What in the world happened to coreutils?!?!
``sort'' now ignores leading spaces no matter what you do. ``cut'' only inserts the output delimiter between the last and second-to-last ranges. Good thing I still have an 8.2 machine to work on. I give up. SuSE 9.1 was an expensive mistake. gpilotd won't work. subfs is a hassle. I can't use an external hard drive with either USB or Firewire. The nvidia driver flickers the second head DESPITE the fix that used to work on 9.0. Gnome themes don't work. If there's a highly-publicized speed up for 2.6 on my dual Athlon 1.8 system, I have yet to notice it. resmgr was a undocumented pain in the rear to fix up for CD burning. And now this. Un-frickin'-believable. I haven't seen this many problems with a distro since RH 8.0, and that's when I went looking for a new vendor. I jumped the gun and installed this stupid mess on all three of my main computers the first day I got it. I *knew* I should have waited for a new Ximian desktop, a post-release kernel, and some of the first patches to roll through. Here's hoping that this does NOT turn out like Red Hat, and these things get fixed BEFORE the next release... Sigh, dk
On Tuesday 18 May 2004 23.44, David Krider wrote:
``sort'' now ignores leading spaces no matter what you do.
Not my 'sort' (coreutils-5.2.1-23) #> cat test aaa aab baa aad aac
cat test|sort
baa aaa aab aac aad
cat test2
aaa aab baa aad aac
cat test2|sort
aaa aab aac aad baa
``cut'' only inserts the output delimiter between the last and second-to-last ranges.
cat test aaa bbb ccc aab bbc ccd baa bab bac aad aae eef aac aae eeg
cut -d ' ' --output-delimiter=':' -f 1-3 test aaa:bbb:ccc aab:bbc:ccd baa:bab:bac aad:aae:eef aac:aae:eeg
Good thing I still have an 8.2 machine to work on.
great
I give up. SuSE 9.1 was an expensive mistake. gpilotd won't work. subfs is a hassle.
A hassle? Then turn it off. Piece of cake. One slight edit of /etc/fstab and you're done. Mind you, the people I've installed 9.1 for have loved it
On Tue, 2004-05-18 at 17:58, Anders Johansson wrote:
cat test|sort
baa aaa aab aac aad
Case in point:
sort test aaa aab aac aad baa
My ``cut'' works with the example you gave. However, it still fails with my original file. Leaving out the sorting issue... Given: 10165301 GM CPC STABAR, FR CORVETTE 14105128 4656102 RICHRYSLER STABAR, FR 01 PT 4656102 4694750 CHRYSLER STABAR, FR NS MVX-2513-H And the command:
cut --output-delimiter="|" -c 1-17,18-32,33-52,53-
I get: 10165301 GM CPC STABAR, FR CORVETTE |14105128 4656102 RICHRYSLER STABAR, FR 01 PT |4656102 4694750 CHRYSLER STABAR, FR NS |MVX-2513-H The only thing I can think of is my LANG environment variable. It's set to en_US.UTF-8. What's yours? dk
On Wednesday 19 May 2004 04.03, David Krider wrote:
10165301 GM CPC STABAR, FR CORVETTE 14105128 4656102 RICHRYSLER STABAR, FR 01 PT 4656102 4694750 CHRYSLER STABAR, FR NS MVX-2513-H
And the command:
cut --output-delimiter="|" -c 1-17,18-32,33-52,53-
The default delimiter is tab. Are those really tabs in that file, or just spaces
I get:
10165301 GM CPC STABAR, FR CORVETTE |14105128 4656102 RICHRYSLER STABAR, FR 01 PT |4656102 4694750 CHRYSLER STABAR, FR NS |MVX-2513-H
My guess would be that the only tab in there is before the last column, and that 'cut' therefore only sees two columns in there.
On Wednesday 19 May 2004 04.17, Anders Johansson wrote:
On Wednesday 19 May 2004 04.03, David Krider wrote:
10165301 GM CPC STABAR, FR CORVETTE 14105128 4656102 RICHRYSLER STABAR, FR 01 PT 4656102 4694750 CHRYSLER STABAR, FR NS MVX-2513-H
And the command:
cut --output-delimiter="|" -c 1-17,18-32,33-52,53-
I'm sorry, I wrote the previous reply without really reading your mail. I get the same result you do. Off hand, I can't say why
On Tue, 2004-05-18 at 21:33, Anders Johansson wrote:
On Wednesday 19 May 2004 04.17, Anders Johansson wrote:
On Wednesday 19 May 2004 04.03, David Krider wrote:
10165301 GM CPC STABAR, FR CORVETTE 14105128 4656102 RICHRYSLER STABAR, FR 01 PT 4656102 4694750 CHRYSLER STABAR, FR NS MVX-2513-H
And the command:
cut --output-delimiter="|" -c 1-17,18-32,33-52,53-
I'm sorry, I wrote the previous reply without really reading your mail. I get the same result you do. Off hand, I can't say why
Just for completeness on documenting this issue on the list, I'll point out that the "real" docs here: http://www.gnu.org/software/coreutils/manual/html_chapter/coreutils_8.html indicate that --output-delimiter is only supposed to work for -f, not -c invocations. But that begs the questions: 1) Did that change (in coreutils) since 9.0? (Because it used to work.) 2) Why then does it give me any delimiter at all? dk
On Wednesday 19 May 2004 04.45, David Krider wrote:
Just for completeness on documenting this issue on the list, I'll point out that the "real" docs here:
http://www.gnu.org/software/coreutils/manual/html_chapter/coreutils_8.html
indicate that --output-delimiter is only supposed to work for -f, not -c invocations. But that begs the questions: 1) Did that change (in coreutils) since 9.0? (Because it used to work.) 2) Why then does it give me any delimiter at all?
It was introduced in version 4.5.5: * cut: new feature: when used to select ranges of byte offsets (as opposed to ranges of fields) and when --output-delimiter=STRING is specified, output STRING between ranges of selected bytes. cut --output-delimiter="|" -c 1-17,18-32,33-52,53-60 fails completely, while cut --output-delimiter="|" -c 1-16,18-31,33-51,53-60 and cut --output-delimiter="|" -c 1-16,18-31,33-52,53- gives you all the delimiters. Note the last field, if it's open, the one before can be adjacent, but if it's closed there needs to be one char in between. Smells like a bug to me
On Tue, 2004-05-18 at 21:49, Anders Johansson wrote:
2) Why then does it
give me any delimiter at all?
It was introduced in version 4.5.5:
* cut: new feature: when used to select ranges of byte offsets (as opposed to ranges of fields) and when --output-delimiter=STRING is specified, output STRING between ranges of selected bytes.
cut --output-delimiter="|" -c 1-17,18-32,33-52,53-60
fails completely, while
cut --output-delimiter="|" -c 1-16,18-31,33-51,53-60
and
cut --output-delimiter="|" -c 1-16,18-31,33-52,53-
gives you all the delimiters. Note the last field, if it's open, the one before can be adjacent, but if it's closed there needs to be one char in between. Smells like a bug to me
Wow. I'm going to join their bugs list and run it up the flag pole. THANKS! dk
On Tue, 2004-05-18 at 22:04, David Krider wrote:
Wow. I'm going to join their bugs list and run it up the flag pole.
For those playing along at home, I'm going to do something like this: cat <file> | perl -n -e 'print (join ("|", unpack ("A17 A15 A20 A17", $_))); print "\n"' while I try to contact the maintainers. dk
onsdag 19 maj 2004 05:04 skrev David Krider:
On Tue, 2004-05-18 at 21:49, Anders Johansson wrote:
cut --output-delimiter="|" -c 1-17,18-32,33-52,53-60
fails completely, while
cut --output-delimiter="|" -c 1-16,18-31,33-51,53-60
and
cut --output-delimiter="|" -c 1-16,18-31,33-52,53-
gives you all the delimiters. Note the last field, if it's open, the one before can be adjacent, but if it's closed there needs to be one char in between. Smells like a bug to me
Wow. I'm going to join their bugs list and run it up the flag pole.
THANKS! dk
This is what I get: oehansen/temp> cut --output-delimiter="|" -c 1-17,18-32,33-52,53- sort.dat 10165301 G|M CPC S|TABAR, FR CORVETTE 1|4105128 4656102 RIC|HRYSLER S|TABAR, FR 01 PT 4|656102 4694750 C|HRYSLER S|TABAR, FR NS M|VX-2513-H oehansen/temp> echo $LANG sv_SE oehansen/temp> cut --output-delimiter="|" -c 1-17,18-32,33-52,53- sort.dat 10165301 G|M CPC S|TABAR, FR CORVETTE 1|4105128 4656102 RIC|HRYSLER S|TABAR, FR 01 PT 4|656102 4694750 C|HRYSLER S|TABAR, FR NS M|VX-2513-H oehansen/temp> echo $LANG sv_SE.UTF8 oehansen/temp> cut --version cut (coreutils) 5.0 Skrivet av David Ihnat, David MacKenzie, and Jim Meyering.
On Tue, 2004-05-18 at 17:58, Anders Johansson wrote:
On Tuesday 18 May 2004 23.44, David Krider wrote:
``sort'' now ignores leading spaces no matter what you do.
Not my 'sort' (coreutils-5.2.1-23)
http://www.gnu.org/software/coreutils/manual/html_node/coreutils_fot.html#FO... Setting LC_ALL=C fixed my sort problem, but not my cut problem. Have you configured any of this sort of thing?
On Wednesday 19 May 2004 04.09, David Krider wrote:
On Tue, 2004-05-18 at 17:58, Anders Johansson wrote:
On Tuesday 18 May 2004 23.44, David Krider wrote:
``sort'' now ignores leading spaces no matter what you do.
Not my 'sort' (coreutils-5.2.1-23)
http://www.gnu.org/software/coreutils/manual/html_node/coreutils_fot.html#F OOT1
Setting LC_ALL=C fixed my sort problem, but not my cut problem. Have you configured any of this sort of thing?
I haven't changed anything, locale is en_GB and LC_ALL is blank. It must be the default setting, because I haven't touched it (except for setting locale to en_GB in the installation, naturally). LC_COLLATE is POSIX, that is usually the one that affects sort order
On Tue, 2004-05-18 at 21:21, Anders Johansson wrote:
I haven't changed anything, locale is en_GB and LC_ALL is blank. It must be the default setting, because I haven't touched it (except for setting locale to en_GB in the installation, naturally). LC_COLLATE is POSIX, that is usually the one that affects sort order
That's interesting, then. On my system, all the LC* variables (now that I know that ``locale'' shows them) are set to "en_US.UTF-8". According to /etc/sysconfig/language, this is the correct behavior, and you should have an LC_COLLATE of "en_GB.<something>", just like your locale. Hrm. dk
On Wednesday 19 May 2004 04.41, David Krider wrote:
That's interesting, then. On my system, all the LC* variables (now that I know that ``locale'' shows them) are set to "en_US.UTF-8". According to /etc/sysconfig/language, this is the correct behavior, and you should have an LC_COLLATE of "en_GB.<something>", just like your locale. Hrm.
hm, my sysconfig/language says ## Type: string ## Default: "" # # This defines the locale for sorting strings and characters. # It is used by the libc to obtain the alphabetical order of characters # (e.g. for string comparisons). # # To keep bash and possibly other apps from misbehaviour, you should # probably keep this at POSIX and set it only for the apps that need it. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # RC_LC_COLLATE="POSIX" Is that a remnant from a previous version? There's no "language.rpmnew" so I thought it was 9.1. Yours doesn't say that?
On Tue, 2004-05-18 at 22:03, Anders Johansson wrote:
Is that a remnant from a previous version? There's no "language.rpmnew" so I thought it was 9.1. Yours doesn't say that?
Nope, and mine is also a fresh install. The relevant portion is: # Local users will get RC_LANG as their default language, i.e. the # environment variable $LANG . $LANG is the default of all $LC_*-variables, # as long as $LC_ALL is not set, which overrides all $LC_-variables. # Root uses this variable only if ROOT_USES_LANG is set to "yes". # RC_LANG="en_US.UTF-8" All the other RC* things are empty (""). dk
participants (3)
-
Anders Johansson -
David Krider -
Örn Hansen