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