[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ed -p '' errors, but shouldn't
From: |
Emanuele Torre |
Subject: |
Re: ed -p '' errors, but shouldn't |
Date: |
Sat, 8 Jun 2024 21:25:26 +0200 |
User-agent: |
Mutt/2.2.13 (00d56288) (2024-03-09) |
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
- ed -p '' errors, but shouldn't, Emanuele Torre, 2024/06/06
- Re: ed -p '' errors, but shouldn't, jackson, 2024/06/06
- Re: ed -p '' errors, but shouldn't, Antonio Diaz Diaz, 2024/06/08
- Re: ed -p '' errors, but shouldn't,
Emanuele Torre <=
- Re: ed -p '' errors, but shouldn't, jackson, 2024/06/08
- Re: ed -p '' errors, but shouldn't, Antonio Diaz Diaz, 2024/06/13
- Re: ed -p '' errors, but shouldn't, jackson, 2024/06/13
- Re: ed -p '' errors, but shouldn't, jackson, 2024/06/13
- Re: ed -p '' errors, but shouldn't, Alexander Jones, 2024/06/14
- Re: ed -p '' errors, but shouldn't, Antonio Diaz Diaz, 2024/06/14