bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Carl Edquist
Subject: Re: clarify behavior of /dev/fd redirections in docs
Date: Tue, 12 Jul 2016 12:22:08 -0500 (CDT)
User-agent: Alpine 2.11 (LRH 23 2013-08-11)

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    address@hidden    http://cnswww.cns.cwru.edu/~chet/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]