Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!ucsd!ucsdhub!hp-sdd!ncr-sd!ncrlnk!ncrcce!mercer
From: mercer@ncrcce.StPaul.NCR.COM (Dan Mercer)
Newsgroups: comp.unix.wizards
Subject: Re: Big fun with 'vi' & I/O redirection
Keywords: vi stdin stdout layers windows
Message-ID: <734@ncrcce.StPaul.NCR.COM>
Date: 2 Sep 88 19:53:19 GMT
References: <520@paisano.UUCP>
Reply-To: mercer@ncrcce.StPaul.NCR.COM (Dan Mercer)
Organization: NCR Comten, Inc.
Lines: 76

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