>> > > 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:
Bobby has pulled on Sally's hair, to everyone can pull on everyone's
hair. Your list means nothing. Please read the standards fully, and
understand the legal lawyer thing.