Re: [PLUG] Process substitution

["Paul L. Snyder" <plsnyder@drexel.edu>]

On Tue, 13 Jan 2009, Walt Mankowski wrote:

> On Tue, Jan 13, 2009 at 12:17:15AM -0500, Paul L. Snyder wrote:
> > On Tue, 13 Jan 2009, Paul L. Snyder wrote:
> > 
> > > '...' and make it available through one of those two mechanisms.  In bash,
> > > I believe it will always be a /dev/fd/<n> file descriptor; in zsh, it will
> > > be a named pipe as long as the system supports them, a /dev/fd file
> > > descriptor otherwise.
> > 
> > I just checked the bash manpage, and it looks like bash also supports both
> > implementations, though it describes the named pipe method as historical.
> > On my system, it always uses /dev/fd/*, while zsh prefers a named pipe.
> 
> It seems to always use a file in /tmp under OSX.

Which syntax is that with, =(...) or <(...)?

Hm, you know, I tested those examples on OSX when I was sending that
message...testing <(...) on Linux, zsh uses a FIFO under /dev/fd, just
as bash does. 

On a Mac, bash and zsh behave differently.

Under zsh, the Mac file in /tmp is a FIFO (try 'ls -lF <(ls)').
Under bash, the same command uses a FIFO under /dev/fd.

For comparison, 'ls -lF =(ls)' under zsh also creates a file in /tmp, but
it is a regular file, not a named pipe.  You can see the -l option reports
that it actually has a size, which the FIFO does not.  Thus, <(...) is
better when you are reading through the data once (as the data is queued
in the FIFO and removed once read), while =(...) is necessary if you
will be seeking through the data and the pipe won't work.

Incidentally, for those who aren't familiar with named pipes/FIFOs (which
are different names for the same thing), they are a useful UNIX feature for
shuffling data about.  Try this:

  $ mkfifo i_am_a_pipe
  $ ls -lF > i_am_a_pipe

The data from the 'ls' is queued in the FIFO.  You'll see that ls is
blocking, as no other application has yet read it in.

Open another terminal and try reading:

  $ sort -r < i_am_a_pipe

(If your sorting order is weird, it may be because ls didn't disable color
highlighting, which it usually will do if you use a regular pipe...add a
'--color=never' to the command line if it disturbs you.)

Once sort has read the data, ls unblocks.  Interestingly, you can run the
two commands in either order; if you run sort first, it will block under
some data shows up for it to read.

> Thanks for the explanation and the great talk yesterday.  I'm excited
> about using all these zsh features I never knew about! :)

Thanks!  It was a fun talk to give.  I've been making notes for things to
include when I give it again at East next month, and I think I have enough
material for a completely different one-hour presentation. :)

Slides will be posted sometime this evening.

Paul
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug