[TUHS] UNIX of choice these days?

[Larry McVoy]

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.