Paul Eggert <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Paul Jarc) writes: >> If the choice is somehow truly under the control of the coreutils >> installer, then I would be happier. > > It's clearly under their control now.
It's clearly under the control of the libc installer, but what if the libc installer is not the coreutils installer? What if I'm installing coreutils on a system where I don't have root access, and don't want to install my own libc? If unistd.h doesn't define _POSIX2_VERSION, then I can define it with "-D_POSIX2_VERSION=..." in CFLAGS. But if unistd.h does define it (unconditionally), then my definition will conflict with that. I think it ought to be possible for the user building coreutils to say what version of conformance they want - say, with a ./configure argument - and this should override the unistd.h definition. >> Item 2c of the Utility Argument syntax rules allows for historical >> cases where the option and its argument cannot be separated. > > No, 2c merely says that even if a utility's synopsis says "tail -n > 35", a conforming application can still invoke "tail -n35". But it then goes on to make exceptions, so that there may be cases such as "tail -35" that do not behave the same way as "tail -3 5"; that's what I was talking about. But it also says these cases are specially marked, and tail is not marked, so scratch that. >> Long options are not single characters. > > Correct. They do not follow the utility argument syntax at all. No > option can possibly use the character '-', because '--' is already > reserved by the standard. This is an escape hatch that long options > can use, but '-10' and '+10" cannot use. And I think this is why the > syntax for long options in GNU has changed. It used to be '+option', > and if memory serves it was also '-=option', but neither of these > choices was a pure extension to POSIX; so the syntax is now > '--option', which is a pure extension. You are reading guideline 10 and concluding that arguments such as "--help" cannot be options. But we could come to that same conclusion from guideline 2, since "-" is not alphanumeric. "=" is also not alphanumeric, so ISTM that "-=help" would be just as much of a pure extension: it doesn't follow the rules, therefore it must be the kind of thing that doesn't have to follow the rules. If "--help" is a pure extension because it does not match the syntax rules, and if "+help" also does not match the syntax rules, then why is "+help" not also a pure extension? >> Can't this be done just as easily for -n/+n? > > I don't think so. '-1' is clearly an option; No. "-1" clearly *can be* an option, since it matches the syntax rules, whereas "--help" cannot be an option, since it does not. But where does the standard say that any argument that matches the syntax rules for options *must be* an option, and thus must match the semantic rules as well (e.g., that "-x -y" has the same semantic meaning as "-xy")? POSIX tells us "if the argument is an option, then it should obey these rules". But AFAICT, there is no guidance for determining whether an argument is an "option" in the first place, other than the standard options (e.g., head -n, but not head -c). paul _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
