> > - It happens to me that I typo things in that context like "uyes",
> > resulting here in a negative answer.
> > That's on me, but that's pretty annoying.
> >
> > It would be nice to check if the answer is either clear positive,
> > or clear negative, and loop until it actually is one of both,
> > in order to avoid those errors.
> >
> > Now POSIX specifies:
> > "If the response is not affirmative"
> >
> > Which hints as “positive” or anything else, but that might be up to
> > interpretation.
>
> I don't fully understand what you mean here. Can you elaborate it
> a bit more?
What I meant is that POSIX specifies that there are two valid cases
for rm -i, affirmative or not:
1 - ^[yY] -> affirmative
2 - ^[^yY] -> negative
It would be nicer to have:
1 - ^[yY] -> affirmative
2 - ^[nN] -> negative
3 - ^[^yYnN] -> garbage, ask again (loop)
> > - I think that it's interactive for giving the user maximum control,
> > as in given the opportunity to take a decision without mistakes,
> > otherwise they'd have just run it without it.
> > In my opinion, just looking at the first char is bound for error,
> > or at least annoyance.
> >
> > Should "yolk" be considered an affirmative answer?
> >
> > I would be for checking the entire word for a case-insensitive
> > "yes", though it wouldn't have to be full ("ye", "y" valid too).
>
> Uhmmmm, this seems contradictory with your previous statement about
> "yolk". IMO yolk is so bad as ye. I think NRK did a very good point
> in other mail about the use of yes(1), that used to be very common.
Well, it wasn't contradictory as I'm pretty sure the y in [yY] stands
for yes and not for yolk.
As ^y.* is valid, I assume that the idea was that one can input "yes",
so it would be natural to accept it, while rejecting yolk.
> > Now POSIX specifies:
> >
> > Affirmative Response
> > An input string that matches one of the responses acceptable to the
> > LC_MESSAGES category keyword *yesexpr*, matching an extended regular
> > expression in the current locale.
> >
> > LC_MESSAGES Category in the POSIX Locale
> > yesexpr
> > "<circumflex><left-square-bracket><y><Y><right-square-bracket>"
> > "^[yY]" noexpr
> > "<circumflex><left-square-bracket><n><N><right-square-bracket>"
> > "^[nN]"
> >
> > So technically ou current agreement would be false anyway,
> > as they explicitely ask for first character, no space trimming.
>
> Yeah, I suppose they didn't specify something like ^[yY]$ to avoid
> discussing if the newline is part of the line read or not, but it
> opens the door to accept anything after the initial "y", like for
> example "yo". I checked that OpenBSD accepts "yo" as affirmative.
That's how POSIX specifies it in the end.
> > - Finally, again with my typoes, it happens that I press enter
> > twice. Resulting in validating the current input, which we may
> > assume is expected, but then also validate the yet-to-happen next
> > prompt.
>
> There are 3 things we can do in this case (an empty line):
>
> - Accept as negative
> - Ignore it
> - Reprint the prompt and get the next line.
>
> > In the end, I'd yield for applying strict POSIX of course,
> > but it might be possible to "improve" the user experience here a
> > bit, without breaking compatibility.
>
> The wording of POSIX here is a bit shit, and after the points that
> you raised and looking the common practice I think if we want to
> be POSIX compatible then we should go to the beginning and just
> look if the first character is 'y' or 'Y'. I don't like this, but
> the regular expressions used in the standard are clear about this
> :(
Yeah I agree too.
The good point about a standard, is that even if you don't entirely
agree with it, at least you know it'll work as expected by users
in general as this is the arbitror in case of uncertainty.
> There is still the option of clear affirmative or clear negative.
> I am not sure if the wording of POSIX accepts that, but it is clear
> that the implementations didn't understand that. In this scenario
> your "uyes" example would loop asking again. This doesn't sound too
> bad to me, not sure about what other think, NRK and THIBAUT?
If I may a bit more uncertainty here, quoting (a bit long):
A.7.3.6 LC_MESSAGES
Affirmative responses like:
y
Yes
Yes!
and negative responses like:
N
No
Never
No way!
should all be recognized as affirmative and negative responses,
respectively, by the EREs identified by the yesexpr and noexpr keywords
for English language-based locales.
There is no requirement that multi-line responses nor ambiguous
responses like: no or yes
yes or no
maybe
be correctly classified by either of these EREs.
So! Now it seems that they say that it's up to the implementation
to interpret what's an ambiguous response or not,
though this quote comes in the context of defining a locale.
They also let the POSIX locale definition ambiguous,
why "^[yY]" and not "^[yY]$" or "^[yY].*$"?
This could use some clarification on the POSIX ml.
