demasi@paisano.UUCP (Michael C. De Masi) (09/01/88)
Hi Wizards!
This question is purely informational. The other day I
got a little bored, so I started playing around with
redirecting I/O streams from various programs to different
windows on a 630MTG running layers. Eventually, I figured
I'd try seeing how many windows I could get the same copy
of vi running across. I did something to the effect of:
(stty `cat vi.stty`;vi) < /dev/xt02 > /dev/xt03
while sitting in xt01. (vi.stty is just the stty options
for vi) This allowed me to type into window 2, while having
the output (which was completely correct) wind up in window
three while vi was technically running in window 1. In
fact, the only thing which did appear in window one were
diagnostic messages, as I had not redirected the standard
error at this point. So far, so good.
I then tried the same command, but with a slight variation:
(stty `cat vi.stty`;vi) < /dev/xt02 > /dev/xt03 2>/dev/xt04
Which I believed would have the effect of doing everything
above with the only exception being the stderr would now go
to a fourth window. It didn't work. The window to which
the output of vi should go was no longer correct. In fact,
it was all out of whack. This is where I get lost.
Why should redirecting the stderr away from the window where
the stdout goes affect vi so seriously, or for that matter,
at all? At first I thought that the stdout & stderr somehow
might combine to make the vi screen image, but that can't be
right because of the first example (plus it's a lousy idea)
That's what I _really_ find strange. If redirecting the
stderr to another window messes up vi, then why doesn't
redirecting the stdout? Either way, you wind up with
the I/O streams directed to different places. What's the
difference?
I then tried another variation. I ran the second command
again, only replacing the 'vi' with 'ksh'. This ran much
as I'd expected (I never knew prompts were diagnostic) so
I figured I'd try running vi in this environment. Guess
what? It failed, same way as in example 2.
Somehow, I feel the answer to this must be linked to one
of the great truths of the universe which I have somehow
failed to grasp. Anybody care to enlighten me?
Awaiting your replies,
Michael C. De Masi - AT&T Communications (For whom I work and not speak)
2340 Dulles Corner Blvd. Herndon, Virginia 22071 Phone: 703-834-8123
UUCP: decuac!grebyn!paisano!demasi
"All things considered, I'd rather be in Philadelphia" - W C Fieldsirene@pyr1.cs.ucl.ac.uk (09/02/88)
/* Written 7:12 pm Aug 31, 1988 by demasi@paisano.UUCP in pyr1.cs.ucl.ac.uk:comp.unix.wizards */
/* ---------- "Big fun with 'vi' & I/O redirection" ---------- */
Hi Wizards!
This question is purely informational. The other day I
got a little bored, so I started playing around with
redirecting I/O streams from various programs to different
windows on a 630MTG running layers. Eventually, I figured
I'd try seeing how many windows I could get the same copy
of vi running across. I did something to the effect of:
(stty `cat vi.stty`;vi) < /dev/xt02 > /dev/xt03
while sitting in xt01. (vi.stty is just the stty options
for vi) This allowed me to type into window 2, while having
the output (which was completely correct) wind up in window
three while vi was technically running in window 1. In
fact, the only thing which did appear in window one were
diagnostic messages, as I had not redirected the standard
error at this point. So far, so good.
I then tried the same command, but with a slight variation:
(stty `cat vi.stty`;vi) < /dev/xt02 > /dev/xt03 2>/dev/xt04
Which I believed would have the effect of doing everything
above with the only exception being the stderr would now go
to a fourth window. It didn't work. The window to which
the output of vi should go was no longer correct. In fact,
it was all out of whack. This is where I get lost.
Why should redirecting the stderr away from the window where
the stdout goes affect vi so seriously, or for that matter,
at all? At first I thought that the stdout & stderr somehow
might combine to make the vi screen image, but that can't be
right because of the first example (plus it's a lousy idea)
That's what I _really_ find strange. If redirecting the
stderr to another window messes up vi, then why doesn't
redirecting the stdout? Either way, you wind up with
the I/O streams directed to different places. What's the
difference?
I then tried another variation. I ran the second command
again, only replacing the 'vi' with 'ksh'. This ran much
as I'd expected (I never knew prompts were diagnostic) so
I figured I'd try running vi in this environment. Guess
what? It failed, same way as in example 2.
Somehow, I feel the answer to this must be linked to one
of the great truths of the universe which I have somehow
failed to grasp. Anybody care to enlighten me?
Awaiting your replies,
Michael C. De Masi - AT&T Communications (For whom I work and not speak)
2340 Dulles Corner Blvd. Herndon, Virginia 22071 Phone: 703-834-8123
UUCP: decuac!grebyn!paisano!demasi
"All things considered, I'd rather be in Philadelphia" - W C Fields
/* End of text from pyr1.cs.ucl.ac.uk:comp.unix.wizards */mercer@ncrcce.StPaul.NCR.COM (Dan Mercer) (09/03/88)
In article <520@paisano.UUCP> demasi@paisano.UUCP (Michael C. De Masi) writes:
:Hi Wizards!
:
:This question is purely informational. The other day I
:got a little bored, so I started playing around with
:redirecting I/O streams from various programs to different
:windows on a 630MTG running layers. Eventually, I figured
:I'd try seeing how many windows I could get the same copy
:of vi running across. I did something to the effect of:
:
: (stty `cat vi.stty`;vi) < /dev/xt02 > /dev/xt03
:
:while sitting in xt01. (vi.stty is just the stty options
:for vi) This allowed me to type into window 2, while having
:the output (which was completely correct) wind up in window
:three while vi was technically running in window 1. In
:fact, the only thing which did appear in window one were
:diagnostic messages, as I had not redirected the standard
:error at this point. So far, so good.
:
:I then tried the same command, but with a slight variation:
:
: (stty `cat vi.stty`;vi) < /dev/xt02 > /dev/xt03 2>/dev/xt04
:
:Which I believed would have the effect of doing everything
:above with the only exception being the stderr would now go
:to a fourth window. It didn't work. The window to which
:the output of vi should go was no longer correct. In fact,
:it was all out of whack. This is where I get lost.
:
:Why should redirecting the stderr away from the window where
:the stdout goes affect vi so seriously, or for that matter,
:at all? At first I thought that the stdout & stderr somehow
:might combine to make the vi screen image, but that can't be
:right because of the first example (plus it's a lousy idea)
:That's what I _really_ find strange. If redirecting the
:stderr to another window messes up vi, then why doesn't
:redirecting the stdout? Either way, you wind up with
:the I/O streams directed to different places. What's the
:difference?
:
:I then tried another variation. I ran the second command
:again, only replacing the 'vi' with 'ksh'. This ran much
:as I'd expected (I never knew prompts were diagnostic) so
:I figured I'd try running vi in this environment. Guess
:what? It failed, same way as in example 2.
:
:Somehow, I feel the answer to this must be linked to one
:of the great truths of the universe which I have somehow
:failed to grasp. Anybody care to enlighten me?
:
:Awaiting your replies,
:
:Michael C. De Masi - AT&T Communications (For whom I work and not speak)
:2340 Dulles Corner Blvd. Herndon, Virginia 22071 Phone: 703-834-8123
:UUCP: decuac!grebyn!paisano!demasi
: "All things considered, I'd rather be in Philadelphia" - W C Fields
I tried redirecting i/o with vi some time back - i wanted to
redirect the output of :se all and :map[!] into a member
so I could print it for a presentation. I eventually
succeeded in redirecting ex (you might try that).
Apparently, when entering visual mode, ex (vi) does
an ioctl (2,.. call to set up termio values. If
stderr is not a terminal, everything gets hosed up.
I've also seen odd things happen with shell layers if
everything is not set up perfectly kosher. ( for instance,
layers hanging around after the shell's been killed, with
the output showing up on the system console).
BTW, does delete work on your system from within a layer.
On ours, its just ignored.
Dan Mercer
NCR Comten