Re: Support for `tail -10', etc. even when conforming to POSIX.1-2001

[Paul Eggert]

Thanks for your review.

Eric Blake <address@hidden> writes:

> Hmm - if coreutils ever supplies renice, that would also be a candidate
> for supporting obsolescent usages.

Yes, I suppose so.

> Also, the Austin group minutes mention that uniq could support '+'
> as an option separator

That is the second part of that report: it talks about possible future
changes to the standard.  I decided not to implement that for now,
partly because it's hard to track a standard that's not written yet,
and partly because when the new standard comes out we'll have to
decide whether we want to support _three_ standard variants (1992,
2001, and 2006, say?) or cut it down to two, and I'd rather not worry
about that yet.

> does that mean that `uniq +c' should behave
> as `uniq -c' or as `uniq ./+c'?

No, it would support only "uniq +10" as an alias for "uniq -s 10", as
described in the 1997 edition here:
<http://www.opengroup.org/onlinepubs/007908799/xcu/uniq.html>.
Likewise for sort and tail: it's only a very few options that are
affected (where the old standard says they have to be interpreted as
options and the 2001 standard says they have to be interpreted as file
names).

>> address@hidden -S @var{string}
>> address@hidden address@hidden
>
> Shouldn't this be address@hidden address@hidden'?

Either metanotation is accurate, as the string can be empty.  I
thought it simpler to omit the brackets, but I suppose I might be
talking into the other way.  Is there precedent either way in the
manual?

>> +For example, use @samp{sort ./+2} or @samp{sort -k 3} rather than
>> +the ambiguous @samp{sort +2}.
>
> Shouldn't the second example be address@hidden -k 2}' for consistency?

No, the obsolete notation is origin-0 and the standard one is
origin-1, so the obsolete +2 is equivalent to the standard -k3.

>> +For example, use @samp{touch ./12312359 main.c} or @samp{touch -t
>> +12312359 main.c} rather than the ambiguous @samp{touch 12312359 main.c}.
>> +
>
> Would an example of `touch 1231235999 main.c' compared to `touch -t
> 9912312359 main.c' vs. `touch -5 ./1231235999 main.c' be helpful?

Naaah.  It might encourage people to use 2-digit years.

>> +For compatibility @command{nice} also supports an obsolete
>> +option syntax @address@hidden  New scripts should use
>> address@hidden @var{adjustment}} instead.
>
> Is it worth showing the difference between `nice -10' and `nice --10'?

Similarly, I'd rather not document the obsolete syntax to that level
of detail; it might encourage people to use it.

>> -#define COMMON_SHORT_OPTIONS "-bcdfgik:mMno:rsS:t:T:uz"
>> +static char const short_options[] = "-bcdfgik:mMno:rsS:t:T:uy:z";
>
> `info coreutils sort' and `sort --help' do not mention `sort -y', and you
> just changed its argument from being optional in older POSIX to being
> required.

The C code that implements '-y' works around this apparent change, so
if you combine the change to the C code with the change to the short
options, the user won't notice the difference.  At least that's the
theory.