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

Reply via email to