Emanuele Torre wrote:
On Sat, Jun 08, 2024 at 07:33:23PM +0200, Antonio Diaz Diaz wrote:
Note that empty option-arguments are ambiguous. See item 2a of section '12.1
Utility Argument Syntax':

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_01

"a. If the SYNOPSIS of a standard utility shows an option with a mandatory
option-argument (as with [-c option_argument] in the example), a conforming
application shall use separate arguments for that option and its
option-argument. However, a conforming implementation shall also permit
applications to specify the option and option-argument in the same argument
string without intervening <blank> characters."
[...]
It is not ambiguous, and I can't even see how you could interpret that
paragraph as saying it is an ambiguous case.

It is simple. Posix states that for an option with a mandatory option-argument, as with '-p <string>', the following two forms must be equivalent:

  -p <string>
  -p<string>

This is only possible if <string> is not the empty string.

So, AFAICT, ed's current behavior is the only one that meets the above POSIX requirement.

Anyway, pretty clearly the only correct thing to do when ed -p '' foo
is invoked is to start ed with an empty string as prompt string.

I can change ed (and Arg_parser) as you suggest, but I would like either to see the ambiguity in POSIX solved or a consensus on this list that the POSIX requirement should be ignored (and that using an empty prompt string makes sense instead of just turning prompt mode off).

And the only reason why GNU ed is currently not doing that is that
Arg_parser has a check that indiscriminately errors if an optarg is the
empty string.
getopt would not do that,

Then maybe your getopt implementation does not follow POSIX, because https://pubs.opengroup.org/onlinepubs/9699919799/functions/getopt.html states that:

"The description has been written to make it clear that getopt(), like the getopts utility, deals with option-arguments whether separated from the option by <blank> characters or not."

If implementation-defined behaviour (e.g. erroring as GNU ed is doing)
was allowed for ed's -p option when empty string is passed, it would
have been explicitly stated in the specification.

Or this is an oversight in POSIX, because the rationale states the ambiguity:

https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap12.html

"One of the justifications for selecting the multiple-argument method was that the single-argument case is inherently ambiguous when the option-argument can legitimately be a null string."

Best regards,
Antonio.

Reply via email to