> > > 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, schwa...@usta.de 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:
> > 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.
These recognize '-' as a name for stdin
as one of possibly many inputs:
These process stdin only if it is
the only (unnamed) input: