Re: About printf %2$s (Was: Coordination on standardizing gettext() in future POSIX)

Stephane CHAZELAS wrote: > (what's "whatwhell" by the way? or do you mean Scan Mascheck's > "whatshell"?) Correct, sticky fingers ;-) Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog:

Re: About printf %2$s (Was: Coordination on standardizing gettext() in future POSIX)

2020-02-03 11:43:38 +0100, Joerg Schilling: [...] > > $ /usr/xpg4/bin/sh -c 'type printf' > > printf is a shell builtin > > This does not apply to OpenSolaris, but on OpenSolaris, this was closed > source > as ksh88 is not available under OSS license. > > This also does not apply to Oracle

Re: About printf %2$s (Was: Coordination on standardizing gettext() in future POSIX)

Stephane Chazelas wrote: > 2020-01-24 15:14:48 +0100, Joerg Schilling: > > printf "Hello World %2$s %1$s\\n" 1 2 > [...] > > mksha ksh88 clone > [...] > > ksh88 had no printf builtin. OK, this is a mstake that frequently happens because most shells have a builtin printf.

About printf %2$s (Was: Coordination on standardizing gettext() in future POSIX)

2020-01-24 15:14:48 +0100, Joerg Schilling: [...] > > > printf "$(gettext 'Hello World %2$d %1$d')\\n" 1 2 > > > > > > to be able to control the order of the output of arguments in a way that > > > is > > > specific to the target language. ... > > > > > BTW: this extension is also available

Re: Coordination on standardizing gettext() in future POSIX

Bruno Haible wrote: > > If you use a modern printf(1) implementation (as available in "bosh"), you > > could even use: > > > > printf "$(gettext 'Hello World %2$d %1$d')\\n" 1 2 > > > > to be able to control the order of the output of arguments in a way that is > > specific to the

Re: Coordination on standardizing gettext() in future POSIX

Jörg Schilling wrote: > OK, then use: > > printf "$(gettext 'Hello World %d')\\n" $$ This is a good solution to the problem of gettext with sentences with embedded arguments. I withdraw my objection about "half of the necessary API". The other objection, that we should avoid copying the

Re: Coordination on standardizing gettext() in future POSIX

Bruno Haible wrote: > > eval echo $(gettext 'Hello World $$') > > No, this is not a reasonable way to use the 'gettext' program either. It fails > miserably when the translation of 'Hello World $$' contains a semicolon. Try OK, then use: printf "$(gettext 'Hello World %d')\\n" $$

Re: Coordination on standardizing gettext() in future POSIX

Sorry, hit Send early by accident. It is not a matter of what I like or not, as that would mean adding something way more flexible than gettext to the standard; it is if one implementation choice, for technical reasons, can be seen as intrinsically more portable than another that choice has

Re: Coordination on standardizing gettext() in future POSIX

It is not a matter of what I like or not, as that would mean adding something way more flexible than gettext to the standard, it is if one implementation choice, for technical reasons, can be seen as intrinsically more portable than another that choice has priority for standardization.

Re: Coordination on standardizing gettext() in future POSIX

On 1/22/20 9:08 AM, Bruno Haible wrote: Ulrich Drepper wrote: Do you really like to require SunOS to loose backwads incompatiblity? Overly dramatic. You just need one mode that is POSIX compatible. Many GNU tools use POSIXLY_CORRECT_ The Solaris practice for keeping backward compatibility

Re: Coordination on standardizing gettext() in future POSIX

On Wed, Jan 22, 2020 at 10:47 AM Joerg Schilling < joerg.schill...@fokus.fraunhofer.de> wrote: > Gettext is a SunOS invention and other implementations are expected to > follow > the definition from the reference implementation. > That implementation was the starting point but I didn't just copy

Re: Coordination on standardizing gettext() in future POSIX

Jörg Schilling wrote: > > It is well-known that the escape sequence expansion in 'echo' was different > > in System V and BSD systems. You can assume that when Ulrich Drepper started > > out writing GNU gettext in 1995, he did NOT want to copy the System V > > behaviour > > of 'echo' into the

Re: Coordination on standardizing gettext() in future POSIX

