[TUHS] UNIX of choice these days?
lm at mcvoy.com
Thu Sep 28 00:17:06 AEST 2017
On Wed, Sep 27, 2017 at 09:50:10AM -0400, Chet Ramey wrote:
> On 9/26/17 10:02 PM, Larry McVoy wrote:
> >>> Yeah, but still doesn't answer the question, application-wise.?? I'm gonna
> >>> guess (without digging through the source) that it's a "dup2(0, 255)*" or
> >>> something, to "save" a copy of stdin/out/err for some obscure reason.
> >> I already answered this.
> > OK, I'm gonna be that guy because I've learned when I ask, I learn.
> > You answered but I didn't get any insight. Why have an extra fd talking
> > to the tty? bash has 0, 1, 2 talking to it. If it were redirected
> > would it have 255 pointing to some random tty? I don't get the reason
> > for the extra fd.
> OK. The only way to guarantee you have a descriptor open to your
> controlling terminal is to open /dev/tty yourself. You can run `bash -im'
> and have yourself an interactive shell with job control enabled no matter
> where stdin/stdout/stderr point, and they can be redirected at any point
> during execution, so you can't count on them. But why do you have to have
> the fd in the first place?
All the tty stuff wasn't my question, I get all that, I did POSIX conformance
in SunOS, there was a time when I dreamed about setsid() et al :)
> ksh93 uses fd 2 no matter what, so you don't get job control if you
> redirect stderr away from the terminal.)
So that's the behaviour I'm used to (dating myself but this is TUHS so...)
My question really was why use an extra fd? If I run
bash something > /dev/null 2>&1
duh. ksh93 wouldn't let you ^Z that, eh? OK, makes sense, I hadn't
thought it through. Sorry for the brain fart.
More information about the TUHS