Re: Coordination on standardizing gettext() in future POSIX

[Joerg Schilling]

Hi Bruno!

Bruno Haible <address@hidden> wrote:

> Regarding the gettext(1) program and whether it expands escape sequences
> by default:
>
>
> 1) [1] is ambiguous / self-contradictory.
> On one hand it says:
>
>   This utility interprets C escape sequences such as \t for tab. Use \\ to
>   print a backslash...

It is obvious that gettext(1) must expand escape sequences by default since 
this is the documented default behavior for both Solaris gettext(1) and GNU 
gettext(1) but in the default case, GNU gettext does not behave the way it is
documented. 

> Which sounds like they are expanded by default.
>
> On the other hand it says:
>
>   OPTIONS
>      -e
>          Enable expansion of some escape sequences.
>
> Which sounds like they are NOT expanded by default.

You forgot to mention that it also mentions:

       -n  Suppress trailing newline.

which makes it obvious that someone made a mistake while writing the GNU 
documentation that describes the options. Someone forgot to mention that the 
options -e/-n are both valid only together with the -s option that switches
the behavior. But this wrong wording is only in the GNU documentaion, while 
the official reference documentation from the inventor of the utility says:

     -s                        Behaves like echo(1) (see DESCRIP-
                               TION  above).  If the -s option is
                               specified,  no  expansion   of   C
                               escape  sequences is performed and
                               a newline character is appended to
                               the output, by default.

With your interpretation of the GNU documentation, GNU gettext would need to 
output a newline at the end by default, but it does not. This is another hint
for an implementation bug in GNU gettext...

> So, you can't resolve this question by referencing an ambiguous specification.

Given that the main explanation requires to expand escape sequences without 
giving any exception, this is doubtlessly the the default behavior. We may 
discuss things beyond that description, but given that GNU gettext even copied 
this text from SunOS man pages from the early 1990s, it is obvious that the 
intention of the GNU gettext implementation was to be compatible with the 
reference implementation and there is only a bug in the GNU implementation. 

The documentation from the reference implementation (Solaris) is definitely 
not ambiguous since it correctly documents -s as an exception.

The GNU documentation is obvious for the default case that is documented in the 
DESCRIPTION section, but GNU gettext does not follow that GNU documentation.

The only ambiguity I see in the GNU documentation is in effect for the 
non-default case, but in the non-default case, GNU gettext follows the behavior 
of the reference implementation.


> 2) GNU gettext(1) and Solaris gettext(1) differ in this respect:
>
> GNU:
> $ gettext 'abc\ndef'; echo
> abc\ndef
>
> Solaris:
> $ gettext 'abc\ndef'; echo
> abc
> def
>
> This makes it hard to standardize, since the behaviours differ, and
> both implementations will want to claim need for backward-compatibility.

Well people who expect the current GNU behavior obviously rely on a bug in the 
implementation. So the main question to me is whether GNU gettext will have a 
chance to be fixed. If you like to protect GNU users that rely on that 
implementation bug, GNU gettext could be enhanced to follow the documented 
behavior in case that POSIXLY_CORRECT is set, as used for other standard 
deviations on Linux already.

The Solaris gettext behaves as documented and I see no reason to introduce a 
different description in POSIX since that would cause backwards compatibility 
problems. The Solaris behavior is obviously not a bug and did not change 
during the past 30+ years - much longer than GNU gettext exists.

The Solaris implementation is even able to emulate the GNU behavior if it is
called as:

        gettext -sn "some text"

as long as you do not like to supply "textdomain" as first argument but rather 
as -d option argument.


> 3) Additionally, there's the problem that gettext(1) does not and can not
> (as a program) deal with strings that contain placeholders. As soon as

It seems that you missunderstand the way gettext(1) is intended to be used.

I see two useful ways to do what you like:

1)

        gettext -s "Hello World" $$

2)

        text=$(gettext 'Hello World $$')
        eval echo $text

        or

        eval echo $(gettext 'Hello World $$')

Method 2 is equivalent to the way, C  programs use gettext(3).

Jörg

-- 
 EMail:address@hidden                    (home) Jörg Schilling D-13353 Berlin
    address@hidden (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'