which is "better" - /dev/fd or FIFO

[Bob Proulx]

tech-lists wrote:
> Bob Proulx wrote:
> > Note that bash will internally simulate /dev/fd if a real system one
> > is not provided.  Pretty sure anyway.  I have definitely used bash and
> > seen that feature noted even on systems without /dev/fd directory support.
> 
> Basically, I'm asking why it's available to be enabled, and the reason
> I'm asking *that* is because I don't know if or why or in what scenario
> it would be "better".

Personally I think it is "better" if script writers do not use
/dev/stdin, /dev/stdout, /dev/fd/0, /dev/fd/1 when just using normal
standard input and standard output could be used instead.

Again within the last few weeks I saw a script that made use of those
when it was not needed at all.  I just sighed deeply and shook my
head.

However there are internal uses of the /dev/fd feature that enable
other things.  AFAIK the feature originated on SunOS and ksh for use
with process substitution.  To facilitate things like this following
using process substitution.  (Man page example from ksh.)

    paste <(cut -f1 file1) <(cut -f3 file2) | tee >(process1) >(process2)

Note that the above is incomplete.  It needs a final "cat" to
synchronize all of the processes at the end.  Ask me if that is a
curiousity to explore.  It is interesting but somewhat involved.

Look at the result of that command line with echo.  Just the paste
part.  Not the tee part.  And let's use files that exist everywhere so
anyone can try it easily.  Good home kitchen experiment! :-)

    FreeBSD bash$ paste <(echo one) <(echo two)
    one     two

    FreeBSD bash$ echo paste <(echo one) <(echo two)
    paste /tmp//sh-np.xQnJ6e /tmp//sh-np.hgXATD

Hmm...  On FreeBSD with the defaults I see the above.  Appears to be
using temporary files.  Contrast that with a Debian system where I get
the following using /dev/fd.

    Debian bash$ paste <(echo one) <(echo two)
    one     two

    Debian bash$ echo paste <(echo one) <(echo two)
    paste /dev/fd/63 /dev/fd/62

Uses the /dev/fd file system to plumb the piping from one process to
another using pipes rather than temporary files.  That should be more
efficient than the temporary file method.  More pronounced when the
data is large.  Trivially insignificant for most command line actions.

Since you have the experiment primed you could try building bash both
ways and then determining if one of those enables the above feature.
If I had the time I would go look myself.

Note this is not a feature of a POSIX shell and therefore scripts
which use /bin/sh are not going to be affected by this "bash'ism"
(which originated with ksh) at all.  I would happily do this on a
typed in command line where the temporary files would be used and I
would not notice at all that it was using temporary files and not
unamed pipes.  Good enough.

> When I'm installing a port, if there are options available, I'll look at
> them and see if they're needed for my use case. I generally go for the
> minimum number of options to satisfy the use case requirement, because
> it usually makes life simpler. In order to do this, I need to have a
> grasp on what the options enable and why. In this case, i don't know the
> why, which is why I'm asking.

That's good!  And it was only the FIFO mention that confused me
greatly and I wanted to ask about it.  Because I do often miss things
and I had this FOMO fear of missing out!

But also at the time I asked that question I had not tested and not
realized that FreeBSD /dev/fd was not used by bash in the default
configuration.  So actually I would say that FIFO being an unnamed
pipe between processes in this case is used in process substitution.
So...  It does apply! :-)

I am sure I accepted the default options myself.  The tyranny of the
default would imply that most users are accepting the defaults and so
that is the most well tested case.  Probably most are using temporary
files for process substitution.  How often do you do process
substitution in bash?  For me vanishingly few times.

Bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20210308/78f613e0/attachment.sig>