[bug #21758] "yes" problem with differents languages

[Eric Blake]

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/