Bruce Korb wrote:
>> If LC_COLLATE is unset, LC_ALL and LANG both affect the collating order.
>
> Neither of which were in the environment, but I didn't show that
> "conclusively". "Trust me" (really). In any event, why would it be
> that "bash" would use en_US and "ls" would use "C"?
Again, i
Chet Ramey wrote:
> If LC_COLLATE is unset, LC_ALL and LANG both affect the collating order.
Neither of which were in the environment, but I didn't show that
"conclusively". "Trust me" (really). In any event, why would it be
that "bash" would use en_US and "ls" would use "C"? Yes, it could
be
Chet Ramey wrote:
> Bruce Korb wrote:
> > $ unset LC_COLLATE
>
> If LC_COLLATE is unset, LC_ALL and LANG both affect the collating
> order.
Aha! So that is where the apparent "system default locale" comes
from.
$ locale | grep COLL
LC_COLLATE=POSIX
$ unset LC_COLLATE
$ locale | grep COLL
LC_CO
Bruce Korb wrote:
> In the listings below, two programs are involved: "ls" and "bash".
> I am inclined to believe that "bash" treats a missing LC_COLLATE
> as "en_US" and "ls" treats it as "C". If there is such a thing as
> an invisible (not in environment variables) "system default locale",
> th
In the listings below, two programs are involved: "ls" and "bash".
I am inclined to believe that "bash" treats a missing LC_COLLATE
as "en_US" and "ls" treats it as "C". If there is such a thing as
an invisible (not in environment variables) "system default locale",
then "ls" is wrong, otherwise
