Re: noisy gnulib-tool on IRIX
Hi Eric, > hence the common idiom of first checking if alias/unalias exist using > a subshell check, and if so then using them in the parent shell. Ah, I didn't think of this trick. But as you noticed, the trick I've found is more efficient, so I'll use it. > $ /bin/sh -c 'alias 2>/dev/null' > alias: Not found > $ /bin/sh -c 'exec 3>&2; exec 2>/dev/null; unalias echo; exec 2>&3; exec 3>&-' Good, it works. So I'm applying the patch below. > What I wasn't sure about is why you were trying to set up an alias in > the first place, nor how you plan on working around echo(1) issues > without the use of alias(1). Well, the code is clear: We know we have to handle ksh without re-execing, and in ksh the solution is to use an alias to a shell function that invokes 'cat'. If we're not in ksh, then the code notices it by the fact that the 'alias' command did not work, and tries to re-exec. Which code path does it end up taking on IRIX (i.e. what's the result when you add a 'set -x' command at the top of gnulib-tool)? 2010-09-08 Bruno Haible gnulib-tool: Avoid stderr output on IRIX related to 'alias', 'unalias'. * gnulib-tool: Use stderr redirection around the 'alias' and 'unalias' commands, because some shells ignore redirections when there is an error in the command lookup. Reported by Eric Blake. --- gnulib-tool.origWed Sep 8 10:24:19 2010 +++ gnulib-tool Wed Sep 8 10:12:02 2010 @@ -842,14 +842,22 @@ $* EOF } -alias echo=bsd_echo 2>/dev/null +exec 3>&2 +exec 2>/dev/null +alias echo=bsd_echo +exec 2>&3 +exec 3>&- fi if test -z "$have_echo" \ && echo '\t' | grep t > /dev/null; then have_echo=yes fi if test -z "$have_echo"; then - unalias echo 2>/dev/null + exec 3>&2 + exec 2>/dev/null + unalias echo + exec 2>&3 + exec 3>&- fi # For Solaris /bin/sh and OSF/1 /bin/sh: respawn using /bin/ksh. if test -z "$have_echo" \
Re: POSIXLY_CORRECT not correctly unset in getopt.m4?
On 09/07/2010 10:39 PM, Eric Blake wrote:
gl_awk_probe='BEGIN { for (v in ENVIRON)
if (v == "POSIXLY_CORRECT") print "x" }'
case ${POSIXLY_CORRECT:+x}`awk "$gl_awk_probe"
Walking all of ENVIRON seems slow. What about
gl_awk_probe='BEGIN {print !!length(ENVIRON["POSIXLY_CORRECT"])}'
case ${POSIXLY_CORRECT:+x}`awk "$gl_awk_probe"
Re: POSIXLY_CORRECT not correctly unset in getopt.m4?
[removing bug-standards from the CC list]
Paolo Bonzini wrote:
> On 09/07/2010 10:39 PM, Eric Blake wrote:
> > gl_awk_probe='BEGIN { for (v in ENVIRON)
> > if (v == "POSIXLY_CORRECT") print "x" }'
> > case ${POSIXLY_CORRECT:+x}`awk "$gl_awk_probe" > xx) gl_had_POSIXLY_CORRECT=exported ;;
> > x) gl_had_POSIXLY_CORRECT=yes ;;
> > *) gl_had_POSIXLY_CORRECT= ;;
> > esac
>
> Walking all of ENVIRON seems slow.
But it handles an empty exported value correctly:
export POSIXLY_CORRECT=
has the same semantics as
export POSIXLY_CORRECT=1
> What about
>
> gl_awk_probe='BEGIN {print !!length(ENVIRON["POSIXLY_CORRECT"])}'
> case ${POSIXLY_CORRECT:+x}`awk "$gl_awk_probe"x1) gl_had_POSIXLY_CORRECT=exported ;;
> x0) gl_had_POSIXLY_CORRECT=yes ;;
> *) gl_had_POSIXLY_CORRECT= ;;
> esac
>
> instead?
It handles an empty exported value as if the variable was not exported.
Bruno
Re: POSIXLY_CORRECT not correctly unset in getopt.m4?
On 09/08/2010 11:30 AM, Bruno Haible wrote:
[removing bug-standards from the CC list]
Paolo Bonzini wrote:
On 09/07/2010 10:39 PM, Eric Blake wrote:
gl_awk_probe='BEGIN { for (v in ENVIRON)
if (v == "POSIXLY_CORRECT") print "x" }'
case ${POSIXLY_CORRECT:+x}`awk "$gl_awk_probe"
Walking all of ENVIRON seems slow.
But it handles an empty exported value correctly:
export POSIXLY_CORRECT=
has the same semantics as
export POSIXLY_CORRECT=1
So maybe it should be ${POSIXLY_CORRECT+x}, not ${POSIXLY_CORRECT:+x}?
Right now it's inconsistent.
bash seems to confirm this
$ POSIXLY_CORRECT=
$ set -o | grep posix
posix on
$ echo ${POSIXLY_CORRECT:+yes}
$ echo ${POSIXLY_CORRECT+yes}
yes
Paolo
[PATCH] init.sh: disqualify shells for which set -x corrupts stderr
grep portability testing has exposed some unwarranted test failures. Using a better SHELL was the quick work-around. Fixing init.sh is the real fix: >From d79a9c27419cc4679620b9283351566ba6085cd2 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 8 Sep 2010 15:18:46 +0200 Subject: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr * tests/init.sh: Add a test to disqualify /bin/sh from SunOS 5.11 and OpenBSD 4.7. They make it so with "set -x", environment settings appear in stderr output. For example, this command: /bin/sh -c 'set -x; P=1 true 2> err' 2>/dev/null; cat err prints "P=1" on those two systems: --- ChangeLog |9 + tests/init.sh |4 2 files changed, 13 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index f36acb6..9a51377 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2010-09-08 Jim Meyering + + test.sh: disqualify shells for which set -x corrupts stderr + * tests/init.sh: Add a test to disqualify /bin/sh from SunOS 5.11 + and OpenBSD 4.7. They make it so with "set -x", environment settings + appear in stderr output. For example, this command: + /bin/sh -c 'set -x; P=1 true 2> err' 2>/dev/null; cat err + prints "P=1" on those two systems: + 2010-09-08 Bruno Haible gnulib-tool: Avoid stderr output on IRIX related to 'alias', 'unalias'. diff --git a/tests/init.sh b/tests/init.sh index fe2c224..9886a8d 100644 --- a/tests/init.sh +++ b/tests/init.sh @@ -103,11 +103,15 @@ fi # shells until we find one that passes. If one is found, re-exec it. # If no acceptable shell is found, skip the current test. # +# The "...set -x; P=1 true 2>err..." test is to disqualify any shell that +# emits "P=1" into err, as /bin/sh from SunOS 5.11 and OpenBSD 4.7 do. +# # Use "9" to indicate success (rather than 0), in case some shell acts # like Solaris 10's /bin/sh but exits successfully instead of with status 2. gl_shell_test_script_=' test $(echo y) = y || exit 1 +test -z "$( (exec 3>&1; set -x; P=1 true 2>&3) 2> /dev/null)" || exit 1 test -z "$EXEEXT" && exit 9 shopt -s expand_aliases alias a-b="echo zoo" -- 1.7.3.rc0.174.g69763
Re: noisy gnulib-tool on IRIX
On 09/08/2010 02:44 AM, Bruno Haible wrote:
Hi Eric,
hence the common idiom of first checking if alias/unalias exist using
a subshell check, and if so then using them in the parent shell.
Ah, I didn't think of this trick. But as you noticed, the trick I've found
is more efficient, so I'll use it.
Actually, you've already used that trick - look earlier in gnulib-tool
where you set an alias for sed, but only when alias is supported.
Well, the code is clear: We know we have to handle ksh without re-execing,
and in ksh the solution is to use an alias to a shell function that invokes
'cat'. If we're not in ksh, then the code notices it by the fact that the
'alias' command did not work, and tries to re-exec. Which code path does it
end up taking on IRIX (i.e. what's the result when you add a 'set -x'
command at the top of gnulib-tool)?
Hmm - gnulib-tool is another shell script where preserving -v and -x
into a re-exec'd invocation might be nice. At any rate, here's the full
trace, showing that /bin/sh is ultimately rejected and the script rerun
under ksh for IRIX.
# The workaround is: define echo to a function that uses the printf
built-in.
have_echo=
have_echo=
if echo '\t' | grep t > /dev/null; then
have_echo=yes # Lucky!
fi
+ echo \t
+ grep t
# Try the workarounds.
# Respawn using $CONFIG_SHELL if that is set and works.
if test -z "$have_echo" \
&& test "X$1" != "X--no-reexec" \
&& test -n "$CONFIG_SHELL" \
&& test -f "$CONFIG_SHELL" \
&& $CONFIG_SHELL -c "echo '\\t' | grep t > /dev/null"; then
exec $CONFIG_SHELL "$0" --no-reexec "$@"
exit 127
fi
+ test -z
+ test X--help != X--no-reexec
+ test -n
# For bash >= 2.04: unset the shell option xpg_echo.
if test -z "$have_echo" \
&& test -n "$BASH_VERSION" \
&& (shopt -o xpg_echo; echo '\t' | grep t > /dev/null) 2>/dev/null; then
shopt -o xpg_echo
have_echo=yes
fi
+ test -z
+ test -n
# For bash >= 2.0: define echo to a function that uses the printf built-in.
# For bash < 2.0: define echo to a function that uses cat of a here
document.
# (There is no win in using 'printf' over 'cat' if it is not a shell
built-in.)
# Also handle problem 2, specific to bash 3.2, here.
if { test -z "$have_echo" \
|| case "$BASH_VERSION" in 3.2*) true;; *) false;; esac; \
} \
&& test -n "$BASH_VERSION"; then \
if type printf 2>/dev/null | grep / > /dev/null; then
# 'printf' is not a shell built-in.
echo ()
{
cat < /dev/null; then
have_echo=yes
fi
fi
+ test -z
+ test -n
# For zsh: turn sh-emulation on.
if test -z "$have_echo" \
&& test -n "$ZSH_VERSION" \
&& (emulate sh) >/dev/null 2>&1; then
emulate sh
fi
+ test -z
+ test -n
# For ksh: alias echo to 'print -r'.
if test -z "$have_echo" \
&& (type print) >/dev/null 2>&1; then
# A 'print' command exists.
if type print 2>/dev/null | grep / > /dev/null; then
:
else
# 'print' is a shell built-in.
if (print -r '\told' | grep told > /dev/null) 2>/dev/null; then
# 'print' is the ksh shell built-in.
alias echo='print -r'
fi
fi
fi
+ test -z
if test -z "$have_echo" \
&& echo '\t' | grep t > /dev/null; then
have_echo=yes
fi
+ test -z
+ echo \t
+ grep t
# For ksh: alias echo to a function that uses cat of a here document.
# The ksh manual page says:
# "Aliasing is performed when scripts are read, not while they are
executed.
#Therefore, for an alias to take effect, the alias definition
command has
#to be executed before the command which references the alias is read."
# Because of this, we have to play strange tricks with have_echo, to ensure
# that the top-level statement containing the test starts after the 'alias'
# command.
if test -z "$have_echo"; then
bsd_echo ()
{
cat /dev/null; then
have_echo=yes
fi
+ test -z
+ echo \t
+ grep t
if test -z "$have_echo"; then
unalias echo 2>/dev/null
fi
+ test -z
+ unalias echo
unalias: Not found
# For Solaris /bin/sh and OSF/1 /bin/sh: respawn using /bin/ksh.
if test -z "$have_echo" \
&& test "X$1" != "X--no-reexec" \
&& test -f /bin/ksh; then
exec /bin/ksh "$0" --no-reexec "$@"
exit 127
fi
+ test -z
+ test X--help != X--no-reexec
+ test -f /bin/ksh
+ exec /bin/ksh ./gnulib-tool --no-reexec --help
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
Re: POSIXLY_CORRECT not correctly unset in getopt.m4?
On 09/08/2010 03:56 AM, Paolo Bonzini wrote:
On 09/08/2010 11:30 AM, Bruno Haible wrote:
Paolo Bonzini wrote:
On 09/07/2010 10:39 PM, Eric Blake wrote:
gl_awk_probe='BEGIN { for (v in ENVIRON)
if (v == "POSIXLY_CORRECT") print "x" }'
case ${POSIXLY_CORRECT:+x}`awk "$gl_awk_probe"
Walking all of ENVIRON seems slow.
Then we should be able to use the faster:
if ("POSIXLY_CORRECT" in ENVIRON)
Autoconf documents that traditional awk has 'for (a in b)' but lacks 'if
(a in b)'; but we are already avoiding traditional awk for their lack of
ENVIRON, and all the [gmn]awk implementations I tested support both forms.
So maybe it should be ${POSIXLY_CORRECT+x}, not ${POSIXLY_CORRECT:+x}?
Right now it's inconsistent.
Good catch. I'm installing a fix for that:
diff --git i/ChangeLog w/ChangeLog
index 103ab6c..2daedad 100644
--- i/ChangeLog
+++ w/ChangeLog
@@ -1,3 +1,10 @@
+2010-09-08 Eric Blake
+
+ getopt: optimize previous patch
+ * m4/getopt.m4 (gl_GETOPT_CHECK_HEADERS): Correctly check for
+ empty variable. Speed up awk script.
+ Reported by Paolo Bonzini.
+
2010-09-07 Eric Blake
strtod: work around IRIX 6.5 bug
diff --git i/m4/getopt.m4 w/m4/getopt.m4
index 720f048..d05e9d9 100644
--- i/m4/getopt.m4
+++ w/m4/getopt.m4
@@ -1,4 +1,4 @@
-# getopt.m4 serial 30
+# getopt.m4 serial 31
dnl Copyright (C) 2002-2006, 2008-2010 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -218,9 +218,8 @@ main ()
# so take care to revert to the correct (non-)export state.
dnl GNU Coding Standards currently allow awk but not env; besides, env
dnl is ambiguous with environment values that contain newlines.
- gl_awk_probe='BEGIN { for (v in ENVIRON)
- if (v == "POSIXLY_CORRECT") print "x" }'
- case ${POSIXLY_CORRECT:+x}`$AWK "$gl_awk_probe" http://libvirt.org
Re: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr
Eric Blake wrote: > On 09/08/2010 07:20 AM, Jim Meyering wrote: >> grep portability testing has exposed some unwarranted test failures. >> Using a better SHELL was the quick work-around. >> Fixing init.sh is the real fix: >> >>> From d79a9c27419cc4679620b9283351566ba6085cd2 Mon Sep 17 00:00:00 2001 >> From: Jim Meyering >> Date: Wed, 8 Sep 2010 15:18:46 +0200 >> Subject: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr > > I'm a little worried that this patch might exclude all shells on a > given platform. For example, on IRIX 5.3: > > $ /bin/sh -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null' > P=1 > $ /bin/ksh -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null' > + P=1 > $ bash -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null' > $ > > If bash is manually installed, then things are okay. But all existing > shells on a bare-bones installation output trace information. If that happens, the result will be that each init.sh-using test will be skipped. > Maybe a compromise is to test that if there is output, is it at least > proceeded by PS4 (in which case it can be filtered), so as not to > outright rejecting /bin/ksh, but still exclude /bin/sh as > unfilterable? But then each init.sh-using test must be audited to discover if/where this makes a difference, and then we'd have to modify offenders to filter out those bogus lines. All for what? To avoid skipping tests when run an ancient system like Irix 5.x that lacks a usable shell. Polluting our code, even "mere" tests, solely to accommodate an inferior or old system is hard for me to justify. I think it scales better simply to eliminate the offending shells -- then we avoid the constant overhead of auditing for yet another portability nit. Of course, if this turns out to affect too many (and more modern) systems, then I'll be the first to look for a lower-impact solution. Besides, isn't Irix 5.x approaching effective museum-only status?
Re: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr
On 09/08/2010 08:45 AM, Jim Meyering wrote: If bash is manually installed, then things are okay. But all existing shells on a bare-bones installation output trace information. If that happens, the result will be that each init.sh-using test will be skipped. Fair enough - someone with enough incentive to test on that type of platform can resolve the issue by manually installing a better shell, particularly if the skip message hints at that being the problem. Polluting our code, even "mere" tests, solely to accommodate an inferior or old system is hard for me to justify. I think it scales better simply to eliminate the offending shells -- then we avoid the constant overhead of auditing for yet another portability nit. Seems reasonable - give ourselves the guarantee now, and if it proves to strict, then back it out and do the audit then, rather than spending time on the audit now. Besides, isn't Irix 5.x approaching effective museum-only status? Probably, but I don't (yet) have access to Irix 6.5 to test a newer version of that platform. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr
On 09/08/2010 07:20 AM, Jim Meyering wrote: grep portability testing has exposed some unwarranted test failures. Using a better SHELL was the quick work-around. Fixing init.sh is the real fix: From d79a9c27419cc4679620b9283351566ba6085cd2 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 8 Sep 2010 15:18:46 +0200 Subject: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr I'm a little worried that this patch might exclude all shells on a given platform. For example, on IRIX 5.3: $ /bin/sh -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null' P=1 $ /bin/ksh -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null' + P=1 $ bash -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null' $ If bash is manually installed, then things are okay. But all existing shells on a bare-bones installation output trace information. Maybe a compromise is to test that if there is output, is it at least proceeded by PS4 (in which case it can be filtered), so as not to outright rejecting /bin/ksh, but still exclude /bin/sh as unfilterable? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr
On Wednesday 08 September 2010, Eric Blake wrote: > On 09/08/2010 07:20 AM, Jim Meyering wrote: > > Subject: [PATCH] init.sh: disqualify shells for which set -x > > corrupts stderr > > I'm a little worried that this patch might exclude all shells on a > given platform. For example, on IRIX 5.3: > > $ /bin/sh -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null' > P=1 > $ /bin/ksh -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null' > + P=1 > $ bash -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null' > $ JFTR, with Zsh 4.3 on Debian: $ zsh -c '(exec 3>&1; set -x; P=1 true 2>&3) 2>/dev/null' +zsh:1> P=1 +zsh:1> true The problem doesn't appear with earlier versions of Zsh (tested: 4.0.1, 4.2.0, 3.0.8). Regards, Stefano
Adding xstat support
Here's the best link I could quickly find summarizing the recent kernel discussions: http://groups.google.com/group/linux.kernel/browse_thread/thread/65f244ddf6829edf/4273489273fb9797?lnk=raot&pli=1 As far as I can tell, the proposed xstat patch has not yet hit the kernel proper, so we don't want to code to an interface that isn't yet set in stone. But once xstat() does hit, it offers the potential to provide some large speedups to programs like ls(1) and find(1), by letting the caller choose how much work the kernel must do rather than forcing the kernel to completely populate struct stat only for the caller to then ignore that work. Meanwhile, cygwin is considering adding support for xstat() once the Linux interface is set in stone, where it has the potential for even more significant speedups. At any rate, it seems like it should be fairly simple to write a gnulib wrapper for xstat() - on platforms that lack the kernel call, simply call the full stat(). And it also seems like it would be nice to start thinking about which utilities can start being written to use xstat() instead of [l]stat() for faster performance in the case where kernel support exists. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
unsetenv test failure on openbsd 4.7
FYI,
No big deal, and no rush for such a corner case...
This certainly doesn't matter to grep.
While testing for grep, I hit this:
$ ./test-unsetenv
test-unsetenv.c:49: assertion failed
Abort trap (core dumped)
[Exit 134 (SIGABRT)]
It failed on this line:
ASSERT (putenv ("") == -1);
The actual return value is 0.
[PATCH] strtod: work around IRIX 6.5 bug
IRIX mis-parses "1e 1" as 10.0 and "" instead of 1.0 and "e 1".
Because the original parse may differ from the reparse in terms
of whether the value overflows, we have to do an errno dance.
* lib/strtod.c (strtod): Reparse number on shorter string if
exponent parse was invalid.
* tests/test-strtod.c (main): Add check for "0x1p 2".
Reported by Tom G. Christensen.
Signed-off-by: Eric Blake
---
> I applied this on top of a fresh gnulib checkout and unfortunately the
> test still fails in the same place.
Ah, because I had a one-line typo:
>> + dup[e - s] = '\0';
>> + num = underlying_strtod (s, &endbuf);
Should be: num = underlying_strtod (dup, &endbuf);
At any rate, I've now enhanced the testsuite, and verified that strtod
now passes on IRIX 5.3.
ChangeLog |6 ++
lib/strtod.c| 32
tests/test-strtod.c | 30 ++
3 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index d880808..9fb8803 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
2010-09-08 Eric Blake
+ strtod: work around IRIX 6.5 bug
+ * lib/strtod.c (strtod): Reparse number on shorter string if
+ exponent parse was invalid.
+ * tests/test-strtod.c (main): Add check for "0x1p 2".
+ Reported by Tom G. Christensen.
+
getopt: optimize previous patch
* m4/getopt.m4 (gl_GETOPT_CHECK_HEADERS): Correctly check for
empty variable. Speed up awk script.
diff --git a/lib/strtod.c b/lib/strtod.c
index 64b62ff..060dffa 100644
--- a/lib/strtod.c
+++ b/lib/strtod.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "c-ctype.h"
@@ -202,6 +203,7 @@ strtod (const char *nptr, char **endptr)
const char *s = nptr;
const char *end;
char *endbuf;
+ int saved_errno;
/* Eat whitespace. */
while (locale_isspace (*s))
@@ -212,6 +214,7 @@ strtod (const char *nptr, char **endptr)
if (*s == '-' || *s == '+')
++s;
+ saved_errno = errno;
num = underlying_strtod (s, &endbuf);
end = endbuf;
@@ -239,6 +242,35 @@ strtod (const char *nptr, char **endptr)
end = p;
}
}
+ else
+{
+ /* If "1e 1" was misparsed as 10.0 instead of 1.0, re-do the
+ underlying strtod on a copy of the original string
+ truncated to avoid the bug. */
+ const char *e = s + 1;
+ while (e < end && c_tolower (*e) != 'e')
+e++;
+ if (e < end && ! c_isdigit (e[1 + (e[1] == '-' || e[1] == '+')]))
+{
+ char *dup = strdup (s);
+ errno = saved_errno;
+ if (!dup)
+{
+ /* Not really our day, is it. Rounding errors are
+ better than outright failure. */
+ num = parse_number (s, 10, 10, 1, 'e', &endbuf);
+}
+ else
+{
+ dup[e - s] = '\0';
+ num = underlying_strtod (dup, &endbuf);
+ saved_errno = errno;
+ free (dup);
+ errno = saved_errno;
+}
+ end = e;
+}
+}
s = end;
}
diff --git a/tests/test-strtod.c b/tests/test-strtod.c
index 694e15d..e1d04af 100644
--- a/tests/test-strtod.c
+++ b/tests/test-strtod.c
@@ -558,6 +558,26 @@ main (void)
ASSERT (ptr == input + 10);
ASSERT (errno == ERANGE);
}
+ {
+const char input[] = "1E 100";
+char *ptr;
+double result;
+errno = 0;
+result = strtod (input, &ptr);
+ASSERT (result == 1.0); /* HP-UX 11.11, IRIX 6.5, OSF/1 4.0 */
+ASSERT (ptr == input + 1); /* HP-UX 11.11, IRIX 6.5 */
+ASSERT (errno == 0);
+ }
+ {
+const char input[] = "0x1P 100";
+char *ptr;
+double result;
+errno = 0;
+result = strtod (input, &ptr);
+ASSERT (result == 1.0); /* NetBSD 3.0, OpenBSD 4.0, AIX 7.1,
HP-UX 11.11, IRIX 6.5, OSF/1 5.1, Solaris 10, mingw */
+ASSERT (ptr == input + 3); /* NetBSD 3.0, OpenBSD 4.0, AIX 7.1,
HP-UX 11.11, IRIX 6.5, OSF/1 5.1, Solaris 10, mingw */
+ASSERT (errno == 0);
+ }
/* Infinity. */
{
@@ -831,6 +851,16 @@ main (void)
ASSERT (ptr == input + 6); /* NetBSD 3.0, OpenBSD 4.0, AIX 5.1,
HP-UX 11.11, IRIX 6.5, OSF/1 5.1, Solaris 10, mingw */
ASSERT (errno == 0);
}
+ {
+const char input[] = "0x1p 2";
+char *ptr;
+double result;
+errno = 0;
+result = strtod (input, &ptr);
+ASSERT (result == 1.0); /* NetBSD 3.0, OpenBSD 4.0, AIX 7.1,
HP-UX 11.11, IRIX 6.5, OSF/1 5.1, Solaris 10, mingw */
+ASSERT (ptr == input + 3); /* NetBSD 3.0, OpenBSD 4.0, AIX 7.1,
HP-UX 11.11, IRIX 6.5, OSF/1 5.1, Solaris 10, mingw */
+ASSERT (errno == 0);
+ }
/* Large buffers. */
{
--
1.7.2
Re: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr
* Eric Blake wrote on Wed, Sep 08, 2010 at 04:58:11PM CEST: > On 09/08/2010 08:45 AM, Jim Meyering wrote: > >Besides, isn't Irix 5.x approaching effective museum-only status? > > Probably, but I don't (yet) have access to Irix 6.5 to test a newer > version of that platform. sh and ksh on IRIX 6.5 also produce output, but at least both now prepend '+ ', and ineligible bsh also prints 'P=1'. No bash in /usr/bin here. Cheers, Ralf
Re: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr
Ralf Wildenhues wrote: > * Eric Blake wrote on Wed, Sep 08, 2010 at 04:58:11PM CEST: >> On 09/08/2010 08:45 AM, Jim Meyering wrote: >> >Besides, isn't Irix 5.x approaching effective museum-only status? >> >> Probably, but I don't (yet) have access to Irix 6.5 to test a newer >> version of that platform. > > sh and ksh on IRIX 6.5 also produce output, but at least both now > prepend '+ ', and ineligible bsh also prints 'P=1'. No bash in > /usr/bin here. Thanks, Ralf. Irix 6.5 is slated to have support at least until December 2013, so I may be stuck... Hmm... an alternative solution is simply to disable the VERBOSE=yes -> "set -x" code on offending systems. That will make debugging things a little harder (when using the broken shells), but that's still better than the alternative.
Re: [PATCH] strtod: work around IRIX 6.5 bug
On Wed, Sep 08, 2010 at 11:29:21AM -0600, Eric Blake wrote: > IRIX mis-parses "1e 1" as 10.0 and "" instead of 1.0 and "e 1". > Because the original parse may differ from the reparse in terms > of whether the value overflows, we have to do an errno dance. > > * lib/strtod.c (strtod): Reparse number on shorter string if > exponent parse was invalid. > * tests/test-strtod.c (main): Add check for "0x1p 2". > Reported by Tom G. Christensen. > I can confirm this also fixes the issue on IRIX 6.5. -tgc
[PATCH] unsetenv: fix OpenBSD bug
* m4/setenv.m4 (gl_FUNC_UNSETENV): Check for FreeBSD bug.
* doc/posix-functions/unsetenv.texi (unsetenv): Update
documentation.
Reported by Jim Meyering.
Signed-off-by: Eric Blake
---
> No big deal, and no rush for such a corner case...
> This certainly doesn't matter to grep.
> It failed on this line:
> ASSERT (putenv ("") == -1);
Minor or not, the fix was easy. In moving from 3.8 to 4.7, the
OpenBSD folks have fixed some, but not all, of the bugs that they have
in unsetenv.
ChangeLog |6 ++
doc/posix-functions/unsetenv.texi |4 ++--
m4/setenv.m4 |6 --
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 9fb8803..328400f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
2010-09-08 Eric Blake
+ unsetenv: fix OpenBSD bug
+ * m4/setenv.m4 (gl_FUNC_UNSETENV): Check for FreeBSD bug.
+ * doc/posix-functions/unsetenv.texi (unsetenv): Update
+ documentation.
+ Reported by Jim Meyering.
+
strtod: work around IRIX 6.5 bug
* lib/strtod.c (strtod): Reparse number on shorter string if
exponent parse was invalid.
diff --git a/doc/posix-functions/unsetenv.texi
b/doc/posix-functions/unsetenv.texi
index 8a683f5..56819bb 100644
--- a/doc/posix-functions/unsetenv.texi
+++ b/doc/posix-functions/unsetenv.texi
@@ -4,7 +4,7 @@ unsetenv
POSIX specification:@*
@url{http://www.opengroup.org/onlinepubs/9699919799/functions/unsetenv.html}
-Gnulib module: setenv
+Gnulib module: unsetenv
Portability problems fixed by Gnulib:
@itemize
@@ -18,7 +18,7 @@ unsetenv
@item
On some platforms, this function does not fail with @samp{EINVAL} when
passed an empty string or a string containing @samp{=}:
-FreeBSD 6.0, NetBSD 1.6, OpenBSD 3.8.
+FreeBSD 6.0, NetBSD 1.6, OpenBSD 4.7.
@item
This function removes only the first value association for the given
environment variable, not all of them, on some platforms:
diff --git a/m4/setenv.m4 b/m4/setenv.m4
index 5a800d3..133f163 100644
--- a/m4/setenv.m4
+++ b/m4/setenv.m4
@@ -1,4 +1,4 @@
-# setenv.m4 serial 17
+# setenv.m4 serial 18
dnl Copyright (C) 2001-2004, 2006-2010 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -78,7 +78,8 @@ int unsetenv();
fi
dnl Solaris 10 unsetenv does not remove all copies of a name.
-AC_CACHE_CHECK([whether unsetenv works on duplicates],
+dnl OpenBSD 4.7 unsetenv("") does not fail.
+AC_CACHE_CHECK([whether unsetenv obeys POSIX],
[gl_cv_func_unsetenv_works],
[AC_RUN_IFELSE([AC_LANG_PROGRAM([[
#include
@@ -89,6 +90,7 @@ int unsetenv();
entry[0] = 'a';
unsetenv ("a");
if (getenv ("a")) return 3;
+ if (!getenv ("")) return 4;
]])],
[gl_cv_func_unsetenv_works=yes], [gl_cv_func_unsetenv_works=no],
[gl_cv_func_unsetenv_works="guessing no"])])
--
1.7.2.2
Re: [PATCH] unsetenv: fix OpenBSD bug
On 09/08/2010 01:54 PM, Eric Blake wrote:
Minor or not, the fix was easy. In moving from 3.8 to 4.7, the
OpenBSD folks have fixed some, but not all, of the bugs that they have
in unsetenv.
@@ -89,6 +90,7 @@ int unsetenv();
entry[0] = 'a';
unsetenv ("a");
if (getenv ("a")) return 3;
+ if (!getenv ("")) return 4;
Oops - that better be unsetenv, not getenv. I'm retesting now, but
don't suspect much will change, as I've already verified that marking
gl_cv_func_unsetenv_works=no is sufficient to pass test-unsetenv on OpenBSD.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
Re: [PATCH] unsetenv: fix OpenBSD bug
On Wednesday 08 September 2010, Eric Blake wrote: > * m4/setenv.m4 (gl_FUNC_UNSETENV): Check for FreeBSD bug. Souldn't it be `OpenBSD bug'? (Ditto for the ChangeLog entry) Regards, Stefano
Re: [PATCH] unsetenv: fix OpenBSD bug
On 09/08/2010 02:00 PM, Stefano Lattarini wrote: On Wednesday 08 September 2010, Eric Blake wrote: * m4/setenv.m4 (gl_FUNC_UNSETENV): Check for FreeBSD bug. Souldn't it be `OpenBSD bug'? (Ditto for the ChangeLog entry) Yep - thanks for the careful review, and I'm glad I didn't push yet. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
strstr broken on alpha GNU/Linux
I received an off-list report of a test-strstr failure on m4 1.4.15: Linux xxx 2.6.34-gentoo-r1 #1 SMP Sun Aug 8 17:45:07 MDT 2010 alpha GNU/Linux gcc (Gentoo 4.4.3-r2 p1.2) 4.4.3 /bin/sh: line 1: 30207 Segmentation fault (core dumped) EXEEXT='' srcdir='.' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LIBSIGSEGV='/usr/local/lib/libsigsegv.a -lc' LOCALE_FR='fr_FR' LOCALE_TR_UTF8='tr_TR.UTF-8' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' PATH='/local/build/cc/m4-1.4.15/build-aux':"$PATH" PATH='/local/build/cc/m4-1.4.15/build-aux':"$PATH" MAKE='make' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' "$tst" > test-strstr.log-t 2>&1 FAIL: test-strstr I'm not sure which version of glibc is running on this platform, but it seems like we should be working around this bug (and also reporting it to glibc, if it hasn't yet been fixed there). I'm also trying to see if I can log in to that machine and reproduce precisely which search is causing the out-of-bounds reference from glibc's strstr implementation. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: Updated and completed patches to regex.texi
Thanks, Karl. I take it that someone did review my patches? (Not mentioned either in this thread or on the commit log AFAICS, except Paolo saying he was going to.)
Re: strstr broken on alpha GNU/Linux
On Wednesday, September 08, 2010 16:36:13 Eric Blake wrote: > I received an off-list report of a test-strstr failure on m4 1.4.15: > > Linux xxx 2.6.34-gentoo-r1 #1 SMP Sun Aug 8 17:45:07 MDT 2010 alpha > GNU/Linux > gcc (Gentoo 4.4.3-r2 p1.2) 4.4.3 > > /bin/sh: line 1: 30207 Segmentation fault (core dumped) EXEEXT='' > srcdir='.' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' > LIBSIGSEGV='/usr/local/lib/libsigsegv.a -lc' LOCALE_FR='fr_FR' > LOCALE_TR_UTF8='tr_TR.UTF-8' LOCALE_FR='fr_FR' > LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' > LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR_UTF8='fr_FR.UTF-8' > LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' > PATH='/local/build/cc/m4-1.4.15/build-aux':"$PATH" > PATH='/local/build/cc/m4-1.4.15/build-aux':"$PATH" MAKE='make' > LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP' > LOCALE_ZH_CN='zh_CN.GB18030' "$tst" > test-strstr.log-t 2>&1 > FAIL: test-strstr > > I'm not sure which version of glibc is running on this platform, but it > seems like we should be working around this bug (and also reporting it > to glibc, if it hasn't yet been fixed there). I'm also trying to see if > I can log in to that machine and reproduce precisely which search is > causing the out-of-bounds reference from glibc's strstr implementation. if you cant, then i have Gentoo alpha systems as well i can add you to -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr
Jim Meyering wrote:
> Ralf Wildenhues wrote:
>> * Eric Blake wrote on Wed, Sep 08, 2010 at 04:58:11PM CEST:
>>> On 09/08/2010 08:45 AM, Jim Meyering wrote:
>>> >Besides, isn't Irix 5.x approaching effective museum-only status?
>>>
>>> Probably, but I don't (yet) have access to Irix 6.5 to test a newer
>>> version of that platform.
>>
>> sh and ksh on IRIX 6.5 also produce output, but at least both now
>> prepend '+ ', and ineligible bsh also prints 'P=1'. No bash in
>> /usr/bin here.
>
> Thanks, Ralf.
>
> Irix 6.5 is slated to have support at least until December 2013,
> so I may be stuck...
>
> Hmm... an alternative solution is simply to disable the
> VERBOSE=yes -> "set -x" code on offending systems.
> That will make debugging things a little harder (when using
> the broken shells), but that's still better than the alternative.
Here's a patch that does that.
At first I did just this:
Subject: [PATCH] test.sh: penalize a set-x-impaired shell; don't disqualify it
* tests/init.sh: Too many shells corrupt application stderr when
you set -x, so we can't afford to disqualify them, since at least
on Irix-6.5, that would disqualify all bourne shells. Instead,
when VERBOSE=yes is requested and set -x might cause trouble,
simply issue a warning and refrain from enabling debug output.
---
ChangeLog |9 +
tests/init.sh | 17 -
But that's no good if your initial shell is zsh: VERBOSE=yes would
not do anything useful for you, whereas it could work fine if
you have bash, dash, etc. available.
Then I realized I could do even better:
[this is not yet well tested]
>From f0e462d8625bb3820a26d39920e8698edaff79a5 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Wed, 8 Sep 2010 22:24:22 +0200
Subject: [PATCH] init.sh: penalize a set-x-impaired shell; don't disqualify it
* tests/init.sh: Too many shells corrupt application stderr when
you set -x, so we can't afford to disqualify them, since at least
on Irix-6.5, that would disqualify all bourne shells.
Instead, use a two-pass approach.
On the first pass, try to find a shell that meets the stricter
condition that set -x does not corrupt stderr.
If no shell meets the stricter condition, retest each candidate
shell, but without that extra condition. Finally, when
VERBOSE=yes is requested and set -x might cause trouble, simply
issue a warning and refrain from enabling debug output.
---
ChangeLog | 14
tests/init.sh | 63 ++--
2 files changed, 57 insertions(+), 20 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 82937ac..2ac4e00 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2010-09-08 Jim Meyering
+
+ init.sh: penalize a set-x-impaired shell; don't disqualify it
+ * tests/init.sh: Too many shells corrupt application stderr when
+ you set -x, so we can't afford to disqualify them, since at least
+ on Irix-6.5, that would disqualify all bourne shells.
+ Instead, use a two-pass approach.
+ On the first pass, try to find a shell that meets the stricter
+ condition that set -x does not corrupt stderr.
+ If no shell meets the stricter condition, retest each candidate
+ shell, but without that extra condition. Finally, when
+ VERBOSE=yes is requested and set -x might cause trouble, simply
+ issue a warning and refrain from enabling debug output.
+
2010-09-08 Eric Blake
unsetenv: fix OpenBSD bug
diff --git a/tests/init.sh b/tests/init.sh
index 9886a8d..690da63 100644
--- a/tests/init.sh
+++ b/tests/init.sh
@@ -109,9 +109,16 @@ fi
# Use "9" to indicate success (rather than 0), in case some shell acts
# like Solaris 10's /bin/sh but exits successfully instead of with status 2.
+# Whether to reject a shell for which "set -x" corrupts stderr.
+strict_=yes
+
+gl_set_x_corrupts_stderr_='$( (exec 3>&1; set -x; P=1 true 2>&3) 2> /dev/null)'
+
gl_shell_test_script_='
test $(echo y) = y || exit 1
-test -z "$( (exec 3>&1; set -x; P=1 true 2>&3) 2> /dev/null)" || exit 1
+if test $strict_ = yes && test -n "$gl_set_x_corrupts_stderr_"; then
+ exit 1
+fi
test -z "$EXEEXT" && exit 9
shopt -s expand_aliases
alias a-b="echo zoo"
@@ -132,24 +139,29 @@ else
if test $? = 9; then
: # The current shell is adequate. No re-exec required.
else
-# Search for a shell that meets our requirements.
-for re_shell_ in "${CONFIG_SHELL:-no_shell}" /bin/sh bash dash zsh pdksh
fail
-do
- test "$re_shell_" = no_shell && continue
- test "$re_shell_" = fail && skip_ failed to find an adequate shell
- "$re_shell_" -c "$gl_shell_test_script_" 2>/dev/null
- if test $? = 9; then
-# Found an acceptable shell. Preserve -v and -x.
-case $- in
- *v*x* | *x*v*) opts_=-vx ;;
- *v*) opts_=-v ;;
- *x*) opts_=-x ;;
- *) opts_= ;;
-esac
-exec "$re_shell_" $opts_ "$0" --no-reexec "$@"
-
Re: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr
On 09/08/2010 03:17 PM, Jim Meyering wrote:
+# Whether to reject a shell for which "set -x" corrupts stderr.
+strict_=yes
+
+gl_set_x_corrupts_stderr_='$( (exec 3>&1; set -x; P=1 true 2>&3) 2>
/dev/null)'
+
gl_shell_test_script_='
test $(echo y) = y || exit 1
-test -z "$( (exec 3>&1; set -x; P=1 true 2>&3) 2> /dev/null)" || exit 1
+if test $strict_ = yes&& test -n "$gl_set_x_corrupts_stderr_"; then
+ exit 1
+fi
Hmm - the value of $strict_ and $gl_set_x_corrupts_stderr_ are known to
the parent shell, but not exported to the child shell.
+for strict_ in yes no; do
Reusing the same variable as you set earlier will leave $strict_ in the
last state that it was in during the shell search. Is that intended, or
should you be iterating on a different variable name?
+ # Search for a shell that meets our requirements.
+ for re_shell_ in "${CONFIG_SHELL:-no_shell}" /bin/sh bash dash zsh pdksh
+ do
+test "$re_shell_" = no_shell&& continue
+test "$re_shell_" = fail&& skip_ failed to find an adequate shell
+"$re_shell_" -c "$gl_shell_test_script_" 2>/dev/null
You either need an eval on this line (to expand the embedded $strict_
within $gl_shell_test_script_), or you need to export some variables.
Another thought - why do two passes? Maybe a better option would be
doing one pass, with two successful exit statuses (9 if the shell can't
use set -x but otherwise works, 10 if the shell does both); then iterate
until you either find a 10, or else pick the first shell that gave 9.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
Re: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr
Eric Blake wrote:
> On 09/08/2010 03:17 PM, Jim Meyering wrote:
>>
>> +# Whether to reject a shell for which "set -x" corrupts stderr.
>> +strict_=yes
>> +
>> +gl_set_x_corrupts_stderr_='$( (exec 3>&1; set -x; P=1 true 2>&3) 2>
>> /dev/null)'
>> +
>> gl_shell_test_script_='
>> test $(echo y) = y || exit 1
>> -test -z "$( (exec 3>&1; set -x; P=1 true 2>&3) 2> /dev/null)" || exit 1
>> +if test $strict_ = yes&& test -n "$gl_set_x_corrupts_stderr_"; then
>> + exit 1
>> +fi
>
> Hmm - the value of $strict_ and $gl_set_x_corrupts_stderr_ are known
> to the parent shell, but not exported to the child shell.
>
>> +for strict_ in yes no; do
>
> Reusing the same variable as you set earlier will leave $strict_ in
> the last state that it was in during the shell search. Is that
> intended, or should you be iterating on a different variable name?
>
>> + # Search for a shell that meets our requirements.
>> + for re_shell_ in "${CONFIG_SHELL:-no_shell}" /bin/sh bash dash zsh
>> pdksh
>> + do
>> +test "$re_shell_" = no_shell&& continue
>> +test "$re_shell_" = fail&& skip_ failed to find an adequate shell
>> +"$re_shell_" -c "$gl_shell_test_script_" 2>/dev/null
>
> You either need an eval on this line (to expand the embedded $strict_
> within $gl_shell_test_script_), or you need to export some variables.
Thanks for the quick review.
I noticed that one right away ;-)
Incremental below:
I'll address your other points after some sleep.
> Another thought - why do two passes? Maybe a better option would be
> doing one pass, with two successful exit statuses (9 if the shell
> can't use set -x but otherwise works, 10 if the shell does both); then
> iterate until you either find a 10, or else pick the first shell that
> gave 9.
diff --git a/tests/init.sh b/tests/init.sh
index 690da63..8064495 100644
--- a/tests/init.sh
+++ b/tests/init.sh
@@ -287,7 +287,9 @@ setup_()
# from SunOS 5.11, OpenBSD 4.7 and Irix 5.x and 6.5.
# If enabling verbose output this way would cause trouble, simply
# issue a warning and refrain.
-if test -n "$gl_set_x_corrupts_stderr_"; then
+ set -x
+gl_corrupt_=$(eval "$gl_set_x_corrupts_stderr_")
+if test -n "$gl_corrupt_"; then
warn_ "using SHELL=$SHELL with 'set -x' corrupts stderr"
else
set -x
Re: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr
Hi Jim, > They make it so with "set -x", environment settings > appear in stderr output. For example, this command: > /bin/sh -c 'set -x; P=1 true 2> err' 2>/dev/null; cat err > prints "P=1" on those two systems: This test disqualifies also 'ksh', which is considered the "good" shell on Solaris, AIX, and a number of other systems: I executed the command (set -x; P=1 true > inner-out 2> inner-err) > outer-out 2> outer-err with a number of shells. Results: inner-out and outer-out were always empty, and | inner-err | outer-err| -++--+ Solaris 10 /bin/sh | P=1| + true | -++--+ ksh-93s | + P=1 | + true | Solaris 10 /bin/ksh || + 1> inner-out 2> inner-err | -++--+ bash 3.2.39 || + P=1| || + true | -++--+ dash || + P=1 true | -++--+ zsh 4.3.6|| +zsh:3> P=1 +zsh:3> true | -++--+ > the result will be that each init.sh-using test > will be skipped. I don't find this a good result. Observe this: - Looking at the stderr output of some programs started with environment variables happens in some tests, but is not very frequent. - When you analyze the stderr output of programs, you need to filter out all lines that start with '==' also, because these are the marks emitted by valgrind. - When you are at it, you can also filter out all lines that start with '+'. - The only remaining problematic shell is then Solaris 10 /bin/sh, which is already disqualified by test $(echo y) = y So, instead of skipping all init.sh based tests on some platforms, I would propose - either to skip only if 'set -x' is enabled; this can be tested by test -z "$( (P=1 true 2>&1) 2> /dev/null)" - or to handle this problem in each test that analyzes the stderr output of some program. Bruno
Re: [PATCH] init.sh: disqualify shells for which set -x corrupts stderr
For your possible amusement, I managed to induce Chet to augment BASH with BASH_XTRACEFD. It surely won't help here, but it will make BASH debugging a lot easier. (I had to debug scripts that knew that if there were *any* output to stderr, then the test had to have failed. And there were enough modules and enough layers that modifying BASH was easier than fixing scripts.)
Re: failure to build due to ignoring fwrite() result
Here's a proposed rewrite that tries to take all the comments in mind, while trying to improve the prose a bit. FWIW, this standards.texi change looked good to me. I sent it to rms. Thanks to all.
cloning gnulib from behind a firewall
I'd like to clone gnulib from behind my company's firewall. The ports for git and cvs are closed, so I tried http, and obtained the error below. export http_proxy=... git clone http://git.savannah.gnu.org/gnulib.git Cloning into gnulib... fatal: http://git.savannah.gnu.org/gnulib.git/info/refs not found: did you run git update-server-info on the server? I'm a novice regarding git, but this looks to me like my problem requires a solution on the savannah end, correct? Any help that would allow me to grab a copy of gnulib while behind the firewall would be appreciated. TiA Ben
Re: cloning gnulib from behind a firewall
On 09/08/2010 01:00 PM, Ben Abbott wrote: I'd like to clone gnulib from behind my company's firewall. The ports for git and cvs are closed, so I tried http, and obtained the error below. export http_proxy=... git clone http://git.savannah.gnu.org/gnulib.git Cloning into gnulib... fatal: http://git.savannah.gnu.org/gnulib.git/info/refs not found: did you run git update-server-info on the server? I'm a novice regarding git, but this looks to me like my problem requires a solution on the savannah end, correct? Yes, savannah would have to set up an http server. But have no fear - the people at repo.or.cz have already set up a clone that mirrors the savannah repository (browse it at http://repo.or.cz/w/gnulib.git), and that mirror provides http service that is usually less than an hour or two behind savannah. So you can instead clone from: git clone http://repo.or.cz/r/gnulib.git In fact, I've set up several mirrors on repo.or.cz precisely because I used to work at a job where I was behind a firewall that allowed only http access. And I found it helpful to do something like: git config --global url.http://repo.or.cz/r/.insteadof \ git://git.sv.gnu.org:/srv/git/ such that cloning other projects like coreutils.git and running bootstrap would then automatically rewrite the submodule URLs to likewise pull from the same location. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: cloning gnulib from behind a firewall
Hi Ben, I am able to clone Savannah's projects via http. The general format is http://git.sv.gnu.org/r/.git. So, git clone http://git.sv.gnu.org/r/gnulib.git should work for you. FYI, you can also browse the source via gitweb: http://git.savannah.gnu.org/gitweb/ Hope this helps, -Mike On Wed, Sep 8, 2010 at 3:00 PM, Ben Abbott wrote: > > I'd like to clone gnulib from behind my company's firewall. > > The ports for git and cvs are closed, so I tried http, and obtained the error > below. > > export http_proxy=... > git clone http://git.savannah.gnu.org/gnulib.git > Cloning into gnulib... > fatal: http://git.savannah.gnu.org/gnulib.git/info/refs not found: did > you run git update-server-info on the server? > > I'm a novice regarding git, but this looks to me like my problem requires a > solution on the savannah end, correct? > > Any help that would allow me to grab a copy of gnulib while behind the > firewall would be appreciated. > > TiA > Ben >
