-----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. > > > [EMAIL PROTECTED] -S @var{string} > [EMAIL PROTECTED] [EMAIL PROTECTED] Shouldn't this be [EMAIL PROTECTED] [EMAIL PROTECTED]'? > @@ -3526,10 +3519,15 @@ numbers of leading blanks in fields can > > Keys can span multiple fields. > > [EMAIL PROTECTED] _POSIX2_VERSION > On older systems, @command{sort} supports an obsolete origin-zero > syntax @[EMAIL PROTECTED] [EMAIL PROTECTED] for specifying sort keys. > [EMAIL PROTECTED] 1003.1-2001 (@pxref{Standards conformance}) does not allow > -this; use @option{-k} instead. > +This obsolete behavior can be enabled or disabled with the > [EMAIL PROTECTED] 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 [EMAIL PROTECTED] -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}. > > [EMAIL PROTECTED] -t [[CC]YY]MMDDhhmm[.ss] > [EMAIL PROTECTED] -t [EMAIL PROTECTED]@[EMAIL PROTECTED]@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 > > [EMAIL PROTECTED] _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 > [EMAIL PROTECTED] options, and if there are two or more @var{file}s and the > +first @var{file} is of the form @[EMAIL PROTECTED]@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 > [EMAIL PROTECTED] 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 > [EMAIL PROTECTED]@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 @[EMAIL PROTECTED] New scripts should use > [EMAIL PROTECTED] @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 [EMAIL PROTECTED] -----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----- _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils