Hi,
On Sat, Apr 19, 2025 at 12:37:35PM +0200, Quentin Rameau wrote:
> - 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?
> - 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.
> 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.
> - 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
:(
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?
Regards
Roberto Vargas
