Ralf Wildenhues asked:
What system and shell (version?) were your tests done on?
I could reproduce Dmitry's tests, with 'sleep 1' instead of 'sleep 0.01'.
$ for i in `seq 0 9`; do sh -c 'trap exit \$? TERM; while /bin/true; do
/bin/false; done' pid=$! sleep 1 kill -TERM -$pid wait $pid;
Jim Meyering wrote:
Imagine that the first 10 tests pass, then each of the remaining ones is
killed via e.g., SIGHUP. ...
a naive search for FAIL: in the build output would find nothing.
Yes, and it should be this way, IMO. Each time a user sees a FAIL:, he
should be encouraged to investigate.
On Sun, Jan 31, 2010 at 08:05:20AM +0100, Ralf Wildenhues wrote:
* Dmitry V. Levin wrote on Sat, Jan 30, 2010 at 08:12:01PM CET:
There is a comment about shell signal handlers in gnulib-tool saying that
The value of $? is 128 + signal number and is set before the
trap-registered command is
* Dmitry V. Levin wrote on Sun, Jan 31, 2010 at 01:04:01PM CET:
On Sun, Jan 31, 2010 at 08:05:20AM +0100, Ralf Wildenhues wrote:
Can you please explain whose fault this is? Is that a kernel issue, a
shell issue, or expected behavior given a POSIX system?
It is expected behaviour.
What
Hi Bruno,
thanks for the additional information.
* Bruno Haible wrote on Sun, Jan 31, 2010 at 12:32:06PM CET:
Ralf Wildenhues asked:
What are the other cases you mention, where no process was terminated
by the signal, but the signal delivered somewhere nonethess?
When I run
$ while
Eric Blake wrote:
FreeBSD is buggy. Rewording the POSIX requirement slightly: if lineptr is
NULL, then it is irrelevant that linecapp is non-zero.
I agree.
Gnulib needs to work around this portability flaw, and guarantee a working
getline implementation even on fBSD, at which point, your
2010-01-31 Bruno Haible br...@clisp.org
Work around getline() bug on FreeBSD 8.0.
* m4/getline.m4 (gl_FUNC_GETLINE): Also test result for a NULL buffer
and a non-zero size.
* tests/test-getline.c (main): Likewise.
* doc/posix-functions/getline.texi: Mention
Hi Martin,
sc_po_check:
This one complains about files like lib/getopt.c not being listed as
requiring translations. OK, it has a point there. Still, of the three
possible solutions which come to my mind, none feels exactly right:
1. Add files, and require every translator
Paolo Bonzini wrote:
I'll think I'll merge the test for EXP_LIBM, LOG_LIBM etc. into a single
one - to save configure script execution time, as you say -.
That's fair enough, thanks.
Implemented as follows:
2010-01-31 Bruno Haible br...@clisp.org
Perform the same test for many
