Email list hosting service & mailing list manager

Optional option argument Shiro Kawai (07 Jul 2020 02:44 UTC)
Re: Optional option argument Marc Nieper-Wi├čkirchen (07 Jul 2020 09:35 UTC)
Re: Optional option argument Anthony Carrico (08 Jul 2020 16:49 UTC)
(missing)
Re: Optional option argument Anthony Carrico (08 Jul 2020 23:41 UTC)
Re: Optional option argument John Cowan (08 Jul 2020 23:43 UTC)
Re: Optional option argument Anthony Carrico (09 Jul 2020 00:05 UTC)
Re: Optional option argument John Cowan (09 Jul 2020 00:07 UTC)
Re: Optional option argument Anthony Carrico (09 Jul 2020 00:18 UTC)
Re: Optional option argument John Cowan (09 Jul 2020 00:22 UTC)
Re: Optional option argument Arthur A. Gleckler (30 Nov 2020 19:24 UTC)
Re: Optional option argument Anthony Carrico (30 Nov 2020 21:12 UTC)
Re: Optional option argument Arthur A. Gleckler (01 Dec 2020 00:56 UTC)
Re: Optional option argument Eugenio Montano (01 Dec 2020 01:50 UTC)
Re: Optional option argument Arthur A. Gleckler (01 Dec 2020 01:57 UTC)
Re: Optional option argument Anthony Carrico (01 Dec 2020 14:18 UTC)
Re: Optional option argument Shiro Kawai (08 Jul 2020 19:27 UTC)
Re: Optional option argument Anthony Carrico (08 Jul 2020 23:57 UTC)
Fwd: Optional option argument Arthur A. Gleckler (07 Jul 2020 17:34 UTC)
Re: Fwd: Optional option argument Anthony Carrico (08 Jul 2020 16:10 UTC)
Re: Fwd: Optional option argument Arthur A. Gleckler (08 Jul 2020 19:29 UTC)

Re: Optional option argument Anthony Carrico 08 Jul 2020 16:49 UTC

On 7/7/20 5:34 AM, Marc Nieper-Wißkirchen wrote:
> Whatever SRFI 37 does, for the user it should be compatible with GNU's
> getopt_long, which means that optional arguments to long options have
> to use the '=' syntax.

I very much agree about this. It does conflict with the SRFI-37 sample
implementation, as I point out in my other note.

> And optional arguments to short options have to
> be in the same argv element according to the documentation to GNU's
> getopt.

This seems very strange to me. It violates the document I referenced for
GNU guidelines in the SRFI:

https://web.archive.org/web/20030805192036/https://www.gnu.org/manual/glibc/html_node/Argument-Syntax.html

"An option and its argument may or may not appear as separate tokens.
(In other words, the whitespace separating them is optional.) Thus, -o
foo and -ofoo are equivalent."

However, you are correct that this is the current documented behavior
for GNU getopt_long documented behavior:

"If such a character is followed by a colon, the option requires an
argument, so getopt() places a pointer to the following text in the same
argv-element, or the text of the following argv-element, in optarg. Two
colons mean an option takes an optional arg; if there is text in the
current argv-element (i.e., in the same word as the option name itself,
for example, "-oarg"), then it is returned in optarg, otherwise optarg
is set to zero."

I wonder is this is a limitation of the GNU implementation which
actually violates their recommendations?

I'm not sure it would be a good idea to change SRFI-37 itself, because
it could break code, but you could create a revision with a new SRFI
number to address the long argument issue.

--
Anthony Carrico