bugGNU Core Utilities - Bugs: bug #21758, "yes" problem with...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #21758: "yes" problem with differents languages

Submitted by:  None
Submitted on:  Sun 09 Dec 2007 06:01:34 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Invalid
Privacy: PublicAssigned to: None
Open/Closed: Closed

Sun 09 Dec 2007 07:06:59 PM UTC, comment #2:

Hi Eric,

Thanks for the suggestion, but changing yes to honor locale settings sounds too risky. I suspect that too many applications depend on the existing locale-independent behavior.

Can anyone point to an implementation that does output something other than "y" by default in a non-C locale? It'd be good to know, but probably won't change the outcome.

Jim Meyering <meyering>
Project Administrator
Sun 09 Dec 2007 04:23:57 PM UTC, comment #1:

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.

Eric Blake <ericb>
Project Administrator
Sun 09 Dec 2007 06:01:34 AM UTC, original submission:

the utility yes has some troubles to handle differents languages , for example, in a GNU/linux system with locales setted to es_ES this line fails.

# yes | mkfs.ext3 << more options>>

the line is in one script in this post : http://bbs.archlinux.org/viewtopic.php?t=20385

the problem ocurrs when I call these line, mkfs expects the character "S" to continue but yes generates the character "Y" ...

Anonymous

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by meyering (Posted a comment)
  • -unavailable- added by ericb (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 10 Dec 2007 07:30:40 AM UTCmeyeringStatusNone=>Invalid
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1