bug#18867: sort utility bug reporting

tag 18867 notabug thanks On 10/27/2014 03:47 PM, Rameshreddy Mudhireddy wrote: > [erammud@eussjlxxen210 ~/programs/python/rewrite_tree]:sort --version > sort (GNU coreutils) 6.12 You may want to upgrade; the latest version is 8.23, and there HAVE been sort bug fixes in the meantime. However, for

bug#18867: sort utility bug reporting

[erammud@eussjlxxen210 ~/programs/python/rewrite_tree]:sort --version sort (GNU coreutils) 6.12 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is

Re: Bug in the sort utility

On 03/08/2010 03:39 PM, Warner Mike - miwarn wrote: > We came across something that appears to be a bug as opposed to an > unintended design feature. Most likely, it is neither a bug nor an unintended feature, but a documented feature of locale specifications. > > I am expecting the output to co

Re: Bug in the sort utility

Warner Mike - miwarn wrote: > We came across something that appears to be a bug as opposed to an > unintended design feature. Thank you for the bug report. However what you are seeing is intended behavior. It isn't something sort has control over. The character collation sequence is chosen by y

Re: Bug in the sort utility

Warner Mike - miwarn writes: > > This is a multi-part message in MIME format. > > --_=_NextPart_001_01CABF10.3624B78B > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable Quoted-Unreadable. Minus 10 points. > I am expecting the output to come out in A

Bug in the sort utility

We came across something that appears to be a bug as opposed to an unintended design feature. If you consider the following source file (named sort.txt in my example): M=L MIK M- M-K M= MIK M-A miw...@avalanche:/home/miwarn> sort sort.txt M= M- M-A MIK MIK M-K M=L miw..

RE: Bug in the sort utility

:39 PM To: 'bug-coreutils@gnu.org' Subject: Bug in the sort utility We came across something that appears to be a bug as opposed to an unintended design feature. If you consider the following source file (named sort.txt in my example): M=L MIK M- M-K M= MIK M-A miw

Re: "sort" utility short comming or bug: cannot sort according to "human format" criterion.

Pádraig Brady wrote: >Andre Gompel wrote: > > > >>Dear colleague: >> it looks like a bug... or at least a short comming. >> >>If I use the -n or -g option I cannot sort according to the output format of >>the "du" or "ls" commands. >> >>Example: >> >> du -chs * |sort -n |more >> >>I am not

Re: "sort" utility short comming or bug: cannot sort according to "human format" criterion.

Andre Gompel wrote: >Dear colleague: > it looks like a bug... or at least a short comming. > >If I use the -n or -g option I cannot sort according to the output format of >the "du" or "ls" commands. > >Example: > > du -chs * |sort -n |more > >I am not sure what would be the best approach,

"sort" utility short comming or bug: cannot sort according to "human format" criterion.

Dear colleague: it looks like a bug... or at least a short comming. If I use the -n or -g option I cannot sort according to the output format of the "du" or "ls" commands. Example: du -chs * |sort -n |more I am not sure what would be the best approach, but I would tend to add one mo

Re: Improper behavior in sort utility

On Wed, 30 Nov 2005, Mark Frost wrote: It appears that sort does not examine the proper fields specified by '-k' unless the '-n' option is given. It would be helpful to know which sort locale is in use here; I'll assume it's en_US. Sort keys can be tricky, but I don't think any of the exampl

Improper behavior in sort utility

Hello, It appears that sort does not examine the proper fields specified by '-k' unless the '-n' option is given. (Behavior observed on 4.5.3 utils included withRedHat EL3. Behavior is consistent with compiled 5.0 binaries from gnu.org) localhost$sort --version sort (coreutils) 4.5.3 Written by

Re: Possible bug in sort utility

On 2005-08-12 "Tal V." <[EMAIL PROTECTED]> writes: > When I sort a file by the second character in first field I have to > refer to the second character as to character number "1" (command > "sort 0.1 filename"). That can't be the syntax that you actually used. Perhaps your email client lopped o

Possible bug in sort utility

I think there is a bug in "sort" utility from the latest utility set coreutils-5.2.1 . When I sort a file by the second character in first field I have to refer to the second character as to character number "1" (command "sort 0.1 filename"). But when I wan

Re: sort utility

On Sat, 25 Jun 2005, John J. Herda wrote: >I am trying to get an ASCII sort and am having great troubles and >frustration. It appears that there is no switch to force an ASCII >sort, only for other kinds of sorts. It appears that environment >variables: LC_ALL, LC_COLLATE, LC_CTYPE, and LANG all

Re: sort utility

John J. Herda wrote: > I am trying to get an ASCII sort and am having great > troubles and frustration. It appears that there is no > switch to force an ASCII sort, only for other kinds of > sorts. It appears that environment variables: LC_ALL, > LC_COLLATE, LC_CTYPE, and LANG all influence how s

sort utility

Gentlemen, I am trying to get an ASCII sort and am having great troubles and frustration. It appears that there is no switch to force an ASCII sort, only for other kinds of sorts. It appears that environment variables: LC_ALL, LC_COLLATE, LC_CTYPE, and LANG all influence how sort works and that