Hi, Theo de Raadt wrote on Tue, Oct 11, 2016 at 01:35:34PM -0600: > jca@ wrote: >> Jan Stary <[email protected]> writes:
>>> The diff below makes head(1) recognize `-' >>> as a name for the standard input, >>> as many other utilities do. >> Makes sense to me. The following points could be improved IMO: >> - using strcmp sounds cleaner than those char comparisons >> - I don't think the man page bits are needed. Utilities that read from >> stdin are supposed to support `-'. I'm not sure whether the extra >> example is really helpful. >> - should we avoid closing stdin (multiple times)? Even though our >> fclose(3) seems to cope with this, it seems that neither the >> C standard nor POSIX offer such a guarantee. > Do standards permit that extension? POSIX neither requires nor forbids it, but encourages consistency among all the utilities taking [file ...] arguments within a given operating system: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/head.html NAME head - copy the first part of files OPTIONS The head utility shall conform to XBD Utility Syntax Guidelines. STDIN The standard input shall be used if no file operands are specified, and shall be used if a file operand is '-' and the implementation treats the '-' as meaning standard input. Otherwise, the standard input shall not be used. See the INPUT FILES section. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html Guideline 13: For utilities that use operands to represent files to be opened for either reading or writing, the '-' operand should be used to mean only standard input (or standard output when it is clear from context that an output file is being specified) or a file named -. Where a utility described in the Shell and Utilities volume of POSIX.1-2008 as conforming to these guidelines is required to accept, or not to accept, the operand '-' to mean standard input or output, this usage is explained in the OPERANDS section. Otherwise, if such a utility uses operands to represent files, it is implementation-defined whether the operand '-' stands for standard input (or standard output), or for a file named -. (Enjoy language lawyers' paradise.) > This is command used in scripts. Scripts are often portable. If one > operating system has an extension, but others don't, then those > scripts become unportable to use use of these extensions. * 1BSD first had head(1) (by Bill Joy 1977), of course treats "-" as a filename * AT&T System V UNIX didn't provide head(1) at all * NetBSD treats "-" as a filename * FreeBSD treats "-" as a filename * DragonFly treats "-" as a filename * illumos treats "-" as a filename * Oracle Solaris 11 treats "-" as a filename * GNU coreutils treats "-" as standard input Some related utilities: tail(1) grep(1) sed(1) source: UNIX v7 UNIX v4 UNIX v7 (of course all filename) * 4.4BSD-L2 filename filename filename * System V filename filename filename * OpenBSD filename filename filename * NetBSD filename stdin filename * FreeBSD filename stdin filename * DragonFly filename stdin filename * illumos filename filename filename * Solaris 11 stdin filename filename * GNU stdin stdin stdin cat(1), sort(1): POSIX requires treating "-" as standard input > I'm not raising a new argument here, it's been raised numerous times > when it comes to commands commonly used in scripts. > > So consider that first. head(1) is firmly a BSD thingy, and all BSDs agree that "-" is a file name and not standard input. POSIX explicitly encourages treating it as standard input ***if you do that for other utilities, too***, and GNU coreutils has the only head(1) implementation i found so far that actually does it. The bigger picture seems to be that OpenBSD and illumos tend to resist treating "-" as standard input whereever resisting is allowed, while GNU embraces treating "-" as standard whereever allowed. Most other systems seem to be somewhat inconsistent, in particular in those cases where they imported GNU utilities. So much for the facts. I see two ways forward that make sense to me: a) Either remain conservative - in line with both BSD and SysV heritage - and not do it unless required by the standard. b) Or switch over to doing it whereever allowed - but then we should do it not just for head(1), but also for tail(1), grep(1), sed(1) and probably several others, and then we should probably also try to push such patches to FreeBSD, DragonFly, NetBSD, and illumos, or at least give them heads-ups. Changing only head(1) and leaving everything else as it is does not look like a complete plan to me. Even POSIX wouldn't encourage that. Yours, Ingo
