[PATCH] bootstrap: check for AC_PROG_LIBTOOL as well as AM_PROG_LIBTOOL
From 1ff16a1235ed546f04b219966a9142a2334a7b4b Mon Sep 17 00:00:00 2001 From: Jim Meyering [EMAIL PROTECTED] Date: Sun, 5 Oct 2008 08:24:04 +0200 Subject: [PATCH] bootstrap: check for AC_PROG_LIBTOOL as well as AM_PROG_LIBTOOL * build-aux/bootstrap: Check for AC_PROG_LIBTOOL, as well as the obsolete AM_PROG_LIBTOOL. Spotted by Debarshi 'Rishi' Ray [EMAIL PROTECTED]. --- ChangeLog |7 +++ build-aux/bootstrap |2 +- 2 files changed, 8 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index a360f8c..6cbd739 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2008-10-05 Jim Meyering [EMAIL PROTECTED] + + bootstrap: check for AC_PROG_LIBTOOL as well as AM_PROG_LIBTOOL + * build-aux/bootstrap: Check for AC_PROG_LIBTOOL, as well as the + obsolete AM_PROG_LIBTOOL. + Spotted by Debarshi 'Rishi' Ray [EMAIL PROTECTED]. + 2008-10-04 Bruno Haible [EMAIL PROTECTED] * modules/dup2 (License): Change to LGPLv2+. diff --git a/build-aux/bootstrap b/build-aux/bootstrap index 1134a65..ae2b8a2 100755 --- a/build-aux/bootstrap +++ b/build-aux/bootstrap @@ -597,7 +597,7 @@ for command in \ 'automake --add-missing --copy --force-missing'; do if test $command = libtool; then -grep '^[]*AM_PROG_LIBTOOL\' configure.ac /dev/null || +grep '^[]*A[CM]_PROG_LIBTOOL\' configure.ac /dev/null || continue command='libtoolize -c -f' fi -- 1.6.0.2.307.gc427 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] tests: fix the install/strip-program test
I noticed a test failure on OpenBSD 3.9. It was due to a bug that would probably cause trouble on other systems, too. Here's the fix: From fbc5aa7c47597694d8973a134143a2281748eec6 Mon Sep 17 00:00:00 2001 From: Jim Meyering [EMAIL PROTECTED] Date: Sat, 4 Oct 2008 17:12:08 +0200 Subject: [PATCH] tests: fix the install/strip-program test * tests/install/strip-program: Use $PREFERABLY_POSIX_SHELL, not POSIX_SHELL. The latter may be empty, and would fail on OpenBSD 3.9. * tests/check.mk (TESTS_ENVIRONMENT): Propagate PREFERABLY_POSIX_SHELL to tests. --- tests/check.mk |1 + tests/install/strip-program |2 +- 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/tests/check.mk b/tests/check.mk index cdb199e..0361d0c 100644 --- a/tests/check.mk +++ b/tests/check.mk @@ -87,6 +87,7 @@ TESTS_ENVIRONMENT = \ PACKAGE_BUGREPORT='$(PACKAGE_BUGREPORT)' \ PACKAGE_VERSION=$(PACKAGE_VERSION) \ PERL='$(PERL)' \ + PREFERABLY_POSIX_SHELL='$(PREFERABLY_POSIX_SHELL)' \ REPLACE_GETCWD=$(REPLACE_GETCWD) \ PATH='$(abs_top_builddir)/src$(PATH_SEPARATOR)'$$PATH \ ; shell_or_perl_ diff --git a/tests/install/strip-program b/tests/install/strip-program index 98f7feb..8dc838f 100755 --- a/tests/install/strip-program +++ b/tests/install/strip-program @@ -26,7 +26,7 @@ fi working_umask_or_skip_ cat EOF b || framework_failure -#!$POSIX_SHELL +#!$PREFERABLY_POSIX_SHELL sed s/b/B/ \$1 \$1.t mv \$1.t \$1 EOF chmod a+x b || framework_failure -- 1.6.0.2.307.gc427 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new snapshot available: coreutils-6.12.208-2441
Hoi,
Jim Meyering wrote:
Elbert Pol[EMAIL PROTECTED] wrote:
Hello Jim,
Thank you! You've just uncovered a bug!
Fixed by the patch below.
However, that problem is independent of the libgmp issue,
so if you apply the patch, your build should get farther.
Actually, there's another: after a failed fork, timeout is
documented to exit with status 125 (EXIT_CANCELED), not errno.
From 15f4d612df8eed7014f76825ad986fb8c769ec5d Mon Sep 17 00:00:00 2001
From: Jim Meyering[EMAIL PROTECTED]
Date: Fri, 3 Oct 2008 18:29:39 +0200
Subject: [PATCH] timeout.c: don't use perror; exit 125 upon failed fork
* src/timeout.c (main): Use error, not perror.
Elbert Pol noticed a build failure on OS/2.
* src/timeout.c (main): Exit 125 (not errno) upon failed fork.
Make the failed fork diagnostic match the one from install.c.
---
src/timeout.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/timeout.c b/src/timeout.c
index 37bed3c..8b506f0 100644
--- a/src/timeout.c
+++ b/src/timeout.c
@@ -284,8 +284,8 @@ main (int argc, char **argv)
monitored_pid = fork ();
if (monitored_pid == -1)
{
- perror (fork);
- return errno;
+ error (0, errno, _(fork system call failed));
+ return EXIT_CANCELED;
}
else if (monitored_pid == 0)
{ /* child */
@@ -299,7 +299,7 @@ main (int argc, char **argv)
/* exit like sh, env, nohup, ... */
exit_status = (errno == ENOENT ? EXIT_ENOENT : EXIT_CANNOT_INVOKE);
- perror (argv[0]);
+ error (0, errno, _(cannot run command %s), quote (argv[0]));
return exit_status;
}
else
--
1.6.0.2.307.gc427
I apply patch and come further but now i get this error..
make.exe[2]: Entering directory `U:/coreutils-6.12.208-2441/man'
Updating man page timeout.1
Array found where operator expected at ./help2man line 48, at end of line
(Missing operator before ?)
syntax error at ./help2man line 48, near gettext @_
syntax error at ./help2man line 59, near gettext shift
Execution of ./help2man aborted due to compilation errors.
make.exe[2]: *** [timeout.1] Error 255
make.exe[2]: Leaving directory `U:/coreutils-6.12.208-2441/man'
make.exe[1]: *** [all-recursive] Error 1
make.exe[1]: Leaving directory `U:/coreutils-6.12.208-2441'
make.exe: *** [all] Error 2
You're making progress.
What version of Perl are you using?
Run perl -v
Then try this patch:
diff --git a/man/help2man b/man/help2man
index cbdaf06..911edc9 100755
--- a/man/help2man
+++ b/man/help2man
@@ -40,8 +40,8 @@ BEGIN {
unless ($have_gettext)
{
- *gettext = sub { $_[0] };
- *textdomain = sub {};
+ eval 'sub gettext { $_[0] }';
+ eval 'sub textdomain {}';
}
}
If that doesn't help, try putting parentheses around
each argument to gettext.
[u:\]perl -v
This is perl, v5.10.0 built for os2
Copyright 1987-2007, Larry Wall
The patch don't help, and also the PArentheses don't fix it.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] bootstrap: check for AC_PROG_LIBTOOL as well as AM_PROG_LIBTOOL
Debarshi Ray [EMAIL PROTECTED] wrote: Subject: [PATCH] bootstrap: check for AC_PROG_LIBTOOL as well as AM_PROG_LIBTOOL Wow! Thanks a lot. Will this make its way into build-aux/bootstrap of Gnulib as well? That *was* for gnulib. I'm Cc'ing the right list this time. * build-aux/bootstrap: Check for AC_PROG_LIBTOOL, as well as the obsolete AM_PROG_LIBTOOL. Spotted by Debarshi 'Rishi' Ray [EMAIL PROTECTED]. I usually use 'Debarshi Ray [EMAIL PROTECTED]', but that is upto you. :-) Actually, you get to choose ;-) I've adjusted the ChangeLog. FYI, I got that from Parted's log. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new snapshot available: coreutils-6.12.208-2441
Elbert Pol [EMAIL PROTECTED] wrote:
...
What version of Perl are you using?
Run perl -v
Then try this patch:
diff --git a/man/help2man b/man/help2man
index cbdaf06..911edc9 100755
--- a/man/help2man
+++ b/man/help2man
@@ -40,8 +40,8 @@ BEGIN {
unless ($have_gettext)
{
-*gettext = sub { $_[0] };
-*textdomain = sub {};
+eval 'sub gettext { $_[0] }';
+eval 'sub textdomain {}';
}
}
If that doesn't help, try putting parentheses around
each argument to gettext.
[u:\]perl -v
This is perl, v5.10.0 built for os2
Copyright 1987-2007, Larry Wall
The patch don't help, and also the PArentheses don't fix it.
For now, I suggest you work around it with this:
cd man make -t
which will leave you with empty man pages.
If you really want them, generate them on a system
where things work better.
Then, maybe your top-level make will succeed.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] bootstrap: check for AC_PROG_LIBTOOL as well as AM_PROG_LIBTOOL
* Jim Meyering wrote on Sun, Oct 05, 2008 at 01:01:14PM CEST: Debarshi Ray [EMAIL PROTECTED] wrote: Subject: [PATCH] bootstrap: check for AC_PROG_LIBTOOL as well as AM_PROG_LIBTOOL * build-aux/bootstrap: Check for AC_PROG_LIBTOOL, as well as the obsolete AM_PROG_LIBTOOL. Spotted by Debarshi 'Rishi' Ray [EMAIL PROTECTED]. You should check for LT_INIT as well. Cheers, Ralf ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] bootstrap: check for AC_PROG_LIBTOOL as well as AM_PROG_LIBTOOL
Subject: [PATCH] bootstrap: check for AC_PROG_LIBTOOL as well as AM_PROG_LIBTOOL Wow! Thanks a lot. Will this make its way into build-aux/bootstrap of Gnulib as well? * build-aux/bootstrap: Check for AC_PROG_LIBTOOL, as well as the obsolete AM_PROG_LIBTOOL. Spotted by Debarshi 'Rishi' Ray [EMAIL PROTECTED]. I usually use 'Debarshi Ray [EMAIL PROTECTED]', but that is upto you. :-) Happy hacking, Debarshi ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new snapshot available: coreutils-6.12.208-2441
Hoi,
Jim Meyering wrote:
Elbert Pol[EMAIL PROTECTED] wrote:
...
What version of Perl are you using?
Run perl -v
Then try this patch:
diff --git a/man/help2man b/man/help2man
index cbdaf06..911edc9 100755
--- a/man/help2man
+++ b/man/help2man
@@ -40,8 +40,8 @@ BEGIN {
unless ($have_gettext)
{
- *gettext = sub { $_[0] };
- *textdomain = sub {};
+ eval 'sub gettext { $_[0] }';
+ eval 'sub textdomain {}';
}
}
If that doesn't help, try putting parentheses around
each argument to gettext.
[u:\]perl -v
This is perl, v5.10.0 built for os2
Copyright 1987-2007, Larry Wall
The patch don't help, and also the PArentheses don't fix it.
For now, I suggest you work around it with this:
cd man make -t
which will leave you with empty man pages.
If you really want them, generate them on a system
where things work better.
You mean not a Os2 machine or?
Then, maybe your top-level make will succeed.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: tee logs no output if stdout is closed
Bruno Haible [EMAIL PROTECTED] wrote: Jim Meyering wrote: You can distinguish close_stream and close_stdout. close_stream is library code, close_stdout is not. What about a 'bool ignore_epipe' that influences the behaviour of close_stdout? Whereas the library code that called close_stream has to check against EOF/EPIPE itself if it wants to. Indeed. This sounds workable, perhaps using a new close_stdout_ignore_epipe function. Here's a proposed patch. The function name 'close_stdout_set_ignore_EPIPE' was chosen for consistency with the already existing function 'close_stdout_set_file_name'. 2008-10-04 Bruno Haible [EMAIL PROTECTED] Jim Meyering [EMAIL PROTECTED] Add an option for ignoring EPIPE during close_stdout. * lib/closeout.h: Include stdbool.h. (close_stdout_set_ignore_EPIPE): New declaration. * lib/closeout.c: Include stdbool.h. (ignore_EPIPE): New variable. (close_stdout_set_ignore_EPIPE): New function. (close_stdout): Ignore EPIPE error if ignore_EPIPE is set. * lib/close-stream.c (close_stream): Mention the possible EPIPE failure. * modules/closeout (Depends-on): Add stdbool. ... +static bool ignore_EPIPE /* = false */; + +/* Specify whether an EPIPE error during the closing of stdout should be + ignored (ignore = true) or signaled to the user through an error message + (ignore = false). Thanks for writing all that. The code looks fine. Let's not use signaled here. How about this in place of the above: /* Tell close_stdout whether to ignore an EPIPE error. The default (ignore = false) ensures that a close_stdout-induced write failure due to EPIPE evokes a diagnostic about the failure, along with a nonzero exit status. Use ignore = true to make close_stdout ignore any EPIPE error. + This setting matters only if the SIGPIPE signal is ignored (i.e. its + handler set to SIG_IGN) or blocked. Only particular programs need to + temporarily ignore SIGPIPE. If SIGPIPE is ignored or blocked because + it was ignored or blocked in the parent process when it created the + child process, it usually is a bug in the parent process: It is bad + practice to have SIGPIPE ignored or blocked while creating a child + process. + + EPIPE occurs when writing to a pipe or socket that has no readers now, + when SIGPIPE is ignored or blocked. + + The ignore = false setting is suitable for a scenario where it is normally + guaranteed that the pipe writer terminates before the pipe reader. In + this case, an EPIPE is an indication of a premature termination of the + pipe reader and should be signaled. Best not to use signaled here. Perhaps diagnosed instead. + + The ignore = true setting is suitable for a scenario where you don't know s/is/may be/ Early reader termination may still deserve a diagnostic. Or it could be that POSIX requires the application to diagnose EPIPE, regardless ;-) + ahead of time whether the pipe writer or the pipe reader will terminate + first. In this case, an EPIPE is an indication that the pipe writer can + stop doing useless write() calls; this is what close_stdout does anyway. + EPIPE is part of the normal pipe/socket shutdown protocol in this case, + and should not be signaled. */ s/signaled/diagnosed/ With those changes, you're welcome to commit. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -u should skip copying a file to itself
Ed Avis [EMAIL PROTECTED] wrote: % touch foo foo % cp -u foo foo echo yes cp: `foo' and `foo' are the same file I expected that since -u says -u, --update copy only when the SOURCE file is newer than the destination file or when the destination file is missing it would not attempt to copy the file in this case (since the file is not newer than itself) and cp would return a true exit status. Sounds like it'd be worthwhile to change that, if you can do it in an obviously safe manner. If you write a patch, please follow the guidelines in HACKING: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=HACKING;hb=HEAD ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Patch to check for required programs when building from source checkout
Ed Avis [EMAIL PROTECTED] wrote: A few tools are required to build coreutils from a git checkout, but not checked in a friendly way. This patch adds checks to bootstrap and configure. Oh, and updates automake to 1.10.1, which appears to work. Hi Ed, Thanks for working on this. Appearances can be deceiving ;-) The newer automake-1.10a is actually required. Here's the relevant change set: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=d9903062 diff --git a/bootstrap b/bootstrap index 438a145..0232ae9 100755 --- a/bootstrap +++ b/bootstrap @@ -22,6 +22,16 @@ nl=' ' +# These programs are needed by this script. +if ! autopoint --help /dev/null; then echo You must install autopoint from gettext; exit 1; fi +if ! aclocal --help /dev/null; then echo You must install aclocal from automake; exit 1; fi + +# This isn't needed by this script, but it is necessary for building +# from a source checkout, and is not checked by configure because +# normal building from a distributed tarball doesn't require it. +# +if ! makeinfo --help /dev/null; then echo You must install makeinfo from Texinfo; exit 1; fi I like the idea of automating these checks, but can't use those changes as-is, since bootstrap is actually used more generally (it's home is in gnulib/build-aux/) and some projects lack texinfo documentation and/or don't use gettext, so those tools aren't run. It'd be a shame to make bootstrap fail in those cases. Besides, this is the purpose of the README-hacking file. # Ensure file names are sorted consistently across platforms. LC_ALL=C export LC_ALL @@ -558,9 +568,11 @@ echo $0: $gnulib_tool $gnulib_tool_options --import ... $gnulib_tool $gnulib_tool_options --import $gnulib_modules slurp $bt || exit -for file in $gnulib_files; do - symlink_to_dir $GNULIB_SRCDIR $file || exit -done +if test x$gnulib_files != x; then + for file in $gnulib_files; do +symlink_to_dir $GNULIB_SRCDIR $file || exit + done +fi What's the above for? When would $gnulib_files be empty? # Import from gettext. diff --git a/configure.ac b/configure.ac index 549c7ee..61b708c 100644 --- a/configure.ac +++ b/configure.ac @@ -32,7 +32,7 @@ AC_CONFIG_SRCDIR(src/ls.c) AC_CONFIG_AUX_DIR(build-aux) AC_CONFIG_HEADERS([lib/config.h:lib/config.hin]) -AM_INIT_AUTOMAKE([1.10a dist-lzma]) +AM_INIT_AUTOMAKE([1.10.1 dist-lzma]) AC_PROG_CC_STDC AM_PROG_CC_C_O @@ -291,6 +291,12 @@ case $t in 1) ;; esac +AC_CHECK_PROG([GPERF], [gperf], [1]) +if test x$GPERF = x; then + AC_MSG_ERROR([You need to install gperf]) + exit 1 +fi gperf should not be required when building from a tarball, so its absence shouldn't make configure fail. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] avoid use of undefined variable in warning
* tests/CuTmpdir.pm (chmod_tree): Do not warn if $dir is
undefined.
---
Hi Jim,
I'm currently debugging my parallel Automake TESTS pending patch
using coreutils' test suite. This turned up as side issue;
I haven't seen this show up otherwise.
I'll post patches when I get the bugs that I see ironed out.
Cheers,
Ralf
tests/CuTmpdir.pm | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/tests/CuTmpdir.pm b/tests/CuTmpdir.pm
index 166e50b..e172bd4 100644
--- a/tests/CuTmpdir.pm
+++ b/tests/CuTmpdir.pm
@@ -45,15 +45,18 @@ sub chmod_1
sub chmod_tree
{
- if (defined $dir chdir $dir)
+ if (defined $dir)
{
- # Perform the equivalent of find . -type d -print0|xargs -0 chmod -R 700.
- my $options = {untaint = 1, wanted = \chmod_1};
- find ($options, '.');
-}
- else
-{
- warn $ME: failed to chdir to $dir: $!\n;
+ if (chdir $dir)
+ {
+ # Perform the equivalent of find . -type d -print0|xargs -0 chmod -R
700.
+ my $options = {untaint = 1, wanted = \chmod_1};
+ find ($options, '.');
+ }
+ else
+ {
+ warn $ME: failed to chdir to $dir: $!\n;
+ }
}
}
--
1.6.0.1.309.g48068
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils-7.0 released (beta)
Coreutils version 7.0 has been released. Considering the two new programs, and that several of the existing programs acquired new options or other non-trivial improvements, this qualifies as a feature release and gets the beta label. However, most changes have been local and well-tested. For a summary of changes and contributors, see: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=shortlog;h=v6.12 or run this command from a git-cloned coreutils directory: git shortlog v6.12..v7.0 To summarize the gnulib-related changes, run this command from a git-cloned gnulib directory: git shortlog b9c1b3ae9d1cb02e7712988570355d4258f1bcb0\ ..785dc8ba76a688c5746d230dc5b7d4102d42ab4c Here are the compressed sources: ftp://alpha.gnu.org/gnu/coreutils/coreutils-7.0.tar.gz (9.0MB) ftp://alpha.gnu.org/gnu/coreutils/coreutils-7.0.tar.lzma (3.8MB) Here are the GPG detached signatures[*]: ftp://alpha.gnu.org/gnu/coreutils/coreutils-7.0.tar.gz.sig ftp://alpha.gnu.org/gnu/coreutils/coreutils-7.0.tar.lzma.sig Here are the MD5 and SHA1 checksums: a0b9aa9edd52b4efe9c8adb0cf622e79 coreutils-7.0.tar.gz 81c7aecc0daa6cada78005108edb6502 coreutils-7.0.tar.lzma 93b29fb84cc89f81a6c82d326c091600fde8a9d0 coreutils-7.0.tar.gz 8c122d454780401302d6b8a215b33c9d438a8178 coreutils-7.0.tar.lzma [*] You can use either of the above signature files to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify coreutils-7.0.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys B9AB9A16 and rerun the `gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.63 Automake 1.10a Bison 2.3 Gnulib v0.0-1166-g785dc8b * How can you help? * If you're interested in lending a hand, or just want to use the latest versions right now, you can build these programs and run the test suite like this: gzip -dc coreutils-7.0.tar.gz | tar xf - cd coreutils-7.0 ./configure make make -k check log grep FAIL log [If you downloaded the much-smaller .lzma tarball, then just substitute this for the gzip... line above: lzma -dc coreutils-7.0.tar.lzma | tar xf - If you don't have lzma installed yet, first try getting it via your distribution, e.g., aptitude install lzma or yum install lzma] Be sure to use make's -k option so that make doesn't stop just because one of the earlier tests fails. Please report any build problems or test failures to the bug-coreutils@gnu.org mailing list. There are detailed instructions in the `Reporting bugs:' section of the README file. * NEWS (since coreutils-7.0) * * Noteworthy changes in release 7.0 (2008-10-05) [beta] ** New programs timeout: Run a command with bounded time. truncate: Set the size of a file to a specified size. ** New features chgrp, chmod, chown, chcon, du, rm: now all display linear performance, even when operating on million-entry directories on ext3 and ext4 file systems. Before, they would exhibit O(N^2) performance, due to linear per-entry seek time cost when operating on entries in readdir order. Rm was improved directly, while the others inherit the improvement from the newer version of fts in gnulib. comm now verifies that the inputs are in sorted order. This check can be turned off with the --nocheck-order option. comm accepts new option, --output-delimiter=STR, that allows specification of an output delimiter other than the default single TAB. cp and mv: the deprecated --reply=X option is now also undocumented. dd accepts iflag=fullblock to make it accumulate full input blocks. With this new option, after a short read, dd repeatedly calls read, until it fills the incomplete block, reaches EOF, or encounters an error. df accepts a new option --total, which produces a grand total of all arguments after all arguments have been processed. If the GNU MP library is available at configure time, factor and expr support arbitrarily large numbers. Pollard's rho algorithm is used to factor large numbers. install accepts a new option --strip-program to specify the program used to strip binaries. ls now colorizes files with capabilities if libcap is available ls -v now uses filevercmp function as sort predicate (instead of strverscmp) md5sum now accepts the new option, --quiet, to suppress the printing of 'OK' messages. sha1sum, sha224sum, sha384sum, and sha512sum accept it, too. sort accepts a new option, --files0-from=F, that specifies a file containing a null-separated list of files to sort. This list is used instead of filenames passed on the command-line to avoid problems with maximum command-line (argv) length. sort accepts a new option
Re: Patch to fix data loss with `tail -F' (bug 6612)
I see that coreutils-7.0 has been released without this change. To recap, I don't think I'm able to provide a more satisfactory patch. Is the consensus that I should just continue to apply my patch locally? That works for me; after all, it does fix my problem, introduces no known regressions that I'm aware of (FreeBSD has been running with this change for almost two years) and rebuilding coreutils is really only a minor inconvenience in the grand scheme of things. Thanks again for your help. Cheers, Jos On Tue, Sep 30, 2008 at 09:36:35AM -0700, Jos Backus wrote: Hi Jim, On Tue, Sep 30, 2008 at 10:37:54AM +0200, Jim Meyering wrote: Jos Backus [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 10:37:31AM +0200, Andreas Schwab wrote: Jos Backus [EMAIL PROTECTED] writes: The `date' output shows up in the tail output. Also, this change only stops reading from the old file once the new file has some content. At that time the old file is read until EOF and closed before starting on the new file. What if the old file keeps growing? Too bad. With proper log rotation this never happens anyway. What is tail supposed to do? It's now seen a new file named foo (after foo was renamed to bar). Why would it care about bar, even though bar may continue to grow? It's supposed to tail foo, not bar. As a courtesy, until a new foo shows up, it will now tail bar because it solves the log rotation problem. Isn't that what you requested? E.g. When a tailed file (name) disappears, and a subsequent open attempt shows the new file is nonexistent or empty, continue tailing the old file descriptor. Perhaps this solution isn't perfect, but as it stands today `tail -F' is broken for tailing logfiles in that it _will_ lose data when the file is rotated. My test setup proves this. So something _has_ to be done. Hi Jos, Thanks for working on this. However, if there's a motto in coreutils development, do it right comes close, which you can interpret as making the code correct (of course), robust, maintainable, portable and efficient. We try not to compromise on any of those. Agreed. But as it stands today, `tail -F' is _not_ correct in the face of rotating log files. The initial patch fixes this without changing the behavior too much. I realize there are still more bugs, but not solving all of them shouldn't prevent us from solving some of them. So, it'd be nice to solve this problem while also remaining faithful to the documentation, which implies that with --follow=name, tail will indeed detect the renaming, even if the original continues to grow. Isn't that what happens already? I'm confused. Thanks for your help resolving this problem. -- Jos Backus jos at catnook.com -- Jos Backus jos at catnook.com ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: tee logs no output if stdout is closed
Jim Meyering wrote: Thanks for writing all that. The code looks fine. Glad to see that our disagreements have been reduced to the comments. Let's not use signaled here. Yes, indeed this term is confusing in a paragraph dealing with signals. How about this in place of the above: /* Tell close_stdout whether to ignore an EPIPE error. The default (ignore = false) ensures that a close_stdout-induced write failure due to EPIPE evokes a diagnostic about the failure, along with a nonzero exit status. Use ignore = true to make close_stdout ignore any EPIPE error. OK, I adopted the diagnostic, along with a nonzero exit status wording. Still generally I prefer to say what the argument indicates, before stating what is the default value. (It is less challenging for the reader to say things one at a time.) Best not to use signaled here. Perhaps diagnosed instead. Yup. + The ignore = true setting is suitable for a scenario where you don't know s/is/may be/ Early reader termination may still deserve a diagnostic. Or it could be that POSIX requires the application to diagnose EPIPE, regardless ;-) I disagree here. If early reader termination leads to a diagnostic in this case, the diagnostic is timing dependent (depends which of the CPU cores executing the reader process and the writer process is more loaded); this is never what you want. POSIX does not specify anthing here, because it essentially says that during the operation specified by POSIX the SIGPIPE handler is set to SIG_DFL. Btw, the wording is suitable is not as strong as is mandatory: it is merely an advice with explanations. I committed this: 2008-10-05 Bruno Haible [EMAIL PROTECTED] Jim Meyering [EMAIL PROTECTED] Add an option for ignoring EPIPE during close_stdout. * lib/closeout.h: Include stdbool.h. (close_stdout_set_ignore_EPIPE): New declaration. * lib/closeout.c: Include stdbool.h. (ignore_EPIPE): New variable. (close_stdout_set_ignore_EPIPE): New function. (close_stdout): Ignore EPIPE error if ignore_EPIPE is set. * lib/close-stream.c (close_stream): Mention the possible EPIPE failure. * modules/closeout (Depends-on): Add stdbool. *** lib/close-stream.c.orig 2008-10-06 02:37:14.0 +0200 --- lib/close-stream.c 2008-10-06 01:50:55.0 +0200 *** *** 1,6 /* Close a stream, with nicer error checking than fclose's. !Copyright (C) 1998, 1999, 2000, 2001, 2002, 2004, 2006, 2007 Free Software Foundation, Inc. This program is free software: you can redistribute it and/or modify --- 1,6 /* Close a stream, with nicer error checking than fclose's. !Copyright (C) 1998, 1999, 2000, 2001, 2002, 2004, 2006, 2007, 2008 Free Software Foundation, Inc. This program is free software: you can redistribute it and/or modify *** *** 33,38 --- 33,42 otherwise. A failure might set errno to 0 if the error number cannot be determined. +A failure with errno set to EPIPE may or may not indicate an error +situation worth signaling to the user. See the documentation of the +close_stdout_set_ignore_EPIPE function for details. + If a program writes *anything* to STREAM, that program should close STREAM and make sure that it succeeds before exiting. Otherwise, suppose that you go to the extreme of checking the return status *** lib/closeout.c.orig 2008-10-06 02:37:14.0 +0200 --- lib/closeout.c 2008-10-06 02:36:36.0 +0200 *** *** 1,6 /* Close standard output and standard error, exiting with a diagnostic on error. !Copyright (C) 1998, 1999, 2000, 2001, 2002, 2004, 2006 Free Software Foundation, Inc. This program is free software: you can redistribute it and/or modify --- 1,6 /* Close standard output and standard error, exiting with a diagnostic on error. !Copyright (C) 1998, 1999, 2000, 2001, 2002, 2004, 2006, 2008 Free Software Foundation, Inc. This program is free software: you can redistribute it and/or modify *** *** 21,26 --- 21,27 #include closeout.h #include errno.h + #include stdbool.h #include stdio.h #include unistd.h *** *** 42,47 --- 43,85 file_name = file; } + static bool ignore_EPIPE /* = false */; + + /* Specify the reaction to an EPIPE error during the closing of stdout: + - If ignore = true, it shall be ignored. + - If ignore = false, it shall evoke a diagnostic, along with a nonzero +exit status. +The default is ignore = false. + +This setting matters only if the SIGPIPE signal is ignored (i.e. its +handler set to SIG_IGN) or blocked. Only particular programs need to +temporarily ignore SIGPIPE. If SIGPIPE is ignored or blocked because +it was ignored or blocked in the parent
Re: tee logs no output if stdout is closed
After the newest changes to gnulib, here's a revised version of the patch
proposed in
http://lists.gnu.org/archive/html/bug-coreutils/2008-09/msg00024.html
From a4434d71a1a3ec7a6aee6de4a81da36301b12a28 Mon Sep 17 00:00:00 2001
From: Bruno Haible [EMAIL PROTECTED]
Date: Mon, 6 Oct 2008 02:58:58 +0200
Subject: [PATCH] New tee option -p.
* src/tee.c (ignore_sigpipe): New variable.
(long_options): Add option -p.
(usage): Document option -p.
(main): Handle option -p.
(tee_files): When option -p is specified, ignore SIGPIPE write errors
until the last open output descriptor is closed.
* doc/coreutils.texi (tee invocation): Document option -p.
---
doc/coreutils.texi | 11 +
src/tee.c | 63 +++
2 files changed, 69 insertions(+), 5 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 67da740..a271251 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -11445,6 +11445,17 @@ them.
@opindex --ignore-interrupts
Ignore interrupt signals.
[EMAIL PROTECTED] -p
[EMAIL PROTECTED] --ignore-sigpipe
[EMAIL PROTECTED] -p
[EMAIL PROTECTED] --ignore-sigpipe
+Ignore failed writes to pipes with no readers. By default, when standard
+output or one of the given files refers to a pipe with no reading processes,
+the operating system will kill the @command{tee} process with signal
[EMAIL PROTECTED], thus terminating the output to the other files. When the
+option @samp{-p} is specified, the @command{tee} process will continue
+writing to the other specified files.
+
@end table
The @command{tee} command is useful when you happen to be transferring a large
diff --git a/src/tee.c b/src/tee.c
index 4e46aab..e7c5943 100644
--- a/src/tee.c
+++ b/src/tee.c
@@ -41,10 +41,14 @@ static bool append;
/* If true, ignore interrupts. */
static bool ignore_interrupts;
+/* If true, ignore failed writes to pipes with no readers. */
+static bool ignore_sigpipe;
+
static struct option const long_options[] =
{
{append, no_argument, NULL, 'a'},
{ignore-interrupts, no_argument, NULL, 'i'},
+ {ignore-sigpipe, no_argument, NULL, 'p'},
{GETOPT_HELP_OPTION_DECL},
{GETOPT_VERSION_OPTION_DECL},
{NULL, 0, NULL, 0}
@@ -64,6 +68,7 @@ Copy standard input to each FILE, and also to standard output.\n\
\n\
-a, --append append to the given FILEs, do not overwrite\n\
-i, --ignore-interrupts ignore interrupt signals\n\
+ -p, --ignore-sigpipe ignore failed writes to pipes with no readers\n\
), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION, stdout);
@@ -93,7 +98,7 @@ main (int argc, char **argv)
append = false;
ignore_interrupts = false;
- while ((optc = getopt_long (argc, argv, ai, long_options, NULL)) != -1)
+ while ((optc = getopt_long (argc, argv, aip, long_options, NULL)) != -1)
{
switch (optc)
{
@@ -105,6 +110,10 @@ main (int argc, char **argv)
ignore_interrupts = true;
break;
+ case 'p':
+ ignore_sigpipe = true;
+ break;
+
case_GETOPT_HELP_CHAR;
case_GETOPT_VERSION_CHAR (PROGRAM_NAME, AUTHORS);
@@ -117,6 +126,12 @@ main (int argc, char **argv)
if (ignore_interrupts)
signal (SIGINT, SIG_IGN);
+ if (ignore_sigpipe)
+{
+ signal (SIGPIPE, SIG_IGN);
+ close_stdout_set_ignore_EPIPE (true);
+}
+
/* Do *not* warn if tee is given no file arguments.
POSIX requires that it work when given no arguments. */
@@ -135,6 +150,7 @@ static bool
tee_files (int nfiles, const char **files)
{
FILE **descriptors;
+ size_t num_open_descriptors;
char buffer[BUFSIZ];
ssize_t bytes_read;
int i;
@@ -161,6 +177,7 @@ tee_files (int nfiles, const char **files)
descriptors[0] = stdout;
files[0] = _(standard output);
setvbuf (stdout, NULL, _IONBF, 0);
+ num_open_descriptors = 1;
for (i = 1; i = nfiles; i++)
{
@@ -173,7 +190,10 @@ tee_files (int nfiles, const char **files)
ok = false;
}
else
- setvbuf (descriptors[i], NULL, _IONBF, 0);
+ {
+ setvbuf (descriptors[i], NULL, _IONBF, 0);
+ num_open_descriptors++;
+ }
}
while (1)
@@ -192,9 +212,41 @@ tee_files (int nfiles, const char **files)
if (descriptors[i]
fwrite (buffer, bytes_read, 1, descriptors[i]) != 1)
{
- error (0, errno, %s, files[i]);
- descriptors[i] = NULL;
- ok = false;
+ if (ignore_sigpipe errno == EPIPE)
+ {
+ /* Could not write to a pipe with no readers.
+ Close the stream. */
+ fclose (descriptors[i]);
+ /* Close also the underlying file descriptor, to avoid an
+ error message from close_stdout. */
+ if (fileno (descriptors[i]) = 0)
+ close (fileno (descriptors[i]));
+ descriptors[i] = NULL;
+ if (--num_open_descriptors == 0)
+ {
+ /* All output descriptors are closed. We have no reason
+ to continue reading input any more. Raise a SIGPIPE
+ and terminate. */
+ sigset_t sigpipe_set;
+
+
Re: Patch to fix data loss with `tail -F' (bug 6612)
Jos Backus [EMAIL PROTECTED] wrote: I see that coreutils-7.0 has been released without this change. To recap, I don't think I'm able to provide a more satisfactory patch. Is the consensus that I should just continue to apply my patch locally? That works for me; after all, it does fix my problem, introduces no known regressions that I'm aware of (FreeBSD has been running with this change for almost two years) and rebuilding coreutils is really only a minor inconvenience in the grand scheme of things. Sorry it couldn't make it into 7.0. The change I have in mind isn't complete, but the way it's shaping up, it would have been too risky anyway. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
