Michael Stone wrote:
> Eric Van Buggenhaut wrote:
> >Michael Stone wrote:
> >>Because in a non-C/POSIX locale that's how sorting works. Case and
> >>punctuation are ignored in a dictionary sort; the only time case and
> >>puncuation matter is if you're doing a ascii sort.
> >
> >OK, I didn't know that. this ascii option isn't documented in the
> >manpage. Maybe including it would be useful ? What option is it btw ?
It *is* documented. However documentation is only useful for people
who read it.
See the man page for sort. Here are the pertinent parts.
man sort
*** WARNING *** The locale specified by the environment affects sort
order. Set LC_ALL=C to get the traditional sort order that uses native
byte values.
See the info documentation for sort. Here are the pertinent parts.
info coreutils sort
Unless otherwise specified, all comparisons use the character
collating sequence specified by the `LC_COLLATE' locale. (1)
(1) If you use a non-POSIX locale (e.g., by setting `LC_ALL' to
`en_US'), then `sort' may produce output that is sorted differently
than you're accustomed to. In that case, set the `LC_ALL' environment
variable to `C'. Note that setting only `LC_COLLATE' has two problems.
First, it is ineffective if `LC_ALL' is also set. Second, it has
undefined behavior if `LC_CTYPE' (or `LANG', if `LC_CTYPE' is unset) is
set to an incompatible value. For example, you get undefined behavior
if `LC_CTYPE' is `ja_JP.PCK' but `LC_COLLATE' is `en_US.UTF-8'.
This is also documented in the FAQ for coreutils which is found by
search engines easily. Look for "Sort does not sort in normal order!"
http://www.gnu.org/software/coreutils/faq/
> >No one can restart cron (ie, /etc/init.d/cron) but root and I'm the
> >only person to know root's password.
>
> And if you restarted cron using an environment which is different from
> the bootup environment that would fit the scenario I suggested.
Agreed. It fits the case exactly.
However, I am not completely convinced that cron does not reset its
locale anyway. So this may or may not be germane. I will need to
look for my own information but no time at the moment. This was the
reason I suggested instrumenting a cron run to deduce for sure with no
doubt what locale the cron task was running under.
> >>>Given this and the example above, I'd say that the problem has nothing
> >>>to do with locale
> >>
> >>The example above isn't a problem, and is exactly the expected output
> >>when using a non-C locale.
Agreed.
> >Using C locale, I get the same result:
> >
> >[EMAIL PROTECTED]:~]$ LANG=C LC_ALL=C LC_COLLATE=C LOCALE=C find
> >/usr/local/RealPlayer/share/r* -type f|sort
> >...
> >or do I miss something ?
Shell metacharacters such as |, ||, &&, ;, separate commands. By
setting the locale for first command (find) you did nothing to the
other command (sort). It still ran in the same environment as your
shell.
> Your locale settings only affected find, not sort. Try
> find /usr/local/RealPlayer/share/r* -type f | LANG=C LC_ALL=C LC_COLLATE=C
> LOCALE=C sort
If LC_ALL is set then none of the others matter. LC_ALL overrides all
of the other settings. It is the Big Gun.
find /usr/local/RealPlayer/share/r* -type f | LC_ALL=C sort
Bob
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
