Re: Bug#545422: coreutils: "tail -f -" fails

Giuseppe Scrivano writes: > In my opinion, it is desiderable that tail works approximately in the > same way when stdin is specified, Assuming that the extension you proposed in is added to the Linux kernel, I suggest that coreuti

Re: summarizing gnulib changes for coreutils-7.7?

Jim Meyering meyering.net> writes: > Once most of your infrastructure improvements are in gnulib, > would you please write a brief summary to go in NEWS > for the upcoming coreutils-7.7 release? > How about the following? I still want to get my symlink module in first, but that should happen

Re: Bug#545422: coreutils: "tail -f -" fails

Jim Meyering writes: > Considering the amount of complexity it adds to already-dense code > (in spite of the fact that some is just due to indentation changes), > for so little gain (who will use tail -f on stdin and care whether tail > is sleep-based or inotify-based?), I'm reluctant to use it a

Re: ls --help: further tweak

Benno Schulenberg wrote: > On Tue, 22 Sep 2009 20:53 +0200, "Jim Meyering" wrote: >> +Using color to distinguish file types is disabled by default, and with\n\ >> +--color=never. With --color=auto, ls emits color codes only when\n\ >> +standard output is connected to a terminal. > > The thing is

Re: ls --help: further tweak

On Tue, 22 Sep 2009 20:53 +0200, "Jim Meyering" wrote: > +Using color to distinguish file types is disabled by default, and with\n\ > +--color=never. With --color=auto, ls emits color codes only when\n\ > +standard output is connected to a terminal. The thing is: the explicit "is disabled" befor

Re: Bug#545422: coreutils: "tail -f -" fails

Giuseppe Scrivano wrote: > have you considered this patch for inclusion? I don't see a clearer way > to avoid polling without inotify fd support. >> This patch changes `tail' to handle stdin separately from inotify >> events, similar to what we are already doing when a --pid is specified. Hi Giu

Re: Bug#545422: coreutils: "tail -f -" fails

Hi Jim, have you considered this patch for inclusion? I don't see a clearer way to avoid polling without inotify fd support. Regards, Giuseppe Giuseppe Scrivano writes: > This patch changes `tail' to handle stdin separately from inotify > events, similar to what we are already doing when a -

Re: ls --help: further tweak

Benno Schulenberg wrote: > (Sorry for breaking thread. I am using the archives and webmail.) > > Jim Meyering quoted Pádraig Brady's change: >> Using color to distinguish types of files is not enabled by default, or >> when\n\ >> --color=never is specified. [...] > > Hmm, the above is not qui

ls --help: further tweak

(Sorry for breaking thread. I am using the archives and webmail.) Jim Meyering quoted Pádraig Brady's change: > Using color to distinguish types of files is not enabled by default, or > when\n\ > --color=never is specified. [...] Hmm, the above is not quite grammatical. Paraphrased: "Someth

[PATCH] maint: df.c: adapt to newer gnulib

FYI, I expect to update coreutils to use the latest gnulib pretty soon. In preparing for that, I noticed a new syntax-check failure when using the newer gnulib: $ make syntax-check ... src/df.c maint.mk: the above files include "canonicalize.h" but don't use it make: *** [sc_pr

summarizing gnulib changes for coreutils-7.7?

Hi Eric, Once most of your infrastructure improvements are in gnulib, would you please write a brief summary to go in NEWS for the upcoming coreutils-7.7 release? Jim

Re: [PATCH] ls: support disabling colors on all subtypes

Pádraig Brady wrote: > Jim Meyering wrote: >> Pádraig Brady wrote: >>> Subject: [PATCH] ls: allow disabling colors on all file types >>> >> Thanks for doing this. >> However, with that change, the ls/no-cap test now fails: >> (on Fedora 11, configured with libcap-devel.x86_64) >> >> make check

Re: [PATCH] maint: uptime: fix a theoretical compile error

Pádraig Brady wrote: >>From af8f446d3ff9962399a93a20f33e372e57e0daa2 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?P=C3=A1draig=20Brady?= > Date: Tue, 22 Sep 2009 08:01:44 +0100 > Subject: [PATCH] maint: uptime: fix a theoretical compile error > > * src/uptime.c (print_uptime): Reference possibly unu

Re: [PATCH] doc: stdbuf: mention it can have a non standard exit status

Pádraig Brady wrote: >>From 825025d08b464a62abd4030bf4468497bf688cd2 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?P=C3=A1draig=20Brady?= > Date: Tue, 22 Sep 2009 08:35:25 +0100 > Subject: [PATCH] doc: stdbuf: mention it can have a non standard exit status > > * doc/coreutils.texi (Exit status): Add

[PATCH] maint: uptime: fix a theoretical compile error

>From af8f446d3ff9962399a93a20f33e372e57e0daa2 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= Date: Tue, 22 Sep 2009 08:01:44 +0100 Subject: [PATCH] maint: uptime: fix a theoretical compile error * src/uptime.c (print_uptime): Reference possibly unused arguments --- src/uptime.c

[PATCH] doc: stdbuf: mention it can have a non standard exit status

>From 825025d08b464a62abd4030bf4468497bf688cd2 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= Date: Tue, 22 Sep 2009 08:35:25 +0100 Subject: [PATCH] doc: stdbuf: mention it can have a non standard exit status * doc/coreutils.texi (Exit status): Add stdbuf to the list --- doc/cor

Re: [PATCH] ls: support disabling colors on all subtypes

Jim Meyering wrote: > Pádraig Brady wrote: >> Subject: [PATCH] ls: allow disabling colors on all file types >> > Thanks for doing this. > However, with that change, the ls/no-cap test now fails: > (on Fedora 11, configured with libcap-devel.x86_64) > > make check -C tests TESTS=ls/no-cap VERBO

Re: [PATCH] ls: support disabling colors on all subtypes

Pádraig Brady wrote: > Pádraig Brady wrote: >> I was trying to disable the green colors today in my ls listing >> and noticed that if you do that the directories are shown >> without color rather than falling back to the standard color >> for directories (blue). >> >> The attached patch fixes that