Re: /bin/sh fd 12

[mlelstv%serpens.de@localhost (Michael van Elst)]

jschauma%netmeister.org@localhost (Jan Schaumann) writes:

>Hello,

>$ ls -li /proc/$$/fd/
>total 0
>      5 crw--w----  1 jschauma  tty    5, 1 Sep 14 02:47 0
>      5 crw--w----  1 jschauma  tty    5, 1 Sep 14 02:47 1
>1090579 crw-rw-rw-  1 root      wheel  1, 0 Sep 14 02:19 12
>      5 crw--w----  1 jschauma  tty    5, 1 Sep 14 02:47 2
>$ ls -li /dev/tty
>1090579 crw-rw-rw-  1 root  wheel  1, 0 Sep 14 02:47 /dev/tty
>$ 

>0, 1, and 2 are obvious, but fd 12 did not seem
>obvious to me.

That's the shell itself using descriptors. These are not inherited
by commands run by the shell, but obviously you can access these
with the proc filesystem just like you access /dev/tty directly.

/bin/sh uses /dev/tty for job control which is enabled automatically
when running as interactive shell. But there is a -m option where
you can enable/disable it, i.e. 'sh +m' runs a shell with job control
disabled and descriptor 12 not open.


>Descriptor 12 being open to the current terminal means
>I can do this:

>$ echo foo >&12
>foo
>$ 

>But I can also:

>$ echo foo >&13
>foo
>$

>even though fd 13 did not show up under /proc/$$/fd/.

fd 13 didn't exist when you were looking, but apparently it did
exist when you told the shell to run the echo command.

When the shell runs an external command, those descriptors
are closed for the process running the external command
(the shell process keeps them open).

For internal commands that are not run in a separate process,
that's obviously different.

Maybe kre@ knows if a shell should allow redirection to its
own internal file descriptors.


>When using /bin/ksh, I see a different extraneous fd,
>fd 10, but I can't write to it:

>$ ls -li /proc/$$/fd/
>total 0
>      5 crw--w----  1 jschauma  tty    5, 1 Sep 14 02:52 0
>      5 crw--w----  1 jschauma  tty    5, 1 Sep 14 02:52 1
>1090579 crw-rw-rw-  1 root      wheel  1, 0 Sep 14 02:51 10
>      5 crw--w----  1 jschauma  tty    5, 1 Sep 14 02:52 2
>$ echo foo >&10
>/bin/ksh: >&10 : illegal file descriptor name
>$ 

(Our) ksh only supports the single digit descriptors 0..9 for redirection
(and descriptor 'p' for the co-process if one exists). >&10 is a
syntax error.


>bash creates /proc/$$/fd/255 with inode 5, it seems...

Our /bin/sh moves the /dev/tty descriptor to an 'unexpected number'
above 10 and uses a somewhat weird algorithm to find a descriptor
and the first one selected is number 12.

Bash apprently uses a different scheme to avoid collisions with
descriptors used elsewhere.

N.B. looking at descriptors from csh/tcsh will be even more confusing.

>Is this documented anywhere?

No idea, but old documentation is usally stored in files with suffix C
for Comment.