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'
> a
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
[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_
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 "$g
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] ini
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
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
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 200
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
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,
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:
>
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 w
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);
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
* 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
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 plat
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 numbe
* 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 thi
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 ("
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
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.
--
E
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_UTF
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.)
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
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 n
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 -
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)
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 Sola
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 mo
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.
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.savanna
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
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 We
33 matches
Mail list logo
