Hi,
I want to report a bug in "sort" utility.
When using the sort utility to sort the following text:
> 10D010074019D0050005 RW 16 46.4 25 1 HR _ L S 1 R- L
> 10D010074019D0050009 RW 16 46.4 25 1 HR _ L S 2 R- L
< 10D010074C5A2027 RW 16 46.7 90 0 VW e N S 1 R- R
< 10D010074C5A202B R
On Tue, 4 Mar 2008, Heijnen, Eugène (DID) wrote:
I want to report a bug in "sort" utility.
Please see the FAQ:
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021
Cheers,
Phil
___
Bug-coreutils mai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Heijnen on 3/4/2008 5:18 AM:
|
| I would assume the lines with ">" and "<" would be grouped together, but
I still get:
|
| Apparently the comparing ">" and "<" doesn't work well (or do ">" and
"<" have special meaning?)
It is probably yo
Hey
Just so we don't talk past each other. The problem is that there could
be a case where the 'id' or 'group' commands are called but there is
no user name, neither on the command line nore in the system
(getlogin() == NULL).
The case when an invalid user is given on the commandline is cought by
Didi <[EMAIL PROTECTED]> wrote:
> Just so we don't talk past each other. The problem is that there could
> be a case where the 'id' or 'group' commands are called but there is
> no user name, neither on the command line nore in the system
> (getlogin() == NULL).
>
> The case when an invalid user is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ralf, Jim,
According to Jim Meyering on 3/4/2008 4:37 AM:
|>> + [AC_CONFIG_LINKS([GNUmakefile:GNUmakefile])])
|> Until Automake is fixed, this will cause
|> ./configure && make distclean
|>
|> to bogusly remove GNUmakefile.
|
| Rats! Thank
Ondřej Vašík <[EMAIL PROTECTED]> wrote:
> Hello,
> I think there are still some things to be consolidated.
> The same with verbose output should be done in the case
> of install(when making dir) and in the case of rmdir.
> In the case of shred should be mentioned in info that
> verbose output is to
Heijnen wrote:
> Hi,
>
> I want to report a bug in "sort" utility.
For the umpteenth time this locale "bug" has been reported,
because the default behaviour is unexpected and fixing it requires
knowledge of how locales and environment variables work.
I wonder should we flag the common case on ex
Eric Blake <[EMAIL PROTECTED]> wrote:
> Hi Ralf, Jim,
>
> According to Jim Meyering on 3/4/2008 4:37 AM:
> |>> + [AC_CONFIG_LINKS([GNUmakefile:GNUmakefile])])
> |> Until Automake is fixed, this will cause
> |> ./configure && make distclean
> |>
> |> to bogusly remove GNUmakefile.
> |
> | Rat
Hi Eric,
* Eric Blake wrote on Tue, Mar 04, 2008 at 02:57:51PM CET:
> According to Jim Meyering on 3/4/2008 4:37 AM:
> |>> + [AC_CONFIG_LINKS([GNUmakefile:GNUmakefile])])
> |> Until Automake is fixed, this will cause
> |> ./configure && make distclean
> |>
> |> to bogusly remove GNUmakefile
Pádraig Brady draigBrady.com> writes:
> I wonder should we flag the common case on exit with something like:
>
> if (only_ascii_read && LC_COLLATE!="C" && !LC_ALL) {
>fprintf(stderr, "Warning, sorting ASCII data in non C locale\n");
Nice thought. But it would violate POSIX if done by defau
Eric Blake wrote:
> Pádraig Brady draigBrady.com> writes:
>
>> I wonder should we flag the common case on exit with something like:
>>
>> if (only_ascii_read && LC_COLLATE!="C" && !LC_ALL) {
>>fprintf(stderr, "Warning, sorting ASCII data in non C locale\n");
>
> Nice thought. But it would v
Pádraig Brady draigBrady.com> writes:
> > Nice thought. But it would violate POSIX if done by default
>
> POSIX says you can't warn users about potential problems?
One person's bug is another person's feature. The entire reason that
LC_COLLATE exists is because some people INTENTIONALLY want
Jim Meyering meyering.net> writes:
>
> Nice. I like it.
> I'll wait a few hours before applying it, this time
>
> > (Should we also have a distclean-local rule in Makefile.am that removes
> > the GNUmakefile symlink in VPATH builds, but is a no-op in in-place builds?)
>
> That would be um, c
Hey
After some work, here the final patch proposal.
Thank you very much for your help Jim.
Summary of the patch:
On some systems with AFS 'id' and 'groups' outputted a very big group
number if no user was specified on the command line. This is now
fixed.
Cheers Didi
www.cern.ch/ribalba
Eric Blake wrote:
> Pádraig Brady draigBrady.com> writes:
>
>>> Nice thought. But it would violate POSIX if done by default
>> POSIX says you can't warn users about potential problems?
>
> One person's bug is another person's feature. The entire reason that
> LC_COLLATE exists is because some
Didi <[EMAIL PROTECTED]> wrote:
> After some work, here the final patch proposal.
>
> Thank you very much for your help Jim.
>
> Summary of the patch:
>
> On some systems with AFS 'id' and 'groups' outputted a very big group
> number if no user was specified on the command line. This is now
> fixed
Pádraig Brady wrote:
> As a related issue, why do we indicate in the man page and FAQ to explicitly
> set the order use LC_ALL rather than LC_COLLATE ?
Because there is a priority of variables available the documentation
would need to say set LANG, unless LC_COLLATE is set in which case set
LC_COL
Looks fine to me. :)
On Tue, Mar 4, 2008 at 7:06 PM, Jim Meyering <[EMAIL PROTECTED]> wrote:
> Didi <[EMAIL PROTECTED]> wrote:
> > After some work, here the final patch proposal.
> >
> > Thank you very much for your help Jim.
> >
> > Summary of the patch:
> >
> > On some systems with AFS '
Eric Blake <[EMAIL PROTECTED]> wrote:
> Thanks for waiting. Here's the improved patch, tested with both in-place and
> VPATH builds. And in the process of testing, I noticed that 'make distclean'
> was triggering an autoreconf to update the version stamp - a rather pointless
> waste of time, if y
Hi, All...
It might be that the man page for sort needs some
polishing. I discovered that in the "-k F[.C],F[.C]"
command line argument pair, for fields beyond the
first, the first character appears to be the first
delimiter character prior to the field. For example,
# cat SortProblem1
ABC 0102
Eric Blake <[EMAIL PROTECTED]> wrote:
> And in the process of testing, I noticed that 'make distclean'
> was triggering an autoreconf to update the version stamp - a rather pointless
> waste of time, if you ask me, since the tree is about to be nuked.
Ahh... that part is long overdue. Thanks.
I c
On Tue, Mar 4, 2008 at 3:21 PM, Eric Blake <[EMAIL PROTECTED]> wrote:
> Pádraig Brady draigBrady.com> writes:
>
> > I wonder should we flag the common case on exit with something like:
> >
> > if (only_ascii_read && LC_COLLATE!="C" && !LC_ALL) {
> >fprintf(stderr, "Warning, sorting ASCII d
Tony Kocurko wrote:
> Hi, All...
>
> It might be that the man page for sort needs some
> polishing. I discovered that in the "-k F[.C],F[.C]"
> command line argument pair, for fields beyond the
> first, the first character appears to be the first
> delimiter character prior to the field.
That (c
24 matches
Mail list logo
