Thanks for your review. Eric Blake <[EMAIL PROTECTED]> 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). >> [EMAIL PROTECTED] -S @var{string} >> [EMAIL PROTECTED] [EMAIL PROTECTED] > > Shouldn't this be [EMAIL PROTECTED] [EMAIL PROTECTED]'? 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 [EMAIL PROTECTED] -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 @[EMAIL PROTECTED] New scripts should use >> [EMAIL PROTECTED] @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. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
