On Sat, Jun 08, 2024 at 07:33:23PM +0200, Antonio Diaz Diaz wrote: > Hello Emanuele, > > Emanuele Torre wrote: > > I have noticed that ed -p '' errors with the following error. > > Thank you for reporting this, and for your accurate diagnostic of the cause > of the behavior of ed. > > > That seems incorrect; there does not seem to be anything in the > > POSIX Issue 7 specification for ed that allows unspecified behaviour > > when the prompt string is empty or requires that the prompt string > > specified by -p shall not be the empty string. > > 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." > > How should ed interpret the following command line?: > > ed -p"" foo >
ed -p"" foo should be interpreted the same way ed -p foo of course; there is nothing that would suggest it should be interpreted any other way. I'm sorry, but that is just not even a concern in general for any tool that has options. It really just isn't. It is not ambiguous, and I can't even see how you could interpret that paragraph as saying it is an ambiguous case. > Until the above ambiguity is solved (if it is even possible), I think ed's > current behavior is the safest compromise. And regardless, I don't see how it is relevant with regards to the bug that I reported which is that ed -p '' foo always errors. The bug that I reported is neither that ed -p '' foo is interpreted as ed -pfoo nor that ed -p foo does not work because it is interpreted as ed -p '' foo. 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. 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, because again, it is perfectly valid, and it would be wrong to indiscriminately error; at most a specific program could not allow one of its option to be an empty string, just as it could not allow an option argument to be non-numeric. 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. > > Best regards, > Antonio. > o/ emanuele6
