bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] getargs: don't translate first line of --version


From: Akim Demaille
Subject: Re: [PATCH] getargs: don't translate first line of --version
Date: Sat, 19 Jun 2021 07:34:33 +0200

Hi Alyssa,

> Le 14 juin 2021 à 23:54, Alyssa Ross <hi@alyssa.is> a écrit :
> 
> Many bootstrap/autogen.sh scripts parse the first line of
> "bison --version" to check whether the Bison installed is new enough.
> 
> On my system, where the system language is Esperanto, most of these
> scripts break, because the first line of "bison --version" is
> 
>    bison (GNU-a Bison) 3.7.6
> 
> A grep through po/*.po tells me that systems in Bulgarian,
> Spanish, and Serbian would have the same issue.

It's an error from these scripts to call any program in
the user's locale.  Before trying to "parse" anything from
any tool, one should set LC_ALL to C.  Otherwise you might
get comas instead of decimal points, changes in the translation
etc.

Besides, I would recommend against parsing version strings.
Rather ask the tool itself if it's recent enough.

$ echo '%require "3.0" %% exp:' > /tmp/foo.y
$ LC_ALL=C bison /tmp/foo.y
$ echo '%require "4.0" %% exp:' > /tmp/foo.y
$ LC_ALL=C bison /tmp/foo.y
/tmp/foo.y:1.10-14: error: require bison 4.0, but have 3.7.2.20-52999-dirty
    1 | %require "4.0" %% exp:
      |          ^~~~~
$ echo $?
63


> To avoid this issue, don't translate this line.  It's not really
> something that can be meaningfully translated anyway.

I only partly agree with that.  The best example being precisely
that in the current case it is actually translated.


> Here is a partial list of packages that expects the exact, English
> format of the first line of "bison --version".  (These are just the
> ones I got find from grepping sources I had checked out on my system.)
> 
> - autoconf-archive (ax_prog_bison_version.m4 used by many other packages)

I doubt that, since configure does its job and sets

  # Ensure predictable behavior from utilities with locale-dependent output.
  LC_ALL=C
  export LC_ALL
  LANGUAGE=C
  export LANGUAGE

at the beginning.  So, no, configure scripts are not vulnerable to
locale issues, they properly set the locale.

You also mentioned "bootstrap".  Well, those from gnulib include:

  # Ensure file names are sorted consistently across platforms.
  LC_ALL=C
  export LC_ALL

so they work as expected.

> - glibc
> - util-linux

They all should be fixed to set LC_ALL if they don't already.


> diff --git a/src/getargs.c b/src/getargs.c
> index 5984d826..697ad7eb 100644
> --- a/src/getargs.c
> +++ b/src/getargs.c
> @@ -478,7 +478,7 @@ version (void)
> {
>   /* Some efforts were made to ease the translators' task, please
>      continue.  */
> -  printf (_("bison (GNU Bison) %s"), VERSION);
> +  printf ("bison (GNU Bison) %s", VERSION);
>   putc ('\n', stdout);
>   fputs (_("Written by Robert Corbett and Richard Stallman.\n"), stdout);
>   putc ('\n', stdout);

That being said, I checked the GNU coreutils and gettext, and neither
translate these lines, so I will apply your patch.  But I stand by my
point: tools that "parse" the output of others should require a
standard output, and that starts with LC_ALL=C.  And they should avoid
"parsing" when possible.

Thanks, and cheers!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]