Re: Updating FreeBSD port

[Mikhail Teterin]

On Friday 22 September 2006 00:14, Eric Blake wrote:
= > Where did pr enter the picture? We are talking about gm4 here...
= 
= pr is a POSIX utility that has an option that takes an optional argument
= (most POSIX-specified utilities do not fit this bill, since POSIX has
= moved away from optional arguments in general).  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.

There is, however, no POSIX requirement for `m4 -d' -- its reliance on an 
optional argument is thus gratuitous.

= > = > Do I have you converted yet?
= > =
= > = Nope.  All you have managed to do is convince me that GNU m4 and gnulib
= > = should continue rejecting the current FreeBSD getopt_long implementation
= > = as broken.
= >
= > So, respecting the POSIXLY_CORRECT makes something broken, while ignoring
= > it makes it correct?
= 
= Unfortunately for FreeBSD's getopt_long, yes.  That's why gnulib doesn't
= use FreeBSD's implementation.

This does not make sense, I'm sorry.

= > Where is the standard for getopt_long documented, anyway?
= 
= My understanding is that it was invented by GNU, then copied by BSD.

Not copied, but re-implemented (under a BSD license).

= I'm not sure if LSB or SUSv3 documents it (POSIX certainly does not).  But
= you could always look to the source code in glibc, where the comments are a
= pretty good documentation.

? Are you seriously advising me to use source code as documentation? And still 
talking about standards and brokenness? Am I to believe, you are arguing in 
good faith?

Without a documented standard, any implementations will remain open to 
whimsical accusations of being "broken" by the authors of other 
implementations. This is exactly, what is happening now.

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.

If GNU wishes for its *implementations* to be widely used, they should change 
their license to be more permissive. Otherwise, they need to publish detailed 
*specifications*, so that other implementations can be created...

        -mi