Re: date zh_TW.Big5 +%P

Better ask a real Chinese. Or better yet: Send a patch. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

date zh_TW.Big5 +%P

You guys blew it for date +%P for locale zh_TW.Big5 $ date +%p%P -d 16 下午工午 $ date +%p%P 上午已午 The third character doesn't make sense to me both times. Just copying from %p would be safer. Or using nothing. Better ask a real Chinese. ___ Bug-coreutils ma

Re: sort 5.2.1 is VERY slow

[EMAIL PROTECTED] writes: > Note these multibyte extensions have been > added (hacked in?) by distributions, and > are not in the official coreutils release. Actually, coreutils "sort" does indeed have some multibyte support these days, since it uses strcoll rather than strcmp, and this can indee

Re: date --help sends one digging RFCs

Eric> Instead of complaining, why not propose a patch? It doesn't even have to OK, maybe add an option that would show what all the flags are now, and in the current locale, $ date --examples-current which would give sort of like what $ set -- $(date --help| perl -anlwe 'next unless /./;$_=$F[0];

Re: sort 5.2.1 is VERY slow

[EMAIL PROTECTED] writes: > Taking this example again: > > grep "konnect 1" Out_konnect | sort --key=4 -n > > "konnect 1" is a fixed ascii string, hence > grep can automatically do LANG=C and -F It cannot do the former. There are encodings where bytes that look like plain ASCII are in fact part

Re: sort 5.2.1 is VERY slow

Dick Hessel wrote: That did the trick! I did not realize that character set translations where going on . (I've never been a Unicode fan...) Thanks! Dick Note grep and sort could be more clever in this regard. Taking this example again: grep "konnect 1" Out_konnect | sort --key=4 -n "konnect 1" i

Re: sort 5.2.1 is VERY slow

That did the trick! I did not realize that character set translations where going on . (I've never been a Unicode fan...) Thanks! Dick [EMAIL PROTECTED] wrote: Dick Hessel wrote: Hi, I was looking at some data in a 6MB text file using sort. When I used the --key flag, the speed of sort was embarr

Re: detecting nonconforming nanosleep

Jim Meyering <[EMAIL PROTECTED]> writes: > I like it. > Thanks. OK, I installed , both in gnulib and coreutils, with the following additional change to gnulib: 2005-03-01 Paul Eggert <[EMAIL PROTECTED]> * modules/xnan

Re: Bug in sort?

On Tue, Mar 01, 2005 at 02:44:09PM +0100, Bernd Klein wrote: > But it means on the other hand, that I can't sort international results (with > "." instead of ",") in a German locale, execept with using sed or awk as a > filter. You can use 'LC_NUMERIC=C sort ...' I think. Tim. */ pgpmwtXfkVm

Re: sort 5.2.1 is VERY slow

Dick Hessel wrote: Hi, I was looking at some data in a 6MB text file using sort. When I used the --key flag, the speed of sort was embarrassingly bad. It was *~80 times slower* on my new Athlon64 processor as on an old 1GHz P3 using cygwin's sort under Windows 2000! I ran grep "konnect 1" Out_konne

Re: Bug in sort?

On Tuesday, 1. March 2005 00:05, you wrote: > Bernd Klein <[EMAIL PROTECTED]> writes: > > which is what I expect to happen, but if I use "sort -g +1 -2 > > example.txt" (-g according to man page: compare according to general > > numerical value) I get the confusing result: > > blabla 0.5 abcd > > x

sort 5.2.1 is VERY slow

Hi, I was looking at some data in a 6MB text file using sort. When I used the --key flag, the speed of sort was embarrassingly bad. It was *~80 times slower* on my new Athlon64 processor as on an old 1GHz P3 using cygwin's sort under Windows 2000! I ran grep "konnect 1" Out_konnect | sort --key=4 -