Re: link -L/-P

2009-09-25 Thread Pádraig Brady
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

2009-09-25 Thread Jim Meyering
Eric Blake wrote:
 Eric Blake ebb9 at 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

2009-09-25 Thread Guenter Knauf
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)

2009-09-25 Thread Eric Blake
-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 e...@byu.net
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

2009-09-25 Thread Ondřej Vašík
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?= ova...@redhat.com
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. 12; }
+
 Exit $fail
-- 
1.5.6.1.156.ge903b



signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy


Re: stdbuf enhancement

2009-09-25 Thread Jim Meyering
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

2009-09-25 Thread Paul Eggert
Ondřej Vašík ova...@redhat.com 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

2009-09-25 Thread Pádraig Brady
Paul Eggert wrote:
 Ondřej Vašík ova...@redhat.com 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

2009-09-25 Thread Jim Meyering
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