Re: problem with command sort after uniq -c
You're right, my locale is set to fr_FR. I've tried with en_EN and en_US, and it works fine (and with -k1,1 too). I think I understand the problem with the locale fr_FR : in french, to write 123456.78 in a easily readable form you write 123 456,78 (and in english it's 123,456.78). Thanks Philip and Andreas for your answers (and sorry for polluting the bug mailing list). Damien Andreas Schwab a écrit : Damien ANCELIN [EMAIL PROTECTED] writes: I met a problem with the sort command : I've used the uniq command with the -c option to count some numbers, and then applying sort -n don't sort lines by numeric order of the first field. Here is an example (my sort version is 5.97) : $ cat bug_sort | sort -n This is a useless use of cat, you can just redirect sort's standard input from the file. 1320 51970 1692 12345 22681 8060 26063 8649 2668 33603 3487 44496 4350 23246 47013 8000 5447 2 81724 5000 I assume that you use the fr_FR locale. In this locale a number can be grouped with a space, thus it is considered part of the number. If you want to be sure that sort only considers the first field as sort key you should use -k1,1 to limit it. The default is to always use the the whole line as sort key, and sort -n will take as much as possible from the key to match a number. Andreas. -- Damien ANCELIN INRIA - ENS-Lyon, LIP (RESO) Bureau 322 Sud Tel : +33 4 72 72 85 02 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #1212] wishlist: ls sort case insensitive option
Follow-up Comment #6, bug #1212 (project coreutils): How about iso-8859-1? -- Nexium http://reallydrugs.com/buy-nexium-online.htmOnline http://reallydrugs.com ___ Reply to this item at: http://savannah.gnu.org/bugs/?1212 ___ 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
Re: tail -1 * has unexpected output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm running version 5.97: (2) [EMAIL PROTECTED] Tue 10:48am [~] % tail --version tail (GNU coreutils) 5.97 Copyright (C) 2006 Free Software Foundation, Inc. This is free software. You may redistribute copies of it under the terms of the GNU General Public License http://www.gnu.org/licenses/gpl.html. There is NO WARRANTY, to the extent permitted by law. Written by Paul Rubin, David MacKenzie, Ian Lance Taylor, and Jim Meyering. The weird thing is that 'tail -1 z.1' works, but 'tail -1 z.1 z.2' errors. If the form -1 is depreciated, shouldn't it fail for the single file invocation also? I'll grab version 6.10 and check it out. Thanks. - - Steve On Fri, 7 Mar 2008, Bob Proulx wrote: Date: Fri, 7 Mar 2008 21:01:47 -0700 From: Bob Proulx [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: bug-coreutils@gnu.org Subject: Re: tail -1 * has unexpected output [EMAIL PROTECTED] wrote: tail: invalid option -- 1 What version of tail are you using? tail --version If it is older than 5.90 please upgrade. Your report implies that you are probably running 5.2.1 from 2004. This behavior was changed in coreutils 5.90 in 2005. The current stable release version is 6.10. Here is the latest release information: http://lists.gnu.org/archive/html/coreutils-announce/2008-01/msg1.html Bob - -- EMAIL: (h) [EMAIL PROTECTED] WEB: http://badcheese.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFH1rkBuiLvK4h2TGkRAi5RAJ9iDjW3MgbpfOkKKUSsX1seYAjlJgCcCLOA s7x59C0K8iy9G4NRiTv4ZlY= =Hk2J -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: tail -1 * has unexpected output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI: using the 6.10 version of tail, still broken, but different error text: (14) [EMAIL PROTECTED] Tue 10:55am [~/coreutils-6.10/src] % ./tail -1 ~/z.1 ~/z.2 ./tail: option used in invalid context -- 1 (15) [EMAIL PROTECTED] Tue 10:57am [~/coreutils-6.10/src] % ./tail -1 ~/z.1 this is z.1 - - Steve On Fri, 7 Mar 2008, Bob Proulx wrote: Date: Fri, 7 Mar 2008 21:01:47 -0700 From: Bob Proulx [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: bug-coreutils@gnu.org Subject: Re: tail -1 * has unexpected output [EMAIL PROTECTED] wrote: tail: invalid option -- 1 What version of tail are you using? tail --version If it is older than 5.90 please upgrade. Your report implies that you are probably running 5.2.1 from 2004. This behavior was changed in coreutils 5.90 in 2005. The current stable release version is 6.10. Here is the latest release information: http://lists.gnu.org/archive/html/coreutils-announce/2008-01/msg1.html Bob - -- EMAIL: (h) [EMAIL PROTECTED] WEB: http://badcheese.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFH1royuiLvK4h2TGkRAkzvAJ9F8F3K/VS+3ixe0UGoS28iOUucnACfU8VX pWBQZUS/rnrn8pfXWenDVJ0= =PVv9 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [ADD TO FAQ] : cut : using space as input delimiter
seb_kramm wrote:
I have search about an hour on how to tell 'cut' to use space as input
delimiter, finally found out alone ! Below is the question I was about to
post, and the solution. I suggest adding this trick to the FAQ, or even
to the manual.
I will add something to the FAQ since this has come up a few times.
I have a generated numeric data file, to be plotted using gnuplot. The
fields are separated with spaces. Before plotting, I need to do some basic
line/text processing, using 'cut' and 'join'.
'cut' isn't the best tool to cut fields. 'awk' is better.
# data
1 1.1 1.3 1.4
2 1.2 1.5 1.6
...
Unfortunatly, I can't manage to use the space character as input separator
for 'cut'. I read the coreutils FAQ, the manual (5.3.0), p.43, but I
understand (and tried) that this is not possible.
The problem is that the fields are separated by TWO spaces not one
space. This means that in the above there are SEVEN fields not four.
Field 2 that you want to cut is an empty field. You would want field
3 instead.
Quote the whole 'd' option:
Yes. Or quote just the delimiter. Either way is exactly the same to
the shell that is parsing the strings. Most GNU and Unix folks would
probably just quote the delimiter because it is whitespace otherwise
and the shell would split the args into different arguments there
otherwise. But I see that you are using MS and the command.com there
is quite different. I only know the GNU and Unix way.
cut --delimiter= -f 2 file_in file_out
or
cut -d -f 2 file_in file_out
But field 2 is empty. It would need to be field three given your data.
cut -d -f3 file_in
Another solution is using 'unexpand' to replace spaces by tabs
Yes. 'cut' was really designed to work on TAB separated fields.
Using 'unexpand' to get to TAB separated fields is in the spirit of
the way cut is designed to work. Today if 'cut' were designed again
it would probably be using a comma by default because .csv files are
more common today than TAB separate fields. I would be inclined to go
this way because then things are more obvious because the delimiters
are visible.
echo 2 1.2 1.5 1.6 | tr ,
2,,1.2,,1.5,,1.6
There it is clear that field 2 is empty.
The better answer to all of this is to use 'awk' because it handles
generic whitespace as a field separator. Try this:
awk '{print$2}' file_in
Bob
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
