Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!vsi1!daver!lynx!m5 From: m5@lynx.uucp (Mike McNally) Newsgroups: comp.unix.wizards Subject: Re: Reading from stderr Message-ID: <5451@lynx.UUCP> Date: 17 Apr 89 15:53:52 GMT References: <5437@lynx.UUCP> <508@visdc.UUCP> Reply-To: m5@lynx.UUCP (Mike McNally) Distribution: na Organization: Lynx Real-Time Systems Inc, Campbell CA Lines: 33 In article <508@visdc.UUCP> jiii@visdc.UUCP (John E Van Deusen III) writes: >In article <5437@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes: >> [ asking about reading from stderr vs. opening /dev/tty ] > >In one application that I have there is a program running in the middle >of a pipe line that sometimes forks an interactive shell. Once I used > >exec /dev/tty > >in order for the shell to access the terminal. The problem was that if >the su command were subsequently invoked, the proper entry in >/etc/ttytype would not be found. . . Gosh all hemlock! I guess I just found an incompatibility between our OS and UNIX. When I open "/dev/tty" on my (non-UNIX) machine, the "driver" for "/dev/tty" does some magic happy stuff and gets the current control device info, and returns a dup'ed file descriptor for that. Thus, when I look at the device number via fstat(), I get the real tty beef. Oh well, I guess I should change the question a little: what's the advantage of having "/dev/tty" behave the way it does in this respect? That is, would a massive catastrophe occur if a file descriptor returned from an open request on "/dev/tty" was a real honest-to-gosh dup of the control tty file descriptor? (Not that I'm suggesting that UNIX be changed; I just need to know if I really ought to bother to break a feature that turns out to be a compatibility issue.) -- Mike McNally Lynx Real-Time Systems uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233 Where equal mind and contest equal, go.