[EMAIL PROTECTED] (Paul Jarc) wrote: > Jim Meyering <[EMAIL PROTECTED]> wrote: >> After 10 years of being merely `obsolescent', head -N has finally >> been officially declared to be `obsolete'. > > This doesn't respond to Ari's argument, though: given that GNU > utilities already go beyond the standard's requirements by supporting > long options, why not also preserve -n/+n arguments as extensions,
Going beyond the requirements (in an explicitly-permitted fashion) is not the same as violating the standard. Making head accept +n/-n would violate the standard. With a conforming implementation of head, `head +1' must try to print the first 10 lines of the file named `+1'. Besides, that old option syntax is incompatible with the guidelines that attempt to make it so most tools treat command-line options consistently. The option syntax guidelines were drafted for a good reason. For example, before this change, using `head *' would fail not only for a file whose name starts with `-', but also for one that starts with `+'. Having to worry about a leading `-' is bad enough. Having to learn/remember that for a handful of programs, a leading `+' is also special is not ideal. And of course, it *is* still possible to obtain the old behavior by setting e.g., _POSIX2_VERSION=199209 in the environment. > especially since so much existing code relies on them? AFAICT, the > only defense of long options is that even though they don't follow the > standard, they are useful. Isn't the same true of -n/+n? _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
