Re: readlink(1) behavior
On Thu, Sep 10, 2009 at 07:29:35PM +0200, Jim Meyering wrote: Eric Blake wrote: I think there are some infelicities in the canonicalization options of readlink. readlink -fv file/= correctly reports ENOTDIR readlink -fv missing = lists /path/to/missing readlink -fv missing/ = complains that missing is not a dir readlink -mv file/= lists /path/to/file readlink -mv missing/ = lists /path/to/missing I would like to see: 'readlink -fv missing/' list '/path/to/missing', on the grounds that one could do 'mkdir missing' to bring the path into existence; this matches the documentation that -f ignores a missing final element (nowhere does it say the final element has to be a non-file). Yes, that makes sense. Yes, but there is a corner case: I think that 'readlink -fv broken_symlink/' behavior should not change. Also, I think that -m should either be changed to reject paths that cannot possibly exist given the current state of the file system (that is, in the above case, 'readlink -mv file/' should fail with ENOTDIR), or we should create a new option (in bewteen -f and -m) with that property. For an example of how this mode might be useful: Suppose we want to test whether 'mkdir -p a/b touch a/b/c' will succeed, without creating directories if it won't. 'readlink -f a/b/c' is insufficient, since a/b might not yet exist. 'readlink -m a/b/c' is insufficient, because 'a' might be a regular file or a symlink to itself. Maybe such an option can be named -p/--possible. A new option for this new mode looks more appropriate, I'd like to see old -m behavior unchanged for backwards compatibility. -- ldv pgpcc3B9b5R5y.pgp Description: PGP signature
Re: readlink(1) behavior
Dmitry V. Levin wrote: On Thu, Sep 10, 2009 at 07:29:35PM +0200, Jim Meyering wrote: Eric Blake wrote: I think there are some infelicities in the canonicalization options of readlink. readlink -fv file/= correctly reports ENOTDIR readlink -fv missing = lists /path/to/missing readlink -fv missing/ = complains that missing is not a dir readlink -mv file/= lists /path/to/file readlink -mv missing/ = lists /path/to/missing I would like to see: 'readlink -fv missing/' list '/path/to/missing', on the grounds that one could do 'mkdir missing' to bring the path into existence; this matches the documentation that -f ignores a missing final element (nowhere does it say the final element has to be a non-file). Yes, that makes sense. Yes, but there is a corner case: I think that 'readlink -fv broken_symlink/' behavior should not change. Building coreutils to use the very latest from gnulib, this has indeed just changed. Not deliberately, it appears. Assuming ln -s /nowhere dangling-symlink, New behavior: $ ./readlink -fv dangling-symlink/ /nowhere Previous: $ readlink -fv dangling-symlink/ readlink: dangling-symlink/: No such file or directory [Exit 1] Also, I think that -m should either be changed to reject paths that cannot possibly exist given the current state of the file system (that is, in the above case, 'readlink -mv file/' should fail with ENOTDIR), or we should create a new option (in bewteen -f and -m) with that property. For an example of how this mode might be useful: Suppose we want to test whether 'mkdir -p a/b touch a/b/c' will succeed, without creating directories if it won't. 'readlink -f a/b/c' is insufficient, since a/b might not yet exist. 'readlink -m a/b/c' is insufficient, because 'a' might be a regular file or a symlink to itself. Maybe such an option can be named -p/--possible. A new option for this new mode looks more appropriate, I'd like to see old -m behavior unchanged for backwards compatibility. Right. IMHO there is no justification to change existing behavior.
feature request: sleep --random
This would help with some work I'm doing today, but is it of general interest? $ sleep --random 4.0 sleeps for a random amount of time up to and including the requested value. The purpose is that on distributed systems it's disruptive to have synchronized scripts all starting up together. One option is to use the shell's $RANDOM if available, but it's lot of typing to get true (vs coarsely quantized) randomness. Phil
Re: readlink(1) behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 9/18/2009 4:47 AM: Assuming ln -s /nowhere dangling-symlink, New behavior: $ ./readlink -fv dangling-symlink/ /nowhere Previous: $ readlink -fv dangling-symlink/ readlink: dangling-symlink/: No such file or directory [Exit 1] On one hand: ln -s dangling link = 0 stat dangling/ = ENOENT stat link/ = ENOENT mkdir link/ = 0 the behavior is consistent - a single mkdir can create the lone missing element in the (expanded) pathname. If we really claim that -f implies that a missing last element is acceptable if it can be created by the same name, then that explains the new behavior. On the other hand, continuing the above example, there are some Linux interfaces which distinguish between a dangling symlink with trailing slash compared to a missing file with trailing slash: rmdir link/ = ENOTDIR rmdir dangling/ rmdir dangling/ = ENOENT rmdir link/ = ENOTDIR This difference does not exist on Solaris (which follows the counter-intuitive POSIX rule that the first 'rmdir link/' remove dangling rather than fail with ENOTDIR). So, we need to decide whether I should work on changing the CAN_ALL_BUT_LAST mode to explicitly differentiate between a missing element with a trailing slash (ok) compared to an existing but dangling symlink with a trailing slash (fail, as before this change); or whether the behavior on a dangling symlink with a trailing slash is an intentional change for consistency. Once we make that decision, we either need to patch coreutils' NEWS or I need to fix the regression in gnulib canonicalize. - -- 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/ iEYEARECAAYFAkqzcGgACgkQ84KuGfSFAYCX/gCdFt1ja3jSK+lNjaxjGXsRRwqD Ly0AoKNQr+/DhFU9cTMPftrQxnlNmD3e =cQPt -END PGP SIGNATURE-
Re: feature request: sleep --random
Philip Rowlands wrote: This would help with some work I'm doing today, but is it of general interest? $ sleep --random 4.0 sleeps for a random amount of time up to and including the requested value. The purpose is that on distributed systems it's disruptive to have synchronized scripts all starting up together. One option is to use the shell's $RANDOM if available, but it's lot of typing to get true (vs coarsely quantized) randomness. Be careful with random sleeps: http://www.stdlib.net/~colmmacc/2009/09/14/period-pain/ You're right that the existing is more verbose but it's also more general: sleep $(seq .1 .1 4 | head -n $(($RANDOM%40 +1)) | tail -n1) I'm not sure we should add this. cheers, Pádraig.
Re: feature request: sleep --random
Philip Rowlands wrote: This would help with some work I'm doing today, but is it of general interest? $ sleep --random 4.0 sleeps for a random amount of time up to and including the requested value. The purpose is that on distributed systems it's disruptive to have synchronized scripts all starting up together. One option is to use the shell's $RANDOM if available, but it's lot of typing to get true (vs coarsely quantized) randomness. How about this: sleep $(perl -le 'print rand 4') That should work with more shells, and is smooth.
Seq Segment Fault.
Here is my code.
#!/bin/bash
echo Add directions here.
read URL
read NUM1
read NUM2
read EXT
echo Please choose a folder name.
read NAM
mkdir $HOME/$NAM
cd $HOME/$NAM
for i in $(seq -w $NUM1 $NUM2); do wget $URL${i}$EXT; done
I was testing out my script, and I came across an instance where I had
a large i (it started at 00 and went to 99). It
processed for a few minutes (my poor intel atom) and returned with a
Segmentation fault. From what I know from Assembly, I think this is
a buffer overflow which could allow for malicious code injection.
Please let me know if I can be of further assistance.
--
Peace Out and Rock On,
Ryan Whited
Re: Seq Segment Fault.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ryan Whited on 9/18/2009 4:38 AM: #!/bin/bash for i in $(seq -w $NUM1 $NUM2) Are you sure your segfault is in seq, or is it in bash? You neglected to mention which versions you were using: bash --version seq --version However, it seems to me that your problem is that bash tries to slurp all of $() into memory, and seq generated so much data that bash ran out of memory (or overflowed its stack). In other words, it is not a segfault in seq, but bash that crashed, and because you exceeded the limits of what your machine will support. - -- 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/ iEYEARECAAYFAkqzde8ACgkQ84KuGfSFAYAbHgCgnNr01KRBNuhsC2ifQOEcgx4f okQAn2i/cc4inQM46UOq5WeMAsxJnwpj =s0aj -END PGP SIGNATURE-
Re: feature request: sleep --random
Pádraig Brady wrote: sleep $(seq .1 .1 4 | head -n $(($RANDOM%40 +1)) | tail -n1) Or more concisely using just coreutils logic: sleep $(seq .1 .1 4 | shuf | head -n1) cheers, Pádraig.
Re: readlink(1) behavior
Eric Blake wrote: According to Jim Meyering on 9/18/2009 4:47 AM: Assuming ln -s /nowhere dangling-symlink, New behavior: $ ./readlink -fv dangling-symlink/ /nowhere Previous: $ readlink -fv dangling-symlink/ readlink: dangling-symlink/: No such file or directory [Exit 1] On one hand: ln -s dangling link = 0 stat dangling/ = ENOENT stat link/ = ENOENT mkdir link/ = 0 the behavior is consistent - a single mkdir can create the lone missing element in the (expanded) pathname. If we really claim that -f implies that a missing last element is acceptable if it can be created by the same name, then that explains the new behavior. That sounds reasonable. Of course, non-creatable dangling links still induce failure: $ rm -rf non-dir; touch non-dir $ ln -s non-dir/file dangling $ ./readlink -fv dangling ./readlink: dangling: Not a directory It comes down to weighing the cost of a new option[*] and the risk that this change would break someone's script. Since changing our ability to detect a dangling symlink might be a security-related issue, I'm leaning towards keeping the existing semantics, just in case. However, it's still nearly a toss-up. Dmitry, what do you think, now? Jim [*] Documenting the subtle difference won't help make the existing options any more understandable.
Re: (man|info) pages and --help
On Thu, 2009-09-17 at 11:59 -0700, Micah Cowan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 C de-Avillez wrote: So. Would it be an acceptable idea to add, to the '--help', a warning that this is *not* the full documentation? Say, like: This is an abridged documentation. The full documentation for blahblah is maintained as a Texinfo manual. If the info and date programs are properly installed at your site, the command info coreutils 'blahblah invocation' should give you access to the complete manual. Is there anyone who's unaware that --help doesn't provide complete documentation? I would not expect anyone to *not* know that help output is abridged. But I would rather have them go straight into 'info' than wasting time on 'man', only to be redirected to 'info'. Usually one looks at the '--help' output first. If we redirect on 'man', why not there? Cheers signature.asc Description: This is a digitally signed message part
Re: feature request: sleep --random
On Fri, 18 Sep 2009, Pádraig Brady wrote: Pádraig Brady wrote: sleep $(seq .1 .1 4 | head -n $(($RANDOM%40 +1)) | tail -n1) Or more concisely using just coreutils logic: sleep $(seq .1 .1 4 | shuf | head -n1) This still has the quantization effects which I'm trying to avoid. Jim's perl suggestion would work well to ensure an even spread over the window of time. $ perl -e 'sleep rand 4' is probably the cleanest / most efficient way to do this with existing tools. Cheers, Phil
Re: (man|info) pages and --help
C de-Avillez wrote: On Thu, 2009-09-17 at 11:59 -0700, Micah Cowan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 C de-Avillez wrote: So. Would it be an acceptable idea to add, to the '--help', a warning that this is *not* the full documentation? Say, like: This is an abridged documentation. The full documentation for blahblah is maintained as a Texinfo manual. If the info and date programs are properly installed at your site, the command info coreutils 'blahblah invocation' should give you access to the complete manual. Is there anyone who's unaware that --help doesn't provide complete documentation? I would not expect anyone to *not* know that help output is abridged. But I would rather have them go straight into 'info' than wasting time on 'man', only to be redirected to 'info'. Usually one looks at the '--help' output first. If we redirect on 'man', why not there? I'm tempted to say add a one-liner, but there are already *four* lines at the end of even the smallest --help output message, e.g., $ sync --help Usage: sync [OPTION] Force changed blocks to disk, update the super block. --help display this help and exit --version output version information and exit Report sync bugs to bug-coreutils@gnu.org GNU coreutils home page: http://www.gnu.org/software/coreutils/ General help using GNU software: http://www.gnu.org/gethelp/ Report sync translation bugs to http://translationproject.org/team/ I guess you'd like to see this added: For complete documentation, run info coreutils 'sync invocation' Maybe. Though I'm tempted to remove the Report ... translation bugs... line when using the C (or maybe all of en_*, too) locale. Other opinions?
Re: Seq Segment Fault.
On Fri, 18 Sep 2009, Eric Blake wrote:
However, it seems to me that your problem is that bash tries to slurp all
of $() into memory, and seq generated so much data that bash ran out of
memory (or overflowed its stack).
It's certainly possible for bash to run out of stack and crash with
SIGSEGV.
$ bash -c 'recurse() { recurse; }; recurse'
Segmentation fault
for i in $(seq -w $NUM1 $NUM2); do wget $URL${i}$EXT; done
This could be rewritten as
seq -w $NUM1 $NUM2 | while read i ; do wget $URL${i}$EXT; done
to prevent all of seq's output having to be buffered at once.
Cheers,
Phil
Re: feature request: sleep --random
Philip Rowlands wrote: On Fri, 18 Sep 2009, Pádraig Brady wrote: Pádraig Brady wrote: sleep $(seq .1 .1 4 | head -n $(($RANDOM%40 +1)) | tail -n1) Or more concisely using just coreutils logic: sleep $(seq .1 .1 4 | shuf | head -n1) This still has the quantization effects which I'm trying to avoid. Jim's perl suggestion would work well to ensure an even spread over the window of time. $ perl -e 'sleep rand 4' is probably the cleanest / most efficient way to do this with existing tools. right. Note the scheduler is still going to quantize your sleep values, so in practicality your probably not going to get smoother than: sleep $(seq .002 .002 4 | shuf | head -n1) cheers, Pádraig. p.s. That's another use case for sort --range
Re: (man|info) pages and --help
Pádraig Brady wrote: Alfred M. Szmidt wrote: Is there anyone who's unaware that --help doesn't provide complete documentation? I would not expect anyone to *not* know that help output is abridged. But I would rather have them go straight into 'info' than wasting time on 'man', only to be redirected to 'info'. Usually one looks at the '--help' output first. If we redirect on 'man', why not there? Because man pages are secondary on GNU systems, the offical spot has always been info. The redirection is only for convience for old timers who still use man. While that may be the official line, practically nobody reads info pages, and if they do it's indirectly through google. I'd vote for removing the translation help line unconditionally (I notice it's not mentioned in man pages) and replace with: For complete documentation, run: info coreutils '$cmd invocation' Seconded.
Re: (man|info) pages and --help
On Fri, 18 Sep 2009 17:34:31 +0200
Jim Meyering j...@meyering.net wrote:
Pádraig Brady wrote:
Alfred M. Szmidt wrote:
Is there anyone who's unaware that --help doesn't provide
complete documentation?
I would not expect anyone to *not* know that help output is
abridged. But I would rather have them go straight into 'info'
than wasting time on 'man', only to be redirected to 'info'.
Usually one looks at the '--help' output first. If we redirect
on 'man', why not there?
Because man pages are secondary on GNU systems, the offical spot
has always been info. The redirection is only for convience for
old timers who still use man.
While that may be the official line, practically nobody reads info
pages, and if they do it's indirectly through google.
I'd vote for removing the translation help line unconditionally
(I notice it's not mentioned in man pages) and replace with:
For complete documentation, run: info coreutils '$cmd invocation'
Seconded.
Is this, then, good?
From c16d6e93cdc94e890ad653d4caa994ea4c315a50 Mon Sep 17 00:00:00 2001
From: C de-Avillez hgg...@ubuntu.com
Date: Fri, 18 Sep 2009 12:16:50 -0500
Subject: [PATCH] --help: link to 'info' for complete docs
* src/system.h:
- take out the translation line
- add a reference to 'info' for complete documentation
---
src/system.h | 13 ++---
1 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/src/system.h b/src/system.h
index a15c298..1ecdcff 100644
--- a/src/system.h
+++ b/src/system.h
@@ -646,17 +646,8 @@ emit_bug_reporting_address (void)
PACKAGE_NAME, PACKAGE);
fputs (_(General help using GNU software: http://www.gnu.org/gethelp/\n),
stdout);
-
- if (hard_locale (LC_MESSAGES))
-{
- /* TRANSLATORS: Replace LANG_CODE in this URL with your language code
- http://translationproject.org/team/LANG_CODE.html to form one of
- the URLs at http://translationproject.org/team/. Otherwise, replace
- the entire URL with your translation team's email address. */
- printf (_(Report %s translation bugs to
-http://translationproject.org/team/\n),
-last_component (program_name));
-}
+ printf (_(For complete documentation, run: info coreutils '%s
invocation'\n),
+ last_component (program_name));
}
#include inttostr.h
--
1.6.3.3
signature.asc
Description: PGP signature
Re: feature request: sleep --random
Pádraig Brady wrote: Pádraig Brady wrote: sleep $(seq .1 .1 4 | head -n $(($RANDOM%40 +1)) | tail -n1) Or more concisely using just coreutils logic: sleep $(seq .1 .1 4 | shuf | head -n1) Or save a pipe+process: sleep $(seq .1 .1 4 | shuf --head=1)
Re: coreutils 7.6 doesn't build on arm
Lluís Batlle wrote:
I'm using glibc 2.9, and gcc 4.3.4, and I can't build coreutils 7.6.
Should I be able to build it?
I get this build error:
gcc -std=gnu99 -I. -g -O2 -c -o mkstemp.o mkstemp.cc
mkstemp.c: In function 'rpl_mkstemp':
mkstemp.c:43: error: too many arguments to function 'gen_tempname'
Thanks for the report.
That is a portability problem
due to changes in gnulib that did not propagate back to
coreutils' copy of the tempname module in it's gl/ hierarchy.
Here's a totally untested patch:
As I type this, I see at least one thing wrong: leading TABs.
Let me know if you'd like a snapshot tarball.
From ff4559c1be30ac77c28a4bf7d14069bd13f96466 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Fri, 18 Sep 2009 23:05:59 +0200
Subject: [PATCH] rebase local copy of tempname module
---
gl/lib/tempname.c | 25 +
gl/lib/tempname.h |5 +++--
2 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/gl/lib/tempname.c b/gl/lib/tempname.c
index 0171516..877ae51 100644
--- a/gl/lib/tempname.c
+++ b/gl/lib/tempname.c
@@ -41,8 +41,7 @@
# define TMP_MAX 238328
#endif
#ifndef __GT_FILE
-# define __GT_FILE 0
-# define __GT_BIGFILE 1
+# define __GT_FILE 1
# define __GT_DIR 2
# define __GT_NOCREATE 3
#endif
@@ -61,12 +60,9 @@
#if _LIBC
# define struct_stat64 struct stat64
-# define small_open __open
-# define large_open __open64
#else
# define struct_stat64 struct stat
-# define small_open open
-# define large_open open
+# define __open open
# define __gen_tempname gen_tempname
# define __getpid getpid
# define __gettimeofday gettimeofday
@@ -171,13 +167,12 @@ static const char letters[] =
__GT_NOCREATE: simply verify that the name does not exist
at the time of the call.
__GT_FILE: create the file using open(O_CREAT|O_EXCL)
-and return a read-write fd. The file is mode 0600.
- __GT_BIGFILE: same as __GT_FILE but use open64().
+ and return a read-write fd. The file is mode 0600.
__GT_DIR: create a directory, which will be mode 0700.
We use a clever algorithm to get hard-to-predict names. */
int
-gen_tempname_len (char *tmpl, int kind, size_t x_suffix_len)
+gen_tempname_len (char *tmpl, int flags, int kind, size_t x_suffix_len)
{
size_t len;
char *XX;
@@ -230,11 +225,9 @@ gen_tempname_len (char *tmpl, int kind, size_t
x_suffix_len)
switch (kind)
{
case __GT_FILE:
- fd = small_open (tmpl, O_RDWR | O_CREAT | O_EXCL, S_IRUSR | S_IWUSR);
- break;
-
-case __GT_BIGFILE:
- fd = large_open (tmpl, O_RDWR | O_CREAT | O_EXCL, S_IRUSR | S_IWUSR);
+ fd = __open (tmpl,
+ (flags ~0777) | O_RDWR | O_CREAT | O_EXCL,
+ S_IRUSR | S_IWUSR);
break;
case __GT_DIR:
@@ -295,7 +288,7 @@ gen_tempname_len (char *tmpl, int kind, size_t x_suffix_len)
}
int
-__gen_tempname (char *tmpl, int kind)
+__gen_tempname (char *tmpl, int flags, int kind)
{
- return gen_tempname_len (tmpl, kind, 6);
+ return gen_tempname_len (tmpl, flags, kind, 6);
}
diff --git a/gl/lib/tempname.h b/gl/lib/tempname.h
index ee34aca..a942f07 100644
--- a/gl/lib/tempname.h
+++ b/gl/lib/tempname.h
@@ -37,5 +37,6 @@
We use a clever algorithm to get hard-to-predict names. */
#include stddef.h
-extern int gen_tempname (char *tmpl, int kind);
-extern int gen_tempname_len (char *tmpl, int kind, size_t x_suffix_len);
+extern int gen_tempname (char *tmpl, int flags, int kind);
+extern int gen_tempname_len (char *tmpl, int flags, int kind,
+ size_t x_suffix_len);
--
1.6.5.rc1.192.g63b0
Re: (man|info) pages and --help
C de-Avillez wrote:
On Fri, 18 Sep 2009 17:34:31 +0200
Jim Meyering j...@meyering.net wrote:
Pádraig Brady wrote:
Alfred M. Szmidt wrote:
Is there anyone who's unaware that --help doesn't provide
complete documentation?
I would not expect anyone to *not* know that help output is
abridged. But I would rather have them go straight into 'info'
than wasting time on 'man', only to be redirected to 'info'.
Usually one looks at the '--help' output first. If we redirect
on 'man', why not there?
Because man pages are secondary on GNU systems, the offical spot
has always been info. The redirection is only for convience for
old timers who still use man.
While that may be the official line, practically nobody reads info
pages, and if they do it's indirectly through google.
I'd vote for removing the translation help line unconditionally
(I notice it's not mentioned in man pages) and replace with:
For complete documentation, run: info coreutils '$cmd invocation'
Seconded.
Is this, then, good?
From c16d6e93cdc94e890ad653d4caa994ea4c315a50 Mon Sep 17 00:00:00 2001
From: C de-Avillez hgg...@ubuntu.com
Date: Fri, 18 Sep 2009 12:16:50 -0500
Subject: [PATCH] --help: link to 'info' for complete docs
* src/system.h:
- take out the translation line
- add a reference to 'info' for complete documentation
We also need to tweak help2man and I've changed the
function name in system.h since we're now not just
outputting bug addresses. The interesting part of
the patch is below. I'd appreciate a quick review of
the perl change in help2man.
cheers,
Pádraig.
From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Fri, 18 Sep 2009 23:06:21 +0100
Subject: [PATCH] doc: mention the texinfo documentation in --help
* src/system.h: Rename emit_bug_reporting_address() to
emit_ancillary_info() and update it to remove the translation
project address and instead mention how to invoke the
texinfo documentation for each command. Also move the
hard-locale.h include to the 8 files that now use it.
* man/help2man: Strip the newly added texinfo reference from the
--help output as a more verbose version is already added by help2man.
Suggestion from C de-Avillez
---
97 files changed, 113 insertions(+), 108 deletions(-)
diff --git a/man/help2man b/man/help2man
index 7b7ce7a..9a15eaf 100755
--- a/man/help2man
+++ b/man/help2man
@@ -373,6 +373,7 @@ my $PAT_AUTHOR = _('Written +by');
my $PAT_OPTIONS= _('Options');
my $PAT_EXAMPLES = _('Examples');
my $PAT_FREE_SOFTWARE = _('This +is +free +software');
+my $PAT_INFO = _('For +complete +documentation');
# Start a new paragraph (if required) for these.
s/([^\n])\n($PAT_BUGS|$PAT_AUTHOR)/$1\n\n$2/og;
@@ -392,6 +393,11 @@ while (length)
$sect = _('EXAMPLES');
next;
}
+# Skip any texinfo reference as that's handled separately
+if (s/($PAT_INFO).*\n//o)
+{
+ next;
+}
# Copyright section
if (/^Copyright +[(\xa9]/)
diff --git a/src/system.h b/src/system.h
index a15c298..a81020c 100644
--- a/src/system.h
+++ b/src/system.h
@@ -635,9 +635,8 @@ Otherwise, units default to 1024 bytes (or 512 if
POSIXLY_CORRECT is set).\n\
), program);
}
-#include hard-locale.h
static inline void
-emit_bug_reporting_address (void)
+emit_ancillary_info (void)
{
printf (_(\nReport %s bugs to %s\n), last_component (program_name),
PACKAGE_BUGREPORT);
@@ -646,17 +645,9 @@ emit_bug_reporting_address (void)
PACKAGE_NAME, PACKAGE);
fputs (_(General help using GNU software: http://www.gnu.org/gethelp/\n),
stdout);
-
- if (hard_locale (LC_MESSAGES))
-{
- /* TRANSLATORS: Replace LANG_CODE in this URL with your language code
- http://translationproject.org/team/LANG_CODE.html to form one of
- the URLs at http://translationproject.org/team/. Otherwise, replace
- the entire URL with your translation team's email address. */
- printf (_(Report %s translation bugs to
-http://translationproject.org/team/\n),
-last_component (program_name));
-}
+ printf (_(\
+For complete documentation, run: info coreutils '%s invocation'\n\
+), last_component (program_name));
}
#include inttostr.h
Re: (man|info) pages and --help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Pádraig Brady on 9/18/2009 8:21 AM: I'd vote for removing the translation help line unconditionally Hmm. The GNU Coding Standards don't mention the translation bug report line, but the gettext manual recommends including it for any program with i18n output. After all, translation bugs really are better directed to the language team that had the translation issue, rather than the developer that can't even understand the language in question. I can, however, agree that the translation line does not add much in the C locale, and probably not in en_ locales. - -- 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/ iEYEARECAAYFAkq0EFIACgkQ84KuGfSFAYAVQACgku+I609SvnCe1GV3gR5eHbG/ pccAnRr0cDob8rdmidMUOttcF3IqtrQ1 =pkPz -END PGP SIGNATURE-
Re: (man|info) pages and --help
On Fri, 18 Sep 2009 23:42:31 +0100 Pádraig Brady p...@draigbrady.com wrote: -emit_bug_reporting_address (void) +emit_ancillary_info (void) Hi Pádraig, Thank you for getting the details done. Well, it really seems I still have a lot to learn on coreutils. But there is an issue in the change above: pretty much all sources have, hardcoded, calls to emit_bug_reporting_address. So, the end result: 1. a lot of warnings like below (well, 'hard_locale' happens only about 10 times): who.c: In function 'usage': who.c:668: warning: implicit declaration of function 'emit_bug_reporting_address' who.c: In function 'main': who.c:791: warning: implicit declaration of function 'hard_locale' 2. since the modules are hardcoded to emit_bug_reporting_address, the new message does not appear in the --help output; 3. on the other hand, it seems the Perl change is OK ;-) Sorry, my presence is being required at the dinner table. Cheers, signature.asc Description: PGP signature
Re: (man|info) pages and --help
Eric Blake wrote: According to Pádraig Brady on 9/18/2009 8:21 AM: I'd vote for removing the translation help line unconditionally Hmm. The GNU Coding Standards don't mention the translation bug report line, but the gettext manual recommends including it for any program with i18n output. After all, translation bugs really are better directed to the language team that had the translation issue, rather than the developer that can't even understand the language in question. Hmm, I wary about adding too much text. Perhaps we should leave things as they are. If someone is looking for more info than is given in --help they'll look at the man page from which they'll be directed to the texinfo docs. I can, however, agree that the translation line does not add much in the C locale, and probably not in en_ locales. Note currently the translation line is not added in the C locale (and hence is not in the default man pages). cheers, Pádraig.
Re: (man|info) pages and --help
C de-Avillez wrote:
On Fri, 18 Sep 2009 23:42:31 +0100
Pádraig Brady p...@draigbrady.com wrote:
-emit_bug_reporting_address (void)
+emit_ancillary_info (void)
Hi Pádraig,
Thank you for getting the details done. Well, it really seems I still
have a lot to learn on coreutils.
But there is an issue in the change above: pretty much all sources
have, hardcoded, calls to emit_bug_reporting_address.
Sorry, the last was an abridged patch for quick review.
Full patch attached.
cheers,
Pádraig.
From 7147430636c9fa773718839ac8d3ee943a33dd75 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Fri, 18 Sep 2009 23:06:21 +0100
Subject: [PATCH] doc: mention the texinfo documentation in --help
* src/system.h: Rename emit_bug_reporting_address() to
emit_ancillary_info() and update it to remove the translation
project address and instead mention how to invoke the
texinfo documentation for each command. Also move the
hard-locale.h include to the 8 files that now use it.
* man/help2man: Strip the newly added texinfo reference from the
--help output as a more verbose version is already added by help2man.
Suggestion from C de-Avillez
---
man/help2man|6 ++
src/base64.c|2 +-
src/basename.c |2 +-
src/cat.c |2 +-
src/chcon.c |2 +-
src/chgrp.c |2 +-
src/chmod.c |2 +-
src/chown.c |2 +-
src/chroot.c|2 +-
src/cksum.c |2 +-
src/comm.c |3 ++-
src/cp.c|2 +-
src/csplit.c|2 +-
src/cut.c |2 +-
src/date.c |2 +-
src/dd.c|2 +-
src/df.c|2 +-
src/dircolors.c |2 +-
src/dirname.c |2 +-
src/du.c|2 +-
src/echo.c |2 +-
src/env.c |2 +-
src/expand.c|2 +-
src/expr.c |2 +-
src/factor.c|2 +-
src/fmt.c |2 +-
src/fold.c |2 +-
src/getlimits.c |2 +-
src/groups.c|2 +-
src/head.c |2 +-
src/hostid.c|2 +-
src/hostname.c |2 +-
src/id.c|2 +-
src/install.c |2 +-
src/join.c |3 ++-
src/kill.c |2 +-
src/link.c |2 +-
src/ln.c|2 +-
src/logname.c |2 +-
src/ls.c|3 ++-
src/md5sum.c|2 +-
src/mkdir.c |2 +-
src/mkfifo.c|2 +-
src/mknod.c |2 +-
src/mktemp.c|2 +-
src/mv.c|2 +-
src/nice.c |2 +-
src/nl.c|2 +-
src/nohup.c |2 +-
src/od.c|2 +-
src/paste.c |2 +-
src/pathchk.c |2 +-
src/pinky.c |3 ++-
src/pr.c|3 ++-
src/printenv.c |2 +-
src/printf.c|2 +-
src/ptx.c |2 +-
src/pwd.c |2 +-
src/readlink.c |2 +-
src/rm.c|2 +-
src/rmdir.c |2 +-
src/runcon.c|2 +-
src/seq.c |2 +-
src/setuidgid.c |2 +-
src/shred.c |2 +-
src/shuf.c |2 +-
src/sleep.c |2 +-
src/sort.c |3 ++-
src/split.c |2 +-
src/stat.c |2 +-
src/stdbuf.c|2 +-
src/stty.c |2 +-
src/su.c|2 +-
src/sum.c |2 +-
src/sync.c |2 +-
src/system.h| 17 -
src/tac.c |2 +-
src/tail.c |2 +-
src/tee.c |2 +-
src/test.c |2 +-
src/timeout.c |2 +-
src/touch.c |2 +-
src/tr.c|2 +-
src/true.c |2 +-
src/truncate.c |2 +-
src/tsort.c |2 +-
src/tty.c |2 +-
src/uname.c |2 +-
src/unexpand.c |2 +-
src/uniq.c |3 ++-
src/unlink.c|2 +-
src/uptime.c|2 +-
src/users.c |2 +-
src/wc.c|2 +-
src/who.c |3 ++-
src/whoami.c|2 +-
src/yes.c |2 +-
97 files changed, 113 insertions(+), 108 deletions(-)
diff --git a/man/help2man b/man/help2man
index 7b7ce7a..3b19c64 100755
--- a/man/help2man
+++ b/man/help2man
@@ -373,6 +373,7 @@ my $PAT_AUTHOR = _('Written +by');
my $PAT_OPTIONS = _('Options');
my $PAT_EXAMPLES = _('Examples');
my $PAT_FREE_SOFTWARE = _('This +is +free +software');
+my $PAT_INFO = _('For +complete +documentation');
# Start a new paragraph (if required) for these.
s/([^\n])\n($PAT_BUGS|$PAT_AUTHOR)/$1\n\n$2/og;
@@ -392,6 +393,11 @@ while (length)
$sect = _('EXAMPLES');
next;
}
+# Skip any texinfo reference as that's handled separately
+if (s/($PAT_INFO).*\n//o)
+{
+ next;
+}
# Copyright section
if (/^Copyright +[(\xa9]/)
diff --git a/src/base64.c b/src/base64.c
index c7cf034..0bca87c 100644
--- a/src/base64.c
+++ b/src/base64.c
@@ -81,7 +81,7 @@ When decoding, the input may contain newlines in addition to the bytes of\n\
the formal base64 alphabet. Use --ignore-garbage to attempt to recover\n\
from any other non-alphabet bytes in the encoded stream.\n),
stdout);
- emit_bug_reporting_address ();
+
Re: (man|info) pages and --help
Pádraig Brady wrote:
...
Subject: [PATCH] doc: mention the texinfo documentation in --help
Thanks!
Good catch on moving hard-locale.h inclusions back.
* src/system.h: Rename emit_bug_reporting_address() to
emit_ancillary_info() and update it to remove the translation
project address and instead mention how to invoke the
texinfo documentation for each command. Also move the
hard-locale.h include to the 8 files that now use it.
* man/help2man: Strip the newly added texinfo reference from the
--help output as a more verbose version is already added by help2man.
Suggestion from C de-Avillez
...
diff --git a/man/help2man b/man/help2man
...
+my $PAT_INFO = _('For +complete +documentation');
You might want to make this regexp more specific,
just in case, to avoid accidentally filtering out
unrelated lines. Then again maybe not ;-)
I have a hard time imagining a sentence starting
like that in --help that should *not* be filtered out.
# Start a new paragraph (if required) for these.
s/([^\n])\n($PAT_BUGS|$PAT_AUTHOR)/$1\n\n$2/og;
@@ -392,6 +393,11 @@ while (length)
$sect = _('EXAMPLES');
next;
}
+# Skip any texinfo reference as that's handled separately
+if (s/($PAT_INFO).*\n//o)
+{
+ next;
+}
# Copyright section
if (/^Copyright +[(\xa9]/)
...
diff --git a/src/system.h b/src/system.h
index a15c298..a81020c 100644
--- a/src/system.h
+++ b/src/system.h
@@ -635,9 +635,8 @@ Otherwise, units default to 1024 bytes (or 512 if
POSIXLY_CORRECT is set).\n\
), program);
}
-#include hard-locale.h
static inline void
-emit_bug_reporting_address (void)
+emit_ancillary_info (void)
{
printf (_(\nReport %s bugs to %s\n), last_component (program_name),
PACKAGE_BUGREPORT);
@@ -646,17 +645,9 @@ emit_bug_reporting_address (void)
PACKAGE_NAME, PACKAGE);
fputs (_(General help using GNU software:
http://www.gnu.org/gethelp/\n),
stdout);
-
- if (hard_locale (LC_MESSAGES))
-{
- /* TRANSLATORS: Replace LANG_CODE in this URL with your language code
- http://translationproject.org/team/LANG_CODE.html to form one of
- the URLs at http://translationproject.org/team/. Otherwise, replace
- the entire URL with your translation team's email address. */
- printf (_(Report %s translation bugs to
-http://translationproject.org/team/\n),
-last_component (program_name));
-}
+ printf (_(\
+For complete documentation, run: info coreutils '%s invocation'\n\
+), last_component (program_name));
}
Re: (man|info) pages and --help
Pádraig Brady wrote: Eric Blake wrote: According to Pádraig Brady on 9/18/2009 8:21 AM: I'd vote for removing the translation help line unconditionally Hmm. The GNU Coding Standards don't mention the translation bug report line, but the gettext manual recommends including it for any program with i18n output. After all, translation bugs really are better directed to the language team that had the translation issue, rather than the developer that can't even understand the language in question. Hmm, I wary about adding too much text. Perhaps we should leave things as they are. If someone is looking for more info than is given in --help they'll look at the man page from which they'll be directed to the texinfo docs. I can, however, agree that the translation line does not add much in the C locale, and probably not in en_ locales. Note currently the translation line is not added in the C locale (and hence is not in the default man pages). I confess that I am not quite sure that removing the translation line is a good move. What do you think about suppressing it also for en* locales instead of removing it altogether? An alternative: don't emit it into --help, but do insert it into the man page.
