bug#34490: console the user that his -n in sort --debug -n was seen

2019-02-16 Thread 積丹尼 Dan Jacobson
> "PB" == Pádraig Brady  writes:
PB> Fair point. I'm thinking of this extra qualification:

PB>   sort: text ordering performed using ‘en_IE.UTF-8’ sorting rules
Maybe say  'LC_CTYPE=en_IE.UTF-8' 
sorting rules

PB>   sort: text ordering performed using simple byte comparison

sort: text ordering performed using simple byte (LC_CTYPE=C) comparison
or something like that.





bug#34488: Add sort --limit, or document workarounds for sort|head error messages

2019-02-16 Thread 積丹尼 Dan Jacobson
(I recall I heard about 50 years ago when pipe buffers first came to
Unix they were supposed to be invisible to the user...)





bug#34490: console the user that his -n in sort --debug -n was seen

2019-02-16 Thread Pádraig Brady
On 15/02/19 06:21, 積丹尼 Dan Jacobson wrote:
> Can you please have assure the user in that message it makes
> that it has indeed seen his -n/--numeric-sort.
> 
> $ sort --debug
> sort: using simple byte comparison
> $ sort --debug --numeric-sort
> sort: using simple byte comparison
> unchanged. User gets nervous.
> 
> sort (GNU coreutils) 8.30. Sorry we discussed this before but kinda hard to 
> find...

Fair point. I'm thinking of this extra qualification:

  sort: text ordering performed using ‘en_IE.UTF-8’ sorting rules
  sort: text ordering performed using simple byte comparison

cheers,
Pádraig





bug#34488: Add sort --limit, or document workarounds for sort|head error messages

2019-02-16 Thread Bernhard Voelker
On 2/15/19 10:40 PM, Assaf Gordon wrote:
>> $ seq  | env --default-signal PIPE sort -n | sed 5q | wc -l
>> 5
> 
> That is a nice idea, I could've used it myself couple of times.
> 
> Attached a suggested patch.
> If this seems like a good direction, I'll complete it with NEWS/docs/etc.

>  src/env.c| 90 
> +++-

That's quite a lot of new code.

What about a new program ... quick shot (and maybe an unlucky name): 'trap' ?

Have a nice day,
Berny





bug#34239: build failure on Android, due to S_MAGIC_* symbols

2019-02-16 Thread Jim Meyering
On Tue, Jan 29, 2019 at 9:01 PM Pádraig Brady  wrote:
> On 28/01/19 19:19, Bruno Haible wrote:
> > Hi,
> >
> > Compiling coreutils on Android produces this error:
> >
> >   CC   src/tail.o
> > In file included from ../src/tail.c:63:
> > ../src/fs-is-local.h: In function 'is_local_fs_type':
> > ../src/fs-is-local.h:9: error: 'S_MAGIC_AAFS' undeclared (first use in this 
> > function)
> > ...
> > make[2]: *** [src/tail.o] Error 1
> >
> > The Android libc, Bionic, does not define any of these S_MAGIC_* symbols or
> > macros, even in the newest version [1].
> >
> > Can some #ifdef be used to avoid this build failure?
> > 'defined __ANDROID__' tests for Android.
> > 'defined __linux__' tests for Linux excluding Android.
> >
> > Bruno
> >
> > [1] https://android.googlesource.com/platform/bionic/
>
> Interesting. So inotify is supported on that android system.
> Our ifdefs were wrong anyway as we check for remoteness even if one disables 
> inotify.
> I.E. our build would have failed on standard linux if one explicitly disabled 
> inotify.
> I've fixed that up and added support for the android specific "sdcardfs" 
> which I found in:
> https://android.googlesource.com/kernel/common/+/android-mainline-tracking/include/uapi/linux/magic.h
>
> Proposed patch attached.

Looks all good. Thanks!