> > > The diff below makes head(1) recognize `-' > > > as a name for the standard input, > > > as many other utilities do.
On Oct 11 23:55:26, [email protected] wrote: > > 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 > > 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. [Ingo's detailed analysis snipped] > > 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. Thank you for the detailed analysis. If there is any interest in possibly going b) see below for a look at the other text filters. Let me clarify the idea. If a filter recognizes '-' as a name for stdin, then stdin can be one of the _multiple_ files being processed. Filters that do not recognize '-' as a name, on the other hand, only process stdin if it is the _only_ input. For example cat(1) and paste(1) do that, head(1) and tail(1) don't. And there are other utilities that could do that, but don't. Below is a list of text filters from bin/ and usr.bin/ for which this seems relevant, separated into the two camps. Jan These recognize '-' as a name for stdin as one of possibly many inputs: cat cmp comm cut diff file join lam paste pr sdiff sort These process stdin only if it is the only (unnamed) input: column expand fmt fold grep head hexdump nl rev tail ul unexpand unvis vis wc
