| Stephane CHAZELAS 2007-02-19, 7:20 am |
| 2007-02-19, 01:12(+00), <PeterSans@not.sonic.net>:
> Vitaly Filatov <vitaly.filatov----@----mail.ru> wrote:
>
> 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
|