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

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Paul Eggert on 4/26/2005 10:52 AM:
> I installed this patch to coreutils to bring back support for commonly
> used commands like "tail -10" even when conforming to POSIX.1-2001, as
> a compatible extension to POSIX.  There are still a few remaining
> trouble spots (see the NEWS patch below) but most of the problems
> should be resolved to everyone's satisfaction.  Thanks to everyone who
> pushed the POSIX committee (and me :-) to get this matter clarified
> and resolved.

In general, this is a nice patch; thanks for working on it!  A few
comments, though...

> +  The following usages now behave just as when conforming to older POSIX:
> +
> +    date -I
> +    expand -TAB1[,TAB2,...]
> +    fold -WIDTH
> +    head -NUM
> +    join -j FIELD
> +    join -j1 FIELD
> +    join -j2 FIELD
> +    join -o FIELD_NAME1 FIELD_NAME2...
> +    nice -NUM
> +    od -w
> +    pr -S
> +    split -NUM
> +    tail -[NUM][bcl][f] [FILE]

Hmm - if coreutils ever supplies renice, that would also be a candidate
for supporting obsolescent usages.  Also, the Austin group minutes mention
that uniq could support '+' as an option separator - does that mean that
`uniq +c' should behave as `uniq -c' or as `uniq ./+c'?  Likewise for sort
and tail.

> @@ -2203,7 +2198,7 @@ three column options (@option{-COLUMN}|@
>  @option{-w} is set.  This is a @acronym{POSIX}-compliant formulation.
>  
>  
> address@hidden -S @var{string}
> address@hidden address@hidden

Shouldn't this be address@hidden address@hidden'?

> @@ -3526,10 +3519,15 @@ numbers of leading blanks in fields can 
>  
>  Keys can span multiple fields.
>  
> address@hidden _POSIX2_VERSION
>  On older systems, @command{sort} supports an obsolete origin-zero
>  syntax @address@hidden address@hidden for specifying sort keys.
> address@hidden 1003.1-2001 (@pxref{Standards conformance}) does not allow
> -this; use @option{-k} instead.
> +This obsolete behavior can be enabled or disabled with the
> address@hidden environment variable (@pxref{Standards
> +conformance}), but portable scripts should avoid commands whose
> +behavior depends on this variable.
> +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?

> @@ -8623,7 +8611,7 @@ the origin for any relative @var{time}s 
>  For example, @samp{-r foo -d '-5 seconds'} specifies a time stamp
>  equal to five seconds before the corresponding time stamp for @file{foo}.
>  
> address@hidden -t [[CC]YY]MMDDhhmm[.ss]
> address@hidden -t address@hidden@address@hidden@var{ss}]
>  Use the argument (optional four-digit or two-digit years, months,
>  days, hours, minutes, optional seconds) instead of the current time.
>  If the year is specified with only two digits, then @var{CC}
> @@ -8633,6 +8621,21 @@ the argument is interpreted as a date in
>  
>  @end table
>  
> address@hidden _POSIX2_VERSION
> +On older systems, @command{touch} supports an obsolete syntax, as follows.
> +If no timestamp is given with any of the @option{-d}, @option{-r}, or
> address@hidden options, and if there are two or more @var{file}s and the
> +first @var{file} is of the form @address@hidden@var{YY}]} and this
> +would be a valid argument to the @option{-t} option (if the @var{YY}, if
> +any, were moved to the front), that argument is interpreted as the time
> +for the other files instead of as a file name.
> +This obsolete behavior can be enabled or disabled with the
> address@hidden environment variable (@pxref{Standards
> +conformance}), but portable scripts should avoid commands whose
> +behavior depends on this variable.
> +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?

> @@ -12453,10 +12449,9 @@ Add @var{adjustment} instead of 10 to th
>  @command{nice} issues a warning but otherwise acts as if you specified
>  a zero adjustment.
>  
> -On older systems, @command{nice} supports an obsolete option
> address@hidden@var{adjustment}}.  @acronym{POSIX} 1003.1-2001 
> (@pxref{Standards
> -conformance}) does not allow this; use @option{-n @var{adjustment}}
> -instead.
> +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'?

> Index: src/sort.c
> ===================================================================
> RCS file: /fetish/cu/src/sort.c,v
> retrieving revision 1.307
> diff -p -u -r1.307 sort.c
> --- src/sort.c        11 Apr 2005 20:10:52 -0000      1.307
> +++ src/sort.c        26 Apr 2005 16:39:28 -0000
> @@ -354,7 +354,7 @@ native byte values.\n\
>    exit (status);
>  }
>  
> -#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.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCb5CD84KuGfSFAYARAhKWAJ0RSbFvQPCJLMEtLgBAqwMSoXCrUwCfUFCS
X/n0lFGYD5v5IgQTi1sPpLs=
=yvhe
-----END PGP SIGNATURE-----