[lug] Process substitution.

[Jeffrey Haemer]

Dave,

Sorry for the long answer that follows.  I just got back from Maine and I
can't sleep.

>  Ignoring /dev/fd/63 because it's not a regular file

Good clue!  logrotate's checking whether what you pass it is a regular file
before it tries to open it -- probably doing a stat and then checking the
S_ISREG flag, to protect against users who accidentally try to pass in
directories or device files, or something.

You could report it as a bug and offer a patch that checks for fifos,
too.  Basically,
change this check:

   [ -f $1 ] || { echo "Ignoring $1 because it's not a regular file"; }

to this

  [ -f $1 ] || [ -p $1 ] || { echo ...; }

(Yeah, but in C.)

 Whether the maintainers take it could be a tossup.   They could, for
example, be constrained by some standards group.

Also, is that enough?  For example, should they also permit you to pipe
stuff in, like this?

   echo "/home/dave/tmp/Logrotate/a.log { ..."  |  logrotate -s -d
/home/dave/tmp/state /dev/stdin

Some programs punt these decisions, and let the user use '-' as a filename
that says, "I know what I'm doing.  Take the input from standard in."

Still, if they're guarding against the user's doing something unintended,
they might print the message to stderr and bail with a non-zero exit status,
instead of just ignoring you.

   [ -f $1 ] || { echo "Ignoring $1 because it's not a regular file" >&2;
exit -1"; }

All that aside,

> vi doesn't either, but vi assumes it will have to seek in the file
> so it would be stupid to try to edit a fifo.

"readlink -f $(which vi)" tells me that, on my box, vi is
/usr/bin/vim.basic, and

  vi <(date)

works without complaint. Go figure.  :-)

-- 
Jeffrey Haemer <jeffrey.haemer at gmail.com>
720-837-8908 [cell], http://seejeffrun.blogspot.com [blog],
http://www.youtube.com/user/goyishekop [vlog]
פרייהייט? דאס איז יאַנג דינען וואָרט.
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20100920/1f0cf579/attachment.html>