Bruno Haible wrote: > It is well-known that the escape sequence expansion in 'echo' was different > in System V and BSD systems. You can assume that when Ulrich Drepper started > out writing GNU gettext in 1995, he did NOT want to copy the System V > behaviour > of 'echo' into the 'gettext'

Re: Coordination on standardizing gettext() in future POSIX

Joerg Schilling wrote: > 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. What you call the

Re: Coordination on standardizing gettext() in future POSIX

Bruno Haible wrote: > If that is your approach to standardization, then it is better to not > standardize > anything. If your approach is to standardize obvious implementation bugs, I am a bit bewildered. I was in hope that you are interested in a fruitful discussion and open to useful

Re: Coordination on standardizing gettext() in future POSIX

Hi Bruno! Bruno Haible 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...

Re: Coordination on standardizing gettext() in future POSIX

Shware Systems wrote: > This is not invention, as even Solaris allows you to turn it off with -s, as > you point out. It may work fine for the charsets/charmap files Solaris > historically provides to have escapes active as the default, but this does > not equate to it being valid for all

Re: Coordination on standardizing gettext() in future POSIX

Hi Jörg, 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... Which sounds like they are expanded by

Re: Coordination on standardizing gettext() in future POSIX

This is not invention, as even Solaris allows you to turn it off with -s, as you point out. It may work fine for the charsets/charmap files Solaris historically provides to have escapes active as the default, but this does not equate to it being valid for all conforming charsets, if an

Re: Coordination on standardizing gettext() in future POSIX

Shware Systems wrote: > My two cents, I'm more in favor of requiring the -e ala GNU, as a byte stream > that may be an escape for the charset of one locale may be plain text in > another locale, especially when the encoding of the escape char itself > differs. This can complicate editing data

Re: Coordination on standardizing gettext() in future POSIX

My two cents, I'm more in favor of requiring the -e ala GNU, as a byte stream that may be an escape for the charset of one locale may be plain text in another locale, especially when the encoding of the escape char itself differs. This can complicate editing data files when a pot file is a

Re: Coordination on standardizing gettext() in future POSIX

Bruno Haible wrote: > Joerg Schilling wrote: > > From looking at the current manuals available on Linux systems, I propose > > to > > start with the manual pages from OpenSolaris since these manual pages seem > > to > > be closer from being complete enough for the POSIX standard. > > The

Re: Coordination on standardizing gettext() in future POSIX

Joerg Schilling wrote: > From looking at the current manuals available on Linux systems, I propose to > start with the manual pages from OpenSolaris since these manual pages seem to > be closer from being complete enough for the POSIX standard. The text from LI18NUX [1] and LSB [2] would be a

Re: Coordination on standardizing gettext() in future POSIX

Hi all, I am happy that we have an agreement to standardize gettext() in POSIX. We may need to agree on a way to do the discussion. Using the Austin Mantis may be an option but I am not sure whether this is the best idea. Eric Blake wrote: > Hello GNU gettext folks, > > Jörg Schilling is

Re: Coordination on standardizing gettext() in future POSIX

Eric Blake wrote: > Jörg Schilling is interested in standardizing gettext() and friends in a > future version of POSIX (as a replacement to the hard-to-use catgets() > that is currently standardized). See > http://austingroupbugs.net/view.php?id=1122 Thanks for the heads-up. I added a couple

Re: Coordination on standardizing gettext() in future POSIX

I am interested in participating, too. Wilhelm -- When the fog came in on little cat feet last night, it left these little muddy paw prints on the hood of my car. -- *** Wilhelm Müller 5E6E CF83 B15E

Re: Coordination on standardizing gettext() in future POSIX

I am also interested in doing work on this, for the 30112 standard. Do we have any text that could be used for normative wording in a standard? best regards keld On Thu, Aug 09, 2018 at 11:32:50AM -0500, Eric Blake wrote: > Hello GNU gettext folks, > > Jörg Schilling is interested in

Coordination on standardizing gettext() in future POSIX

Hello GNU gettext folks, Jörg Schilling is interested in standardizing gettext() and friends in a future version of POSIX (as a replacement to the hard-to-use catgets() that is currently standardized). See http://austingroupbugs.net/view.php?id=1122 While there are probably things in GNU