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 up.
...
Subject: [PATCH] ls: allow disabling colors on all file types
* src/ls.c (print_color_indicator): Use consistent syntax for
all file and directory subtypes, and fall back to the color
of the base type if there is no enabled color for the subtype.
This allows turning off specific colors for o+w dirs for example.
* tests/ls/color-dtype-dir: Add a case to test that turning off
coloring for o+w directories, falls back to standard dir color.
* NEWS: Mention the fix
Introduced by commit ac467814, 2005-09-05,
Colorize set-user-ID ... files and sticky ... directories.
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 VERBOSE=yes
perhaps because of the way it tries to disable colorizing
based on capabilities:
rm -f out
eval $(TERM=xterm dircolors -b | sed 's/ca=[^:]*:/ca=:/')
strace -e capget ls --color=always /dev/null 2 out || fail=1
$EGREP 'capget\(' out fail=1
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 VERBOSE=yes Oops, that test was skipped on my system. I needed: sudo yum install libcap-devel I must look at warning or at least documenting these optional libs to get full coverage. I switched the other tests to call is_colored() last as that's probably faster for all other cases, and I switched this one for consistency. But as noted in http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=f3f1ccfd that order was on purpose for performance reasons. I'll push the attached. sorry, Pádraig. p.s. for my own reference here is another ls slow down I found: http://lists.gnu.org/archive/html/bug-coreutils/2009-04/msg00036.html From 8c92bb3441c628fe87ccf4a946b1c8b14cb0a0d2 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com Date: Tue, 22 Sep 2009 10:06:49 +0100 Subject: [PATCH] ls: fix a performance regression * src/ls.c (print_color_indicator): This reinstates commit f3f1ccfd, 21-10-2008, ls: make it possible to disable file capabilities checking which was inadvertently reverted with commit 3a169f4c, 14-09-2009, ls: handle disabling of colors consistently --- src/ls.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/ls.c b/src/ls.c index 2fb5282..859d7c4 100644 --- a/src/ls.c +++ b/src/ls.c @@ -4126,7 +4126,8 @@ print_color_indicator (const char *name, mode_t mode, int linkok, type = C_SETUID; else if ((mode S_ISGID) != 0 is_colored (C_SETGID)) type = C_SETGID; - else if (has_capability (name) is_colored (C_CAP)) + /* has_capability() called second for performance. */ + else if (is_colored (C_CAP) has_capability (name)) type = C_CAP; else if ((mode S_IXUGO) != 0 is_colored (C_EXEC)) type = C_EXEC; -- 1.6.2.5
[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?= p...@draigbrady.com
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/coreutils.texi |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 27c5809..fa05626 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -745,8 +745,8 @@ However, some of the programs documented here do produce
other exit status values and a few associate different
meanings with the values @samp{0} and @samp{1}.
Here are some of the exceptions:
-...@command{chroot}, @command{env}, @command{expr},
-...@command{nice}, @command{nohup}, @command{printenv}, @command{sort},
+...@command{chroot}, @command{env}, @command{expr}, @command{nice},
+...@command{nohup}, @command{printenv}, @command{sort}, @command{stdbuf},
@command{su}, @command{test}, @command{timeout}, @command{tty}.
--
1.6.2.5
[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?= p...@draigbrady.com 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 |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/uptime.c b/src/uptime.c index 0449c6d..cb3dcf0 100644 --- a/src/uptime.c +++ b/src/uptime.c @@ -111,7 +111,11 @@ print_uptime (size_t n, const STRUCT_UTMP *this) boot_time = UT_TIME_MEMBER (this); ++this; } +#else + (void) n; + (void) this; #endif + time_now = time (NULL); #if defined HAVE_PROC_UPTIME if (uptime == 0) -- 1.6.2.5
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?= p...@draigbrady.com 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 Good catch.
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?= p...@draigbrady.com 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 |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/uptime.c b/src/uptime.c index 0449c6d..cb3dcf0 100644 --- a/src/uptime.c +++ b/src/uptime.c @@ -111,7 +111,11 @@ print_uptime (size_t n, const STRUCT_UTMP *this) boot_time = UT_TIME_MEMBER (this); ++this; } +#else + (void) n; + (void) this; #endif Theoretical, indeed ;-) When a ChangeLog entry affects #ifdef'd code, adding the affected condition (at least when it's not too long) in brackets makes the summary more useful: And this would avoid a warning (albeit sometimes mapped to an error via -Werror): maint: uptime: fix a theoretical compiler warning * src/uptime.c (print_uptime) [!HAVE_UTMPX_H !HAVE_UTMP_H]: Reference possibly unused arguments.
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 -C tests TESTS=ls/no-cap VERBOSE=yes Oops, that test was skipped on my system. I needed: sudo yum install libcap-devel I must look at warning or at least documenting these optional libs to get full coverage. I switched the other tests to call is_colored() last as that's probably faster for all other cases, and I switched this one for consistency. But as noted in http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=f3f1ccfd that order was on purpose for performance reasons. I'll push the attached. Thanks for the quick fix.
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
[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_prohibit_canonicalize_without_use] Error 1 I will push this patch first thing after the gnulib update commit. Jim From 47a967b38b858610efdddc393b4ffc3d07b7e5d7 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Tue, 22 Sep 2009 19:43:23 +0200 Subject: [PATCH] maint: df.c: adapt to newer gnulib * src/df.c: Don't include canonicalize.h. No longer needed, since canonicalize_file_name is now guaranteed to be declared in stdlib.h, thanks to gnulib. --- src/df.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/src/df.c b/src/df.c index aef7b2d..fd59aea 100644 --- a/src/df.c +++ b/src/df.c @@ -24,7 +24,6 @@ #include getopt.h #include system.h -#include canonicalize.h #include error.h #include fsusage.h #include human.h -- 1.6.5.rc1.220.g6de7f
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: Something is not true by default, or when option --foo is given. What might be okay: Using color to distinguish types of files is disabled by default and also\n\ when --color=never is specified. But I would prefer to be perfectly clear: Using color to distinguish types of files is disabled by default. It is\n\ also disabled when --color=never is specified. Benno -- http://www.fastmail.fm - Accessible with your email software or over the web
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 quite grammatical. Paraphrased: Something is not true by default, or when option --foo is given. What might be okay: Using color to distinguish types of files is disabled by default and also\n\ when --color=never is specified. But I would prefer to be perfectly clear: Using color to distinguish types of files is disabled by default. It is\n\ also disabled when --color=never is specified. How about this? From 4f8b0ca317382a51317060f01350d523e88bb360 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Tue, 22 Sep 2009 20:53:35 +0200 Subject: [PATCH] doc: ls: further improve --help message re --color * src/ls.c (usage): Correct grammar, change voice, shorten. Inspired by a report from Bruno Schulenberg. --- src/ls.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/ls.c b/src/ls.c index 859d7c4..54a4486 100644 --- a/src/ls.c +++ b/src/ls.c @@ -4671,9 +4671,9 @@ Mandatory arguments to long options are mandatory for short options too.\n\ emit_size_note (); fputs (_(\ \n\ -Using color to distinguish types of files is not enabled by default, or when\n\ ---color=never is specified. With --color=auto, color codes are output only\n\ -when standard output is connected to a terminal. The LS_COLORS environment\n\ +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 LS_COLORS environment\n\ variable can change the settings. Use the dircolors command to set it.\n\ ), stdout); fputs (_(\ -- 1.6.5.rc1.220.g6de7f
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 gscriv...@gnu.org writes:
This patch changes `tail' to handle stdin separately from inotify
events, similar to what we are already doing when a --pid is specified.
Regards,
Giuseppe
From f3010bebf9e25be9a83868b4ad9db2cc6cb6613f Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano gscriv...@gnu.org
Date: Mon, 7 Sep 2009 16:35:16 +0200
Subject: [PATCH] tail: handle - properly
* src/tail.c (tail_forever_inotify): Handle stdin (i.e., -, but not
/dev/stdin) separately from inotify.
* tests/tail-2/wait: Ensure that when a stdin is watched, tail does not
raise errors.
---
src/tail.c| 176
++---
tests/tail-2/wait |6 ++
2 files changed, 119 insertions(+), 63 deletions(-)
diff --git a/src/tail.c b/src/tail.c
index e3b9529..b817ecb 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -134,7 +134,7 @@ struct File_spec
int errnum;
#if HAVE_INOTIFY
- /* The watch descriptor used by inotify. */
+ /* The watch descriptor used by inotify, -1 on error, -2 if stdin. */
int wd;
/* The parent directory watch descriptor. It is used only
@@ -1184,6 +1184,7 @@ tail_forever_inotify (int wd, struct File_spec *f,
size_t n_files,
char *evbuf;
size_t evbuf_off = 0;
size_t len = 0;
+ struct File_spec *stdin_spec = NULL;
wd_table = hash_initialize (n_files, NULL, wd_hasher, wd_comparator, NULL);
if (! wd_table)
@@ -1196,6 +1197,34 @@ tail_forever_inotify (int wd, struct File_spec *f,
size_t n_files,
{
if (!f[i].ignore)
{
+ if (STREQ (f[i].name, -))
+{
+ int old_flags = fcntl (f[i].fd, F_GETFL);
+ int new_flags = old_flags | O_NONBLOCK;
+
+ stdin_spec = f[i];
+ found_watchable = true;
+
+ if (old_flags 0
+ || (new_flags != old_flags
+ fcntl (f[i].fd, F_SETFL, new_flags) == -1))
+{
+ /* Don't update f[i].blocking if fcntl fails. */
+ if (S_ISREG (f[i].mode) errno == EPERM)
+{
+ /* This happens when using tail -f on a file with
+ the append-only attribute. */
+}
+ else
+error (EXIT_FAILURE, errno,
+ _(%s: cannot change stdin nonblocking mode));
+}
+ f[i].blocking = false;
+ f[i].wd = -2;
+ prev_wd = f[i].wd;
+ continue;
+}
+
size_t fnlen = strlen (f[i].name);
if (evlen fnlen)
evlen = fnlen;
@@ -1235,6 +1264,8 @@ tail_forever_inotify (int wd, struct File_spec *f,
size_t n_files,
continue;
}
+ prev_wd = f[i].wd;
+
if (hash_insert (wd_table, (f[i])) == NULL)
xalloc_die ();
@@ -1245,8 +1276,6 @@ tail_forever_inotify (int wd, struct File_spec *f,
size_t n_files,
if (follow_mode == Follow_descriptor !found_watchable)
return;
- prev_wd = f[n_files - 1].wd;
-
evlen += sizeof (struct inotify_event) + 1;
evbuf = xmalloc (evlen);
@@ -1259,12 +1288,12 @@ tail_forever_inotify (int wd, struct File_spec *f,
size_t n_files,
struct File_spec *fspec;
uintmax_t bytes_read;
struct stat stats;
-
+ bool check_stdin = false;
struct inotify_event *ev;
- /* When watching a PID, ensure that a read from WD will not block
- indefinetely. */
- if (pid)
+ /* When watching a PID or stdin, ensure that a read from WD will not
block
+ indefinitely. */
+ if (pid || stdin_spec)
{
fd_set rfd;
struct timeval select_timeout;
@@ -1284,78 +1313,92 @@ tail_forever_inotify (int wd, struct File_spec *f,
size_t n_files,
if (n_descriptors == 0)
{
- /* See if the process we are monitoring is still alive. */
- if (kill (pid, 0) != 0 errno != EPERM)
-exit (EXIT_SUCCESS);
+ if (stdin_spec)
+check_stdin = true;
+ if (pid)
+{
+ /* See if the process we are monitoring is still alive. */
+ if (kill (pid, 0) != 0 errno != EPERM)
+exit (EXIT_SUCCESS);
- continue;
+ if (!check_stdin)
+continue;
+}
}
}
- if (len = evbuf_off)
+ if (check_stdin)
{
- len = safe_read (wd, evbuf, evlen);
- evbuf_off = 0;
-
- /* For kernels prior to 2.6.21,
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 Giuseppe, 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 at all. Is there a good reason to want to avoid the sleep-based code in this corner case? Subject: [PATCH] tail: handle - properly * src/tail.c (tail_forever_inotify): Handle stdin (i.e., -, but not /dev/stdin) separately from inotify. * tests/tail-2/wait: Ensure that when a stdin is watched, tail does not raise errors. BTW, that log message is out of date. tail -f handles - now, via the sleep-based implementation. Summarizing what this patch does: it changes e.g., tail -f - F1 F2 F3 not to revert to the sleep-based implementation solely due to the presence of an unnamed (stdin) file, -. Instead, the files F1, F2, F3 would still be tracked efficiently via inotify, and stdin would be tracked via a select-based wait.
Re: ls --help: further tweak
On Tue, 22 Sep 2009 20:53 +0200, Jim Meyering j...@meyering.net 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 before the comma describes a situation, the understood is disabled after the comma describes an action. In my head this grates. But maybe this is just my Dutch shimmering through: there different verbs are needed for those two things (is uitgeschakeld, wordt uitgeschakeld). Using color is disabled by default, and (is disabled) with --color=never. The grating gets less but not nil when putting in an also: Using color is disabled by default, and also with --color=never. Benno -- http://www.fastmail.fm - Access all of your messages and folders wherever you are
Re: ls --help: further tweak
Benno Schulenberg wrote: On Tue, 22 Sep 2009 20:53 +0200, Jim Meyering j...@meyering.net 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 before the comma describes a situation, the understood is disabled after the comma describes an action. In my head this grates. But maybe this is just my Dutch shimmering through: there different verbs are needed for those two things (is uitgeschakeld, wordt uitgeschakeld). Using color is disabled by default, and (is disabled) with --color=never. The grating gets less but not nil when putting in an also: Using color is disabled by default, and also with --color=never. It did feel a little awkward. One more iteration: From 24d0b21efd42bdcec937d5c0ba2944b3e2fe96f4 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Tue, 22 Sep 2009 20:53:35 +0200 Subject: [PATCH] doc: ls: further improve --help message re --color * src/ls.c (usage): Correct grammar, change voice, shorten. Inspired by a report from Bruno Schulenberg. --- src/ls.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/ls.c b/src/ls.c index 859d7c4..28fc3e5 100644 --- a/src/ls.c +++ b/src/ls.c @@ -4671,9 +4671,9 @@ Mandatory arguments to long options are mandatory for short options too.\n\ emit_size_note (); fputs (_(\ \n\ -Using color to distinguish types of files is not enabled by default, or when\n\ ---color=never is specified. With --color=auto, color codes are output only\n\ -when standard output is connected to a terminal. The LS_COLORS environment\n\ +Using color to distinguish file types is disabled both by default and\n\ +with --color=never. With --color=auto, ls emits color codes only when\n\ +standard output is connected to a terminal. The LS_COLORS environment\n\ variable can change the settings. Use the dircolors command to set it.\n\ ), stdout); fputs (_(\ -- 1.6.5.rc1.220.g6de7f
Re: Bug#545422: coreutils: tail -f - fails
Jim Meyering j...@meyering.net 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 at all. Is there a good reason to want to avoid the sleep-based code in this corner case? In my opinion, it is desiderable that tail works approximately in the same way when stdin is specified, as we are already doing with --pid. If we decide to handle this too, there will not be any known case that the inotify back-end doesn't support. Summarizing what this patch does: it changes e.g., tail -f - F1 F2 F3 not to revert to the sleep-based implementation solely due to the presence of an unnamed (stdin) file, -. Instead, the files F1, F2, F3 would still be tracked efficiently via inotify, and stdin would be tracked via a select-based wait. Exactly. Giuseppe
Re: summarizing gnulib changes for coreutils-7.7?
Jim Meyering jim at 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 within the next 24 hours.
From 6a3f1d2c746f9520f25ff07fb9f4c7387fbb0978 Mon Sep 17 00:00:00 2001
From: Eric Blake e...@byu.net
Date: Tue, 22 Sep 2009 15:03:02 -0600
Subject: [PATCH 1/2] readlink: pick up gnulib changes to readlink -f
* bootstrap.conf (obsolete_gnulib_modules): Move rename...
(gnulib_modules): ...here. Add symlink.
* NEWS: Document the change in readlink.
* doc/coreutils.texi (readlink invocation): Likewise.
* tests/readlink/can-f: Update test to new semantics, and add test
of loop.
---
NEWS |4
bootstrap.conf |3 ++-
doc/coreutils.texi |6 --
gnulib |2 +-
tests/readlink/can-f | 36 ++--
5 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/NEWS b/NEWS
index 270aa85..35c4966 100644
--- a/NEWS
+++ b/NEWS
@@ -18,6 +18,10 @@ GNU coreutils NEWS-*-
outline -*-
** Changes in behavior
+ canonicalize -f now ignores a trailing slash when deciding if the
+ last component (possibly via a dangling symlink) can be created,
+ since mkdir will succeed in that case.
+
id no longer prints SELinux context=... when the POSIXLY_CORRECT
environment variable is set.
diff --git a/bootstrap.conf b/bootstrap.conf
index fb5ed15..d1dc128 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -31,7 +31,6 @@ obsolete_gnulib_modules='
memcpy
memmove
memset
- rename
strcspn
strtod
strtol
@@ -177,6 +176,7 @@ gnulib_modules=
readutmp
realloc
regex
+ rename
rename-dest-slash
rmdir
root-dev-ino
@@ -203,6 +203,7 @@ gnulib_modules=
strtoimax
strtoumax
strverscmp
+ symlink
sys_stat
timespec
tzset
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index fa05626..0bfbd56 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -9204,7 +9204,8 @@ readlink invocation
@opindex --canonicalize
Activate canonicalize mode.
If any component of the file name except the last one is missing or
unavailable,
-...@command{readlink} produces no output and exits with a nonzero exit code.
+...@command{readlink} produces no output and exits with a nonzero exit
+code. A trailing slash is ignored.
@item -e
@itemx --canonicalize-existing
@@ -9212,7 +9213,8 @@ readlink invocation
@opindex --canonicalize-existing
Activate canonicalize mode.
If any component is missing or unavailable, @command{readlink} produces
-no output and exits with a nonzero exit code.
+no output and exits with a nonzero exit code. A trailing slash
+requires that the name resolve to a directory.
@item -m
@itemx --canonicalize-missing
diff --git a/gnulib b/gnulib
index 6c9f1e8..d34f1e7 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit 6c9f1e88ada406b65f6b10098b8c9e60c973e614
+Subproject commit d34f1e73508874213f8ac588f7a7d6d8f62854c3
diff --git a/tests/readlink/can-f b/tests/readlink/can-f
index 8a000f8..a702ba9 100755
--- a/tests/readlink/can-f
+++ b/tests/readlink/can-f
@@ -38,6 +38,7 @@ ln -s regfile link1 || framework_failure
ln -s subdir link2 || framework_failure
ln -s missing link3 || framework_failure
ln -s subdir/missing link4 || framework_failure
+ln -s link5 link5 || framework_failure
cd $pwd/$tmp/removed || framework_failure
@@ -73,14 +74,14 @@ for p in $pwd/$tmp/; do
v=`readlink -f ${p}subdir/more` || fail=1
test $v = $my_pwd/$tmp/subdir/more || fail=1
- v=`readlink -f ${p}./subdir/more/` fail=1
- test -z $v || fail=1
+ v=`readlink -f ${p}./subdir/more/` || fail=1
+ test $v = $my_pwd/$tmp/subdir/more || fail=1
v=`readlink -f ${p}missing` || fail=1
test $v = $my_pwd/$tmp/missing || fail=1
- v=`readlink -f ${p}./missing/` fail=1
- test -z $v || fail=1
+ v=`readlink -f ${p}./missing/` || fail=1
+ test $v = $my_pwd/$tmp/missing || fail=1
v=`readlink -f ${p}missing/more` fail=1
test -z $v || fail=1
@@ -109,8 +110,8 @@ for p in $pwd/$tmp/; do
v=`readlink -f ${p}link2/more` || fail=1
test $v = $my_pwd/$tmp/subdir/more || fail=1
- v=`readlink -f ${p}./link2/more/` fail=1
- test -z $v || fail=1
+ v=`readlink -f ${p}./link2/more/` || fail=1
+ test $v = $my_pwd/$tmp/subdir/more || fail=1
v=`readlink -f ${p}link2/more/more2` fail=1
test -z $v || fail=1
@@ -121,8 +122,8 @@ for p in $pwd/$tmp/; do
v=`readlink -f ${p}link3` || fail=1
test $v = $my_pwd/$tmp/missing || fail=1
- v=`readlink -f ${p}./link3/` fail=1
- test -z $v || fail=1
+ v=`readlink -f ${p}./link3/` || fail=1
+ test $v = $my_pwd/$tmp/missing || fail=1
v=`readlink -f ${p}link3/more` fail=1
test -z $v || fail=1
@@ -133,11 +134,26 @@ for p in $pwd/$tmp/; do
v=`readlink -f ${p}link4` || fail=1
Re: Bug#545422: coreutils: tail -f - fails
Giuseppe Scrivano gscriv...@gnu.org 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 http://www.mail-archive.com/bug-coreutils@gnu.org/msg17684.html is added to the Linux kernel, I suggest that coreutils modify the code to use 'inotify_add_watch_fd' instead of the current 'inotify_add_watch'. This will let tail watch stdin just like it can watch any other file descriptor. An added benefit of the fd approach is that it will fix a race condition in the current code, if a file is renamed between the call to 'open' and the call to 'inotify_add_watch_fd'. It should also simplify the tail code considerably to use an file-descriptor-based approach. In the meantime I would just leave the code alone; no sense wasting much time maintaining the inferior kernel interface.
