Follow-up Comment #1, bug #21758 (project coreutils):
When answering yes/no questions, POSIX states that the locale chosen by
LC_MESSAGES is relevant to the regular expression chosen for recognizing
yes/no answers. yes also takes an optional argument, which is the string it
should output. So either one of these approaches should work around the
problem:
yes S | mkfs.ext3
yes | LC_MESSAGES=C mkfs.ext3
However, it may be worth pursuing two more avenues. One would be a bug
report against the es_ES locale, as used by mkfs.ext3, to make the regular
expression for recognizing a yes answer be more permissive. While POSIX
leaves all locales other than the C locale unspecified, the es_ES locale would
be wise to use a yesexpr of ^[sSyY] rather than ^[sS], as seems to be the case
based on your report.
The other would be writing a patch for coreutils. Right now, yes.c uses the
string "y" untranslated as its default string, when no options are provided.
Perhaps it would be better to use _("y") instead, so that the default output
of yes uses the translated string provided by gettext according to
LC_MESSAGES, which in turn will match the yesexpr compared against by
mkfs.ext3 also determined by LC_MESSAGES.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?21758>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
