-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Mikhail Teterin on 9/21/2006 11:12 PM: > = The point I am trying to > = make is that since 'm4 -d' is an example of an optional argument, it > = should behave exactly as POSIX requires that 'pr -s' should behave, and > = POSIX is clear that 'pr -s _' is an option without argument followed by a > = filename, although FreeBSD's getopt_long under POSIXLY_CORRECT mistakenly > = treats it as an option with argument and no filename. > > What evidence do you have for this? In fact, you are wrong. BSD's pr takes > special precautions -- to be POSIX compliant. `pr -s' works as prescribed.
If 'pr -s' works correctly on FreeBSD, it is because it took special precautions, and does NOT use BSD's getopt_long. You have confirmed my argument - if 'm4- d' is to have the same semantics of optional arguments, then it must not use FreeBSD's getopt_long. > > There is, however, no POSIX requirement for `m4 -d' -- its reliance on an > optional argument is thus gratuitous. Exactly - which is why GNU M4 can prescribe its semantics as a pure extension to POSIX; and we have chosen that in GNU m4, -d takes an optional argument. This is perfectly compliant with POSIX, and GNU 'm4 - -d' predates the move of POSIX away from optional arguments. > Although there is no documentation for getopt_long, you find it possible to > call the BSD's implementation of it broken because it respects a commonly > used environment variable POSIXLY_CORRECT. > > The getopt manual page on my RedHat installation documents the "dual colon" > feature as a GNU extension. It is quite natural, that it would be turned off, > when POSIXLY_CORRECT is found in the environment. On GNU systems, POSIXLY_CORRECT does not imply disabling ALL extensions, it only implies disabling default behavior where the default is non-compliant. m4 -d is not specified by POSIX, therefore, POSIXLY_CORRECT has no business changing the behavior of m4 -d, because it is a pure extension rather than a non-compliant default. Likewise to the GNU :: parsing in getopt - POSIX does not specify it, so POSIXLY_CORRECT has no business changing the behavior of getopt/getopt_long with regards to handling short options called out with ::. POSIXLY_CORRECT does, however, have the right to change whether getopt is permitted to rearrange arguments, since POSIX is explicit that filenames are not to be intermixed with options, but GNU by default allows out-of-order parsing as an ease-of-use non-compliant extension. My goal with m4, along with Paul's goal for GNU coreutils, is that POSIXLY_CORRECT should affect as little behavior as possible, because it is just that much more of a testing and maintenance nightmare. It seems apparent that you don't agree with my line of reasoning any more than I agree with yours, so I probably will not be answering any more questions in this thread. I would love to use FreeBSD's getopt_long to minimize the size of m4, but cannot do so unless FreeBSD's getopt_long will not change the behavior of m4 from what it currently is. We'll just have to agree to disagree on whether GNU's behavior for optional arguments to options should be consistent whether or not POSIXLY_CORRECT is in effect. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFFAKn84KuGfSFAYARAqWRAJ98WCojhqNxidO29WaWiNQ2nAaw7ACbBpVO STN67W3WLrnzRKieiIN/sDM= =/6dI -----END PGP SIGNATURE-----
