Joerg Schilling <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> wrote: > >> > It needs to be "head -39c x.tar"... >> >> Oh, I see. `head -c39' works fine with GNU head, so you must be >> using some other version. I agree that using -39c is more portable. > > If your head program accepts -c39, I would call this a bug.
It's a long-standing feature of GNU head: head --bytes=N (-c N) You're the first in 13 years to call it a bug. ... > But the problem not is that a program incorrectly asumes that open() > would never return 2. > > The "problem" is that the program correctly asumes that stderr is an > open fd at program startup. There was a related discussion some time > before on the POSIX mailing list. POSIX provides no guarantee that any file descriptor will be open at startup. But in programs that are run set-ID, reopening on e.g., /dev/null is permitted. If the standard ever does allow such behavior for non-set-ID programs, it will have to adjust the meaning of the shell's N>&- syntax. > With star in (default mode with FIFO) you get even other problems. > The libschily error output rutines check the write(2) return code > and abort star because of the write problem when fd#2 is not open. I'd rather not make any GNU coreutils program abort just because someone (probably accidentally or unknowingly) invoked it with closed stdin, stdout, or stderr. Even programs that *may* use a stream like stderr can usually work just fine if that stream is initially closed. Would you like touch or cp to abort if invoked like this touch foo 2>&- I certainly wouldn't. > If I recall the POSIX discussion correctly, if POSIX would explicitly > allow this, the correct fix would be to enhance the startup code before > main() is called to make sure that things are as expected..... Finding an acceptable definition of `as expected' and changing the standard to *allow* that new behavior will take time. Maybe a very long time. If this happens, it will be years before the majority of systems provide such protection. _______________________________________________ Bug-tar mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-tar
