Ingo Schwarze <schwa...@usta.de> writes:
> Theo de Raadt wrote on Tue, Oct 11, 2016 at 01:35:34PM -0600:
>> jca@ wrote:
>>> Jan Stary <h...@stare.cz> writes:
>>>> The diff below makes head(1) recognize `-'
>>>> as a name for the standard input,
>>>> as many other utilities do.
>>> Makes sense to me. The following points could be improved IMO:
>>> - using strcmp sounds cleaner than those char comparisons
>>> - I don't think the man page bits are needed. Utilities that read from
>>> stdin are supposed to support `-'. I'm not sure whether the extra
>>> example is really helpful.
>>> - should we avoid closing stdin (multiple times)? Even though our
>>> fclose(3) seems to cope with this, it seems that neither the
>>> C standard nor POSIX offer such a guarantee.
>> 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:
> head - copy the first part of files
> The head utility shall conform to XBD Utility Syntax Guidelines.
> The standard input shall be used if no file operands are
> specified, and shall be used if a file operand is '-' and the
> implementation treats the '-' as meaning standard input.
> Otherwise, the standard input shall not be used. See the INPUT
> FILES section.
> Guideline 13:
> For utilities that use operands to represent files to be opened
> for either reading or writing, the '-' operand should be used
> to mean only standard input (or standard output when it is clear
> from context that an output file is being specified) or a file
> named -.
> Where a utility described in the Shell and Utilities volume of
> POSIX.1-2008 as conforming to these guidelines is required to
> accept, or not to accept, the operand '-' to mean standard input
> or output, this usage is explained in the OPERANDS section.
> Otherwise, if such a utility uses operands to represent files,
> it is implementation-defined whether the operand '-' stands for
> standard input (or standard output), or for a file named -.
> (Enjoy language lawyers' paradise.)
>> 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.
> * 1BSD first had head(1) (by Bill Joy 1977),
> of course treats "-" as a filename
> * AT&T System V UNIX didn't provide head(1) at all
> * NetBSD treats "-" as a filename
> * FreeBSD treats "-" as a filename
> * DragonFly treats "-" as a filename
> * illumos treats "-" as a filename
> * Oracle Solaris 11 treats "-" as a filename
> * GNU coreutils treats "-" as standard input
> Some related utilities:
> tail(1) grep(1) sed(1)
> source: UNIX v7 UNIX v4 UNIX v7 (of course all filename)
> * 4.4BSD-L2 filename filename filename
> * System V filename filename filename
> * OpenBSD filename filename filename
> * NetBSD filename stdin filename
> * FreeBSD filename stdin filename
> * DragonFly filename stdin filename
> * illumos filename filename filename
> * Solaris 11 stdin filename filename
> * GNU stdin stdin stdin
> cat(1), sort(1): POSIX requires treating "-" as standard input
>> 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.
Thanks a lot for this thorough analysis.
> 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.
Well, let's see if someone volunteers. :)
> 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.
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE