Vitaly Filatov wrote:
>I installed localization patch 119408-07.
>
>This patch significantly change behavior of "date" command
>under Russian ISO8859-5 (ru) and other locales vs. "C" and
>en_US.ISO8859-1 locales.
>...
>This is not good

Not good for sure, but that's POSIX.

Problem is POSIX is not comprised of systems administrators but of
programmers. These POSIX re/engineers neither know nor care how many
sysadmin tools they break or how many useful commands they deprecate.
They are driven to change perfectly functional software "because they
can". Sadly, OS vendors wishing to claim "full POSIX compliance" are
forced to adopt the flawed "standards" and we all have to suffer the
consequences.

Peter



>Compare:
>
>$ LANG=C date
>Fri Feb 16 18:13:54 MSK 2007
>$ LANG=en_US.ISO8859-1 date
>Fri Feb 16 18:18:40 MSK 2007
>$ LANG=en_US date
>Fri Feb 16 18:18:40 MSK 2007
>
>vs.:
>
>$ LANG=en_GB date
>Friday, 16 February 2007 18:16:05 MSK
>$ LANG=ru date
>16 ??????? 2007 ?. 18:18:01 MSK
>$ LANG=ru_RU.ISO8859-5 date
>16 ??????? 2007 ?. 18:19:13 MSK
>$ LANG=fr date
>vendredi 16 f?vrier 2007 18 h 20 MSK
>$ LANG=es date
>viernes 16 de febrero de 2007 18H21'34" MSK
>$ LANG=de date
>Freitag, 16. Februar 2007 18:22 Uhr MSK
>
>All program which use 3 positions for month name and day of
>week name need to be modified!
>
>This is not good
>
>Vitaly Filatov, Moscow

2007-02-19, 01:12(+00), :
> Vitaly Filatov wrote:
>>I installed localization patch 119408-07.
>>
>>This patch significantly change behavior of "date" command
>>under Russian ISO8859-5 (ru) and other locales vs. "C" and
>>en_US.ISO8859-1 locales.
>>...
>>This is not good
>
> Not good for sure, but that's POSIX.
>
> Problem is POSIX is not comprised of systems administrators but of
> programmers. These POSIX re/engineers neither know nor care how many
> sysadmin tools they break or how many useful commands they deprecate.
> They are driven to change perfectly functional software "because they
> can". Sadly, OS vendors wishing to claim "full POSIX compliance" are
> forced to adopt the flawed "standards" and we all have to suffer the
> consequences.
[...]

I don't follow you. POSIX aims at aiding portability.

POSIX doesn't forbid date output to be the same in Russian or US
english locales. However it clearly defines what the output
should be in the POSIX or C locale.

So, it's not making "date" conformant that broke the OP's script
it's making "date" localized that did it.

The OP's script was wrong to assume he could rely on date output
in non-POSIX locales, not because POSIX makes sure the output is
not what he expects in non-POSIX locales, but because there's
nothing (neither POSIX nor common sense) that guarantees the
output format in non-standard locales.

On the contrary, thanks to POSIX, he can now be assured that as
long as he forces the locale to be POSIX, the date output format
will be consistent from system to system.

LC_ALL=C date +%b

will return "Feb" (or whatever the month is in the user's
timezone) whatever the system (as long as you're in a POSIX
environement on that POSIX compliant system).

And

LC_ALL=C date -u +%b

will return the month in the universal time zone.

Without POSIX, how would you want to guarantee anything?

--
Stéphane

Stephane CHAZELAS wrote:
> 2007-02-19, 01:12(+00),
> I don't follow you. POSIX aims at aiding portability.
>
> POSIX doesn't forbid date output to be the same in Russian or US
> english locales. However it clearly defines what the output
> should be in the POSIX or C locale.
>
> So, it's not making "date" conformant that broke the OP's script
> it's making "date" localized that did it.
>
> The OP's script was wrong to assume he could rely on date output
> in non-POSIX locales, not because POSIX makes sure the output is
> not what he expects in non-POSIX locales, but because there's
> nothing (neither POSIX nor common sense) that guarantees the
> output format in non-standard locales.
>
> On the contrary, thanks to POSIX, he can now be assured that as
> long as he forces the locale to be POSIX, the date output format
> will be consistent from system to system.
>
> LC_ALL=C date +%b
>
> will return "Feb" (or whatever the month is in the user's
> timezone) whatever the system (as long as you're in a POSIX
> environement on that POSIX compliant system).
>
> And
>
> LC_ALL=C date -u +%b
>
> will return the month in the universal time zone.
>
> Without POSIX, how would you want to guarantee anything?
>
Thank you!

I do it in the same manner, when I'm writing my skripts.

But I wanted to say that after this patch some X-programs obtain wrong
behavior.

Vitaly Filatov

In alt.solaris.x86 Stephane CHAZELAS wrote:
>I don't follow you. POSIX aims at aiding portability.

Might be true from a data structure and algorithm perspective but clearly
not true from the point of view of a systems administrator. What,
for example, is portable about variable width D.O.M and D.O.W fields?
What about the word "abbreviation" do POSIX re/engineers not understand?

>POSIX doesn't forbid date output to be the same in Russian or US
>english locales. However it clearly defines what the output
>should be in the POSIX or C locale.

Not the problem we are talking about here.

>Without POSIX, how would you want to guarantee anything?

Pure FUD. POSIX doesn't guarantee backwards compatibility, it breaks it.

For a few other examples: why has POSIX "deprecated" the nslookup command,
and sort's -M? Why have they "deprecated" sort flags beginning with "+"?
For another example, where POSIX specifies 'LANG=fr date':

viernes 16 de febrero de 2007 18H21'34" MSK

it could have specified:

Ven Fev 16 18:18:40 MSK 2007

and retained backwards compatibility. Just for starters...

Make no mistake, POSIX is a relatively small group of C programmers with
little or no systems administration experience, making no effort to seek
end-user input on proposed changes. This has always been a problem with
the IEEE. Just this once you would think they could learn something
from the IETF's more successful and inclusive methodology.

Peter

2007-02-20, 19:08(+00), :
> In alt.solaris.x86 Stephane CHAZELAS wrote:
>>I don't follow you. POSIX aims at aiding portability.
>
> Might be true from a data structure and algorithm perspective but clearly
> not true from the point of view of a systems administrator. What,
> for example, is portable about variable width D.O.M and D.O.W fields?
> What about the word "abbreviation" do POSIX re/engineers not understand?

I have no clue what you're talking about.

>>POSIX doesn't forbid date output to be the same in Russian or US
>>english locales. However it clearly defines what the output
>>should be in the POSIX or C locale.
>
> Not the problem we are talking about here.

I beleive someone said: since my system was upgraded for POSIX
compliant, the Russian locale breaks my script.

POSIX doesn't specify what the output of date should be in the
Russian locale, so it can't be, that's what I was saying.

>
>>Without POSIX, how would you want to guarantee anything?
>
> Pure FUD. POSIX doesn't guarantee backwards compatibility, it breaks it.

???

> For a few other examples: why has POSIX "deprecated" the nslookup command,
> and sort's -M? Why have they "deprecated" sort flags beginning with "+"?
> For another example, where POSIX specifies 'LANG=fr date':

You may be confused. There has never been any nslookup or any
name resolution command specified by POSIX, AFAIK.

AFAIK, there's no network related command specified by POSIX

I think the vendors of bind (the ISC at least initially)
deprecated nslookup for their new software "dig". As far as I
know, there's no standard behind it.

> viernes 16 de febrero de 2007 18H21'34" MSK
>
> it could have specified:
>
> Ven Fev 16 18:18:40 MSK 2007
>
> and retained backwards compatibility. Just for starters...

Again, POSIX doesn't specify the output of date in the Spanish or
Russian locale, certainly it can't be blamed for that, you seem
confused again.

> Make no mistake, POSIX is a relatively small group of C programmers with
> little or no systems administration experience, making no effort to seek
> end-user input on proposed changes. This has always been a problem with
> the IEEE. Just this once you would think they could learn something
> from the IETF's more successful and inclusive methodology.
[...]

What are you talking about? Maybe you're confusing POSIX with
something else?


--
Stéphane