hi,
> diff --git a/libutil/confirm.c b/libutil/confirm.c
> new file mode 100644
> index 0000000..4fa48fb
> --- /dev/null
> +++ b/libutil/confirm.c
> @@ -0,0 +1,21 @@
> +/* See LICENSE file for copyright and license details. */
> +#include <stdarg.h>
> +#include <ctype.h>
> +
> +#include "../util.h"
> +
> +int confirm(const char *fmt, ...) {
> + int c, ans;
> + va_list ap;
> +
> + va_start(ap, fmt);
> + xvprintf(fmt, ap);
> + va_end(ap);
> +
> + while (isblank(c = getchar()))
> + ;
> + ans = c;
> + while (c != '\n' && c != EOF)
> + c = getchar();
> + return ans == 'y' || ans == 'Y';
> +}
If I may chime in a bit after the battle,
I have a few remarks, especially that this tooling will be
at the center of interactiveness in sbase:
- 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 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).
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.
- 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.
I would really like if we would flush stdin before prompting,
in order to avoid the other kind of issues
I realize most of those points are "personal preferences",
and I don't expect them to be approved 100%,
but at least maybe improving the discussion here.
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.
Thanks!
