Re: clarify behavior of /dev/fd redirections in docs

[Carl Edquist]

Hi Chet, thanks for the reply!

> These semantic differences do exist with the Linux implementation of
> /dev/fd, but not with other implementations.  The BSD and Mac OS X
> versions, for instance, behave more or less as if they duplicate the
> file descriptor.

Yes, *BSDs have dup semantics for opening /dev/fd/*, so the behavior is 
implementation-specific.  But the point is that bash in fact does not 
handle /dev/fd/* (or /dev/std{in,out,err}, for that matter) filenames 
specially at all when they are provided by the OS, while the docs state 
without qualification that it does handle them specially.

You might say that much is a philosophical argument, which can be made 
even if all OS implementations gave /dev/fd/* dup semantics on open -- the 
question is whether or not bash itself is doing anything special with 
them.

But on the practical side, the biggest gotcha on Linux is probably that 
the files /dev/std{out,err} refer to can get truncated ... for example:

        some_script_or_function () {
                echo BEGIN STDERR >/dev/stderr

                command_with_stdout_and_stderr

                echo END STDERR >/dev/stderr
        }

        some_script_or_function >>out.log 2>>err.log

The docs imply dup semantics which would append all stderr to err.log, but 
the behavior on Linux (because bash does not treat them specially and 
duplicate the fd, as the docs claim it does) is the final redirection 
truncates err.log and all you get is the "END STDERR" footer.


Apart from that, I do in fact personally use this feature of the Linux 
implementation to re-open fds with /dev/fd/* with different open modes 
(both for files and pipes, actually).  The docs imply that that shouldn't 
work, but I am glad that it does in fact work.


> I suppose it's worth saying something about how bash emulates the files 
> on systems that don't provide the feature themselves.

Sure!  Yeah, that sounds like it would convey both the intention and the 
actual behavior.

Thanks for your time & consideration!

Carl

On Tue, 12 Jul 2016, Chet Ramey wrote:

> On 7/11/16 6:02 PM, Carl Edquist wrote:
>
> > Bash Version: 4.3
> > Patch Level: 46
> > Release Status: release
> >
> > Description:
> >     The docs say:
> >
> >         Bash handles several filenames specially when they are
> >         used in redirections, as described in the following table:
> >
> >             /dev/fd/[fd]
> >                 If [fd] is a valid integer, file descriptor [fd]
> >                 is duplicated.
> >
> >     But in fact this is only true when HAVE_DEV_FD is undefined (see
> >     redir.c lines 522-524).
> >
> >     Of course, when HAVE_DEV_FD is defined and the /dev/fd mechanism
> >     for opening files is available, the idea is _similar_ to fd
> >     duplication, but in fact there are important differences in the
> >     semantics:
>
> These semantic differences do exist with the Linux implementation of
> /dev/fd, but not with other implementations.  The BSD and Mac OS X
> versions, for instance, behave more or less as if they duplicate the
> file descriptor.  For instance,
>
> https://github.com/freebsd/freebsd/blob/master/sys/fs/fdescfs/fdesc_vnops.c;
> in particular fdesc_open(), which sets things up for dupfdopen(),
> which duplicates a file descriptor.
>
> I suppose it's worth saying something about how bash emulates the
> files on systems that don't provide the feature themselves.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/