Re: GNU coding standards clash with POSIX for "... | tail -f"

[Bob Proulx]

Paul Eggert wrote:
> The GNU Coding Standards say that programs' behavior should be
> independent of file type, but POSIX says that "tail" is supposed to
> ignore any -f option if it has no operands and if standard input is a
> pipe.  The POSIX requirement is kind of strange and I don't think many
> people are relying on it, but it's common practice.

Could you expand on "... I don't think many people are relying on it,
but it's common practice." as that seem to imply conflicting things
and I think your meaning there is significant.

> A consequence of this strangeness is that GNU "tail -f FOO" and
> "tail -f <FOO" have differing behaviors if FOO is a FIFO: "tail -f
> FOO" works, and follows FOO, but "tail -f <FOO" does not.  This is
> because there's no portable way to distingish a FIFO stdin from a
> pipe stdin.

I checked the behavior of native HP-UX tail and found that it follows
the POSIX requirement, if I read that right.  That also matches the
current coreutils cvs head behavior.

This is going to be difficult to illustrate but here goes:

  $ mknod namedpipe p
  $ { sleep 2 ; echo hello > namedpipe ;} & /bin/tail -f < namedpipe
  [1] 19858
  [1]+  Done                    { sleep 2; echo hello >namedpipe; }
  hello
  $ 

This is the same behavior I get from the current coreutils cvs.  And
HP-UX native tail follows the input when it is a named argument.

  mknod namedpipe p
  $ { sleep 2 ; echo hello > namedpipe ;} & /bin/tail -f namedpipe
  [1] 19924
  hello
  [1]+  Done                    { sleep 2; echo hello >namedpipe; }
  ...tail is following namedpipe...interrupt it...

I am mostly just pointing this out to show that POSIX appears to be
simply documenting the current behavior of legacy Unix implemenations
and probably not trying to dictate a particular objective here.

Bob