>> > > 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:
>> 
>>   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

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.

Reply via email to