27 Sep
2017
27 Sep
'17
8:17 p.m.
On Wed, Sep 27, 2017 at 09:50:10AM -0400, Chet Ramey wrote:
On 9/26/17 10:02 PM, Larry McVoy wrote:
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 :)
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. 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.