Update of bug #11004 (project coreutils):
Open/Closed: Closed => Open
_______________________________________________________
Follow-up Comment #6:
I looked at the bug again, and now I think I understand it
better. You're calling "sort" twice, in two different
environments. In one environment "sort' has an artificially
restricted amount of memory, so that the call to "setlocale"
fails, and "sort" behaves as if LC_ALL is equal to C. In
the other, there is no such restriction and "sort" behaves
as if LC_ALL is equal to en_GB.ISO-8859-15. The two locales
are not consistent, so "sort" sorts differently under them.
You suggested 'if sort is unable to produce an output that
would pass a "sort -c" check, I think it should exit with a
nonzero status (probably 2).' But if you invoke "sort -c"
in the same environment as "sort", it will pass the "sort
-c" check. So I don't think this is a serious bug.
One possible fix would be for "sort" to report an error
message if setlocale fails. However, this would have
negative consequences. I've been on systems that behave
that way, and whenever you set the locale to something
"wrong", you start getting diagnostics from nearly every
program that you run. The normal Unix utility tradition is
therefore to ignore setlocale failures, and silently fall
back on the POSIX locale.
A better fix might be to modify glibc setlocale to set errno
reliably (currently it doesn't), and to report an error if
we are using glibc and if the errno value indicates a memory
problem. This will require a change to glibc. Perhaps you
could tackle that task?
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?11004>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
