Re: Not sure how to best reply re: dir_colors situation

2009-06-11 Thread Kamil Dudka
On Thursday 11 of June 2009 09:54:29 Jim Meyering wrote: I've shortened log message lines to fit within 72-col limit (remember: they get TAB prepended in the generated ChangeLog file). Then we should split the short log message into two parts to fit within the 72-col limit as well. Also

Re: Not sure how to best reply re: dir_colors situation

2009-06-11 Thread Jim Meyering
Kamil Dudka wrote: On Thursday 11 of June 2009 09:54:29 Jim Meyering wrote: I've shortened log message lines to fit within 72-col limit (remember: they get TAB prepended in the generated ChangeLog file). Then we should split the short log message into two parts to fit within the 72-col

Re: Not sure how to best reply re: dir_colors situation

2009-06-11 Thread Kamil Dudka
On Thursday 11 of June 2009 10:28:01 Jim Meyering wrote: Kamil Dudka wrote: On Thursday 11 of June 2009 09:54:29 Jim Meyering wrote: I've shortened log message lines to fit within 72-col limit (remember: they get TAB prepended in the generated ChangeLog file). Then we should split the

Re: inotify back end for tail -f on linux

2009-06-11 Thread Jim Meyering
Giuseppe Scrivano wrote: The new version includes all these changes. ... +/* Tail N_FILES files forever, or until killed. + Check modifications using the inotify events system. */ +static void +tail_forever_inotify (int wd, struct File_spec *f, int n_files) +{ + unsigned int i; +

Re: Not sure how to best reply re: dir_colors situation

2009-06-11 Thread Pádraig Brady
Hmm, it's worth adding a test at least to demonstrate that file permissions take precedence over hardlink coloring I.E. multi hardlinked png and exectuable files will be colored inconsistently. diff attached. cheers, Pádraig. From 656b4273135e50746956dc04b47d1ed96f851d96 Mon Sep 17 00:00:00 2001

Re: Not sure how to best reply re: dir_colors situation

2009-06-11 Thread Jim Meyering
Pádraig Brady wrote: Hmm, it's worth adding a test at least to demonstrate that file permissions take precedence over hardlink coloring I.E. multi hardlinked png and exectuable files will be colored inconsistently. Subject: [PATCH] tests: ls --color, permissions override hardlink coloring *

Re: bug in sort -n -k1.4,1.2

2009-06-11 Thread Pádraig Brady
Thanks for the analysis and patch! I'll take a look at this this evening as I've been looking at this area recently. cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [PATCH] stdbuf work in progress

2009-06-11 Thread Pádraig Brady
Jim Meyering wrote: Pádraig Brady wrote: Update with fixed whitespace and added copyright message to libstdbuf.c: http://www.pixelbeat.org/patches/stdbuf.diff Thanks. I tried to build on Fedora 10 x86_64 and got this: /usr/bin/ld: ../lib/libcoreutils.a(quote.o): relocation R_X86_64_32

Re: Not sure how to best reply re: dir_colors situation

2009-06-11 Thread Matthew Woehlke
Pádraig Brady wrote: Hmm, it's worth adding a test at least to demonstrate that file permissions take precedence over hardlink coloring I.E. multi hardlinked png and exectuable files will be colored inconsistently. If I can interject a question here... I hope I will remember to turn this back

Re: Not sure how to best reply re: dir_colors situation

2009-06-11 Thread Pádraig Brady
Matthew Woehlke wrote: Pádraig Brady wrote: Hmm, it's worth adding a test at least to demonstrate that file permissions take precedence over hardlink coloring I.E. multi hardlinked png and exectuable files will be colored inconsistently. If I can interject a question here... I hope I will

Re: Not sure how to best reply re: dir_colors situation

2009-06-11 Thread Matthew Woehlke
Pádraig Brady wrote: Matthew Woehlke wrote: Pádraig Brady wrote: Hmm, it's worth adding a test at least to demonstrate that file permissions take precedence over hardlink coloring I.E. multi hardlinked png and exectuable files will be colored inconsistently. If I can interject a question

Re: inotify back end for tail -f on linux

2009-06-11 Thread Giuseppe Scrivano
Jim, thank for the review. Jim Meyering j...@meyering.net writes: Perhaps prev_wd would be more accurate? I fixed it. The same name is used in `tail_forever', that is why I used it, should it be changed in `tail_forever' too? Another regression: touch k; chmod 0 k; tail -F k fails

Re: inotify back end for tail -f on linux

2009-06-11 Thread Jim Meyering
Giuseppe Scrivano wrote: Jim, thank for the review. Jim Meyering j...@meyering.net writes: Perhaps prev_wd would be more accurate? I fixed it. The same name is used in `tail_forever', that is why I used it, should it be changed in `tail_forever' too? Another regression: touch k;