tag 22084 notabug
close 22084
stop
Hello Adrià and Deimos,
On 12/03/2015 07:30 AM, Adrià Rovira wrote:
I noticed the reverse option is not correctly applied if it has to sort by more
than one column.
This is not a bug, but simply a usage issue.
The "sort --help" page states:
" ... OPTS is
tag 22084 notabug
thanks
On 12/03/2015 05:30 AM, Adrià Rovira wrote:
> Dear GNU,
>
> I am using the sort command in (GNU coreutils) version 8.13
>
> I noticed the reverse option is not correctly applied if it has to sort by
> more than one column.
>
> This behaviour is corrected by forcing
Dear GNU,
I am using the sort command in (GNU coreutils) version 8.13
I noticed the reverse option is not correctly applied if it has to sort by
more than one column.
This behaviour is corrected by forcing again the type of sort.
This happens with -n and -g.
Example:
echo -e "930 7.83\n930
On 12/03/2015 11:30 AM, Pádraig Brady wrote:
On 03/12/15 18:58, Rich Burridge wrote:
Hi,
I'm finally getting around to integrating coreutils version 8.24
into Solaris 12 (and being built with the Studio C compiler rather
than gcc) and noticed that the test for whether we had stdbuf was
How about the attached (untested) patch instead? It should fix the
underlying problem, and thus avoid the need for fiddling with compiler
flags.
diff --git a/configure.ac b/configure.ac
index 66c8cbe..3f546e9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -475,7 +475,8 @@ AC_LINK_IFELSE(
{
Hi,
I'm finally getting around to integrating coreutils version 8.24
into Solaris 12 (and being built with the Studio C compiler rather
than gcc) and noticed that the test for whether we had stdbuf was
failing.
I've fixed it with the following patch. Looks like gcc just doesn't
trip over this,
On 03/12/15 18:58, Rich Burridge wrote:
> Hi,
>
> I'm finally getting around to integrating coreutils version 8.24
> into Solaris 12 (and being built with the Studio C compiler rather
> than gcc) and noticed that the test for whether we had stdbuf was
> failing.
>
> I've fixed it with the
On 12/03/2015 12:04 PM, Paul Eggert wrote:
How about the attached (untested) patch instead? It should fix the
underlying problem, and thus avoid the need for fiddling with compiler
flags.
Yup. That works nicely too.
Thanks.
On 12/03/2015 01:08 PM, Rich Burridge wrote:
Yup. That works nicely too.
Thanks, I noticed a similar problem in three other places (which I guess
don't affect your platform) and so installed the attached more-general
patch.
>From c536d89fc497f90464de61c5b4207d103dfbad08 Mon Sep 17 00:00:00
Paul Eggert wrote:
> How about the attached (untested) patch instead? It should fix the
> underlying problem, and thus avoid the need for fiddling with compiler
> flags.
> diff --git a/configure.ac b/configure.ac
> index 66c8cbe..3f546e9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@
Eric Blake wrote:
> Bob Proulx wrote:
> > Or is a return 0 already defaulted? It stood out to me that the
> > previous return was unconditional and without an else or a
> > fallthrough this is a change from the previous control flow.
> >
> > -return !(stdbuf == 1);]])
> > +if (stdbuf
11 matches
Mail list logo
