Re: link -L/-P
Eric Blake wrote: > According to Pádraig Brady on 9/24/2009 5:13 PM: >> Eric Blake wrote: > >>> + -L, --logical make hard links to symbolic link >>> references\n\ >> s/references/targets/ is a bit clearer to me? > > I thought about that, but we already specify: > > ln source target > > as the synopsis, so I didn't want to confuse target (the file being > created) with target (the contents of the symlink being linked through). > >>> + -P, --physical make hard links directly to symblic links\n\ >> s/symblic/symbolic/ > > Thanks. I folded that in, then added a patch to fix copy.c to use linkat > (pushed). I also noticed a cleanup for stdbuf while searching through > instances of 'link (', although I haven't been able to test that yet, > since stdbuf doesn't compile on cygwin. I've pushed my work to: > > git pull git://repo.or.cz/coreutils/ericb.git master > > to make it easier to review. > You need to chmod a+x ln/hard-to-sym Also your stdbuf cleanup needs the following. (I was wary about passing NULL into access()) cheers, Pádraig. diff --git a/bootstrap.conf b/bootstrap.conf index f648e22..475ed8f 100644 --- a/bootstrap.conf +++ b/bootstrap.conf @@ -43,6 +43,7 @@ gnulib_modules=" acl alloca announce-gen + areadlink areadlink-with-size argmatch argv-iter diff --git a/src/stdbuf.c b/src/stdbuf.c index c33cdfa..383003c 100644 --- a/src/stdbuf.c +++ b/src/stdbuf.c @@ -28,6 +28,8 @@ #include "quote.h" #include "xstrtol.h" #include "c-ctype.h" +#include "areadlink.h" +#include "filenamecat.h" /* The official name of this program (e.g., no `g' prefix). */ #define PROGRAM_NAME "stdbuf" @@ -154,8 +156,8 @@ set_program_path (const char *arg) path = xstrdup (path); for (dir = strtok (path, ":"); dir != NULL; dir = strtok (NULL, ":")) { - char *candidate = file_name_concat (dir, arg); - if (access (candidate, X_OK) == 0) + char *candidate = file_name_concat (dir, arg, NULL); + if (candidate && access (candidate, X_OK) == 0) { program_path = dir_name (candidate); free (candidate);
Re: link -L/-P
Also " path " in your -P description in coreutils.texi is causing doc/Makefile.am::check-texinfo to fail I'll leave it to you to reword (or change the check) cheers, Pádraig.
Re: link -L/-P
Eric Blake wrote: > Eric Blake byu.net> writes: > >> > I'd like to make a test release soon. Maybe as soon as Friday. >> > If you have something that you'd like included, please speak up. >> >> I'm nearly ready to post support for ln -P/-L, thanks to the pending addition >> of gnulib linkat(). That would be nice to have in the release. > > How does this look? Looks fine. Thanks! One nit: ... > diff --git a/doc/coreutils.texi b/doc/coreutils.texi > index 0bfbd56..e7cf5ea 100644 > --- a/doc/coreutils.texi > +++ b/doc/coreutils.texi > @@ -8753,6 +8753,11 @@ link invocation > not specified by @acronym{POSIX}, and the @command{link} command is > more portable in practice. > > +If @var{filename} is a symbolic link, it is unspecified whether > +...@var{linkname} will be a hard link to the symbolic link or to the > +target of the symbolic link. Use @command{ln -P} or @command{ln -L} > +specify which behavior is desired. s/^specify/to specify/
[FEATURE_REQUEST] support openssl checksum format too
Hi all, suprisingly I just found that md5sum and sha1sum also accept the formats of the md5 and sha1 tools as input with option -c. There's though a third checksum format which is produced by the openssl tool which only slightly differs to the format from md5 and sha1 - two blanks are missing ... output of 'md5 file': MD5 (httpd-2.2.14.tar.bz2) = a5226203aaf97e5b941c41a71c112704 output of 'openssl md5 file': MD5(httpd-2.2.14.tar.bz2)= a5226203aaf97e5b941c41a71c112704 output of 'sha1 file': SHA1 (httpd-2.2.14.tar.bz2) = eacd04c87b489231ae708c84a77dc8e9ee176fd2 output of 'openssl md5 file': SHA1(httpd-2.2.14.tar.bz2)= eacd04c87b489231ae708c84a77dc8e9ee176fd2 I think that it cant be hard to make md5sum and sha1sum accept the openssl format too. thanks, Günter.
stdbuf enhancement (was: link -L/-P)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Pádraig Brady on 9/25/2009 4:11 AM: > > You need to chmod a+x ln/hard-to-sym Oops. Yeah. Serves me right for testing on cygwin 1.5 (cygwin 1.7 fixed that bug, so that a script now has to be executable to run it). > Also " path " in your -P description in coreutils.texi > is causing doc/Makefile.am::check-texinfo to fail s/path/file name/ fixed that. > > Also your stdbuf cleanup needs the following. > (I was wary about passing NULL into access()) I should have used xreadlink, not areadlink, for ENOMEM. But file_name_concat guarantees non-NULL results (it calls xalloc-die on ENOMEM, and there are no other failure paths), so there was no risk of calling access(NULL). Hmm, should we be using euidaccess instead of access? Also, Jim, should we add a maintainer check that ensures we always use [ax]readlink rather than raw readlink? I've folded in your suggestions. I pushed ln and copy.c changes to master, but left stdbuf changes only on my own repo. git pull git://repo.or.cz/coreutils/ericb.git master - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq8wz0ACgkQ84KuGfSFAYC8mQCgvvTDvYEyo9a+wS3Y9zE9Z+ZE R7cAniLaXbQl92mCCw8K6Z2o3D36QUm+ =a82d -END PGP SIGNATURE- >From 7a31f56455d10a9467bbb688093302875c9dff09 Mon Sep 17 00:00:00 2001 From: Eric Blake Date: Thu, 24 Sep 2009 17:18:47 -0600 Subject: [PATCH] stdbuf: improve path search * src/stdbuf.c (set_program_path): Use gnulib methods for better file name handling. * bootstrap.conf (gnulib_modules): Add xreadlink. --- bootstrap.conf |1 + src/stdbuf.c | 28 +++- 2 files changed, 12 insertions(+), 17 deletions(-) diff --git a/bootstrap.conf b/bootstrap.conf index f648e22..c9ce36f 100644 --- a/bootstrap.conf +++ b/bootstrap.conf @@ -236,6 +236,7 @@ gnulib_modules=" xnanosleep xprintf xprintf-posix + xreadlink xstrtod xstrtoimax xstrtol diff --git a/src/stdbuf.c b/src/stdbuf.c index afb7821..05a6b9f 100644 --- a/src/stdbuf.c +++ b/src/stdbuf.c @@ -24,8 +24,10 @@ #include "system.h" #include "error.h" +#include "filenamecat.h" #include "posixver.h" #include "quote.h" +#include "xreadlink.h" #include "xstrtol.h" #include "c-ctype.h" @@ -145,34 +147,26 @@ set_program_path (const char *arg) } else { - char *path; - char tmppath[PATH_MAX + 1]; - ssize_t len = readlink ("/proc/self/exe", tmppath, sizeof (tmppath) - 1); - if (len > 0) -{ - tmppath[len] = '\0'; - program_path = dir_name (tmppath); -} + char *path = xreadlink ("/proc/self/exe"); + if (path) +program_path = dir_name (path); else if ((path = getenv ("PATH"))) { char *dir; path = xstrdup (path); for (dir = strtok (path, ":"); dir != NULL; dir = strtok (NULL, ":")) { - int req = snprintf (tmppath, sizeof (tmppath), "%s/%s", dir, arg); - if (req >= sizeof (tmppath)) -{ - error (0, 0, _("path truncated when looking for %s"), - quote (arg)); -} - else if (access (tmppath, X_OK) == 0) + char *candidate = file_name_concat (dir, arg, NULL); + if (access (candidate, X_OK) == 0) { - program_path = dir_name (tmppath); + program_path = dir_name (candidate); + free (candidate); break; } + free (candidate); } - free (path); } + free (path); } } -- 1.6.5.rc1
[PATCH]: ls: do not show long iso time format for en_* locales
Hello, as reported in https://bugzilla.redhat.com/show_bug.cgi?id=525134 by Daniel Qarras, ls -l shows iso long format for en_* locales. This is caused by http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=6837183d42a0ccdf7b7106794ea693c5b609aea5 . After that commit ls in locale time style checks if the translation differs from defaults. If not, it fallbacks to long iso time style format. However - for english locales is this default time style format (same as C) expected, so the check for missing translation is wrong. Attached patch should fix this, allowing the default timestyle for en_* locales. However - I guess it would be maybe better to remove the check for possibly messed translation completely - as the default time-style (the same as C style) could be in use in more LC_TIME styles and fallback to C style for locales with missing translation is not that bad behaviour (imho better than long iso style). Greetings, Ondřej Vašík From e82f581055af6eadcf3e99ff7aa3f5f3479c7c22 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Ond=C5=99ej=20Va=C5=A1=C3=ADk?= Date: Fri, 25 Sep 2009 15:20:47 +0200 Subject: [PATCH] ls: do not show long iso time format for en_* locales * src/ls.c (decode_switches): Do not fallback to long iso time format for en_* locales. Introduced by commit 6837183d, 11-08-2005 and reported in https://bugzilla.redhat.com/show_bug.cgi?id=525134 by Daniel Qarras. * tests/misc/ls-time: test it * NEWS: mention it --- NEWS |3 +++ src/ls.c |8 ++-- tests/misc/ls-time |7 +++ 3 files changed, 16 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 1571c9c..502355a 100644 --- a/NEWS +++ b/NEWS @@ -16,6 +16,9 @@ GNU coreutils NEWS-*- outline -*- when the color of a more specific type is disabled. [bug introduced in coreutils-5.90] + ls -l now correctly show locale timestamp of files instead of long iso format + [bug introduced in coreutils-6.0] + ** Portability On Solaris 9, many commands would mistakenly treat file/ the same as diff --git a/src/ls.c b/src/ls.c index 1bb6873..3a1d2d1 100644 --- a/src/ls.c +++ b/src/ls.c @@ -2027,13 +2027,17 @@ decode_switches (int argc, char **argv) if (hard_locale (LC_TIME)) { /* Ensure that the locale has translations for both - formats. If not, fall back on long-iso format. */ + formats (translation differs from default). If not, + fall back on long-iso format, unless unchanged + format is expected (for english locales). */ int i; +const char *lc_time = setlocale (LC_TIME, NULL); for (i = 0; i < 2; i++) { char const *locale_format = dcgettext (NULL, long_time_format[i], LC_TIME); -if (locale_format == long_time_format[i]) +if (lc_time && strncmp(lc_time, "en_", 3) && +locale_format == long_time_format[i]) goto case_long_iso_time_style; long_time_format[i] = locale_format; } diff --git a/tests/misc/ls-time b/tests/misc/ls-time index abdd429..86868a7 100755 --- a/tests/misc/ls-time +++ b/tests/misc/ls-time @@ -123,4 +123,11 @@ EOF fail=1 fi +# The output for english locale should differ from long iso format +# This failed between 6.0 and 7.7 +LC_ALL=en_US ls -l c >en_output +ls -l --time-style=long-iso c >liso_output +compare en_output liso_output && { fail=1; + echo "Long format timestamp for en_US locale is same as for long iso." 1>&2; } + Exit $fail -- 1.5.6.1.156.ge903b signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: stdbuf enhancement
Eric Blake wrote: ... > Also, Jim, should we add a maintainer check that ensures we always use > [ax]readlink rather than raw readlink? Good idea.
Re: [PATCH]: ls: do not show long iso time format for en_* locales
Ondřej Vašík writes: > as reported in https://bugzilla.redhat.com/show_bug.cgi?id=525134 by > Daniel Qarras, ls -l shows iso long format for en_* locales. I just now read that Bugzilla report, and the diagnosis and the patch do not seem correct. The diagnosis says: > In ls.c (case locale_time_style) is dcgettext (NULL, long_time_format[i], > LC_TIME); ... that translates the string, but the translation is THE SAME as > the default - as the format is the same for en_* locales. But that is not what the ls.c source code does. The code does this: char const *locale_format = dcgettext (NULL, long_time_format[i], LC_TIME); if (locale_format == long_time_format[i]) goto case_long_iso_time_style; The "==" test returns true when dcgettext returns the msgid (its 2nd argument) because it finds no translation. If it found a translation, dcgettext would return a different string, so the "==" test would return false, and the code would use the translation. Even if the translation has the same _contents_ as the msgid, it will have a different _address_, so the code is correct as-is and does not need this modification. Also, the proposed patch would use U.S. styles for all English locales, which certainly is not right. I suspect the diagnosis given by Jim Meyering in comment #3 at that bug report is correct, and that something is going wrong at install time.
Re: [PATCH]: ls: do not show long iso time format for en_* locales
Paul Eggert wrote: > Ondřej Vašík writes: > >> as reported in https://bugzilla.redhat.com/show_bug.cgi?id=525134 by >> Daniel Qarras, ls -l shows iso long format for en_* locales. > > I just now read that Bugzilla report, and the diagnosis and the > patch do not seem correct. The diagnosis says: > >> In ls.c (case locale_time_style) is dcgettext (NULL, long_time_format[i], >> LC_TIME); ... that translates the string, but the translation is THE SAME as >> the default - as the format is the same for en_* locales. > > But that is not what the ls.c source code does. The code does this: > > char const *locale_format = > dcgettext (NULL, long_time_format[i], LC_TIME); > if (locale_format == long_time_format[i]) > goto case_long_iso_time_style; > > The "==" test returns true when dcgettext returns the msgid (its 2nd > argument) because it finds no translation. Right. We don't have any translations for "en". I noticed this previously and assumed it was on purpose. I.E. we can override the default time style by providing an en "translation" for the time formats. Note one can't use LC_TIME=C to set the format, as that will also cause nl_langinfo to lookup the abbreviated months in that locale. I.E. the following would show english abbreviations: LC_TIME=C LANG=fr_FR.utf8 ls -l What I do is to set TIME_STYLE as follows: # traditional unix time format with abbreviated month translated from locale export TIME_STYLE='+%b %e %Y %b %e %H:%M' cheers, Pádraig.
Re: [FEATURE_REQUEST] support openssl checksum format too
Guenter Knauf wrote: > suprisingly I just found that md5sum and sha1sum also accept the formats > of the md5 and sha1 tools as input with option -c. There's though a > third checksum format which is produced by the openssl tool which only > slightly differs to the format from md5 and sha1 - two blanks are > missing ... > output of 'md5 file': > MD5 (httpd-2.2.14.tar.bz2) = a5226203aaf97e5b941c41a71c112704 > output of 'openssl md5 file': > MD5(httpd-2.2.14.tar.bz2)= a5226203aaf97e5b941c41a71c112704 > output of 'sha1 file': > SHA1 (httpd-2.2.14.tar.bz2) = eacd04c87b489231ae708c84a77dc8e9ee176fd2 > output of 'openssl md5 file': > SHA1(httpd-2.2.14.tar.bz2)= eacd04c87b489231ae708c84a77dc8e9ee176fd2 > > I think that it cant be hard to make md5sum and sha1sum accept the > openssl format too. But it's even easier to convert openssl's format into one that is recognized. Filter it through this: sed 's/(/ (/;s/\(= [0-9a-f]*\)$/ \1/' E.g., $ touch f; openssl md5 f MD5(f)= d41d8cd98f00b204e9800998ecf8427e $ openssl md5 f | sed 's/(/ (/;s/\(= [0-9a-f]*\)$/ \1/' MD5 (f) = d41d8cd98f00b204e9800998ecf8427e