GNU bug report logs - #10465
MSYS read-only file trouble

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10465 in the body.
You can then email your comments to 10465 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: bug-automake <at> gnu.org
Subject: MSYS read-only file trouble
Date: Mon, 09 Jan 2012 11:58:48 +0100

Hi!

MSYS will not allow redirecting on top of an existing r/o file,
even if the dir is r/w, like this:

$ mkdir foo
$ ls -do foo
drwxr-xr-x 2 peda 0 Jan  9 11:02 foo
$ cd foo
$ touch bar
$ chmod a-w bar
$ ls > bar
bash: bar: Permission denied
$ cat bar
$

I think the above causes a testsuite failure for tap-driver-stderr.test.

Cheers,
Peter

For reference, tap-driver-stderr.log:

Running from installcheck: no
Using TAP: no
PATH = /home/peda/automake/tests:/c/Program Files (x86)/Microsoft F#/v4.0/:/c/Program Files (x86)/Microsoft Visual Studio 10.0/VSTSDB/Deploy:/c/Program Files (x86)/Microsoft Visual Studio 10.0/Common7/IDE/:/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/BIN:/c/Program Files (x86)/Microsoft Visual Studio 10.0/Common7/Tools/:/c/Windows/Microsoft.NET/Framework/v4.0.30319:/c/Windows/Microsoft.NET/Framework/v3.5:/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/VCPackages:/c/Program Files (x86)/HTML Help Workshop:/c/Program Files (x86)/Microsoft Visual Studio 10.0/Team Tools/Performance Tools:/c/Program Files (x86)/Microsoft SDKs/Windows/v7.0A/bin/NETFX 4.0 Tools:.:/usr/local/bin:/mingw/bin:/bin:/c/Program Files/Common Files/Microsoft Shared/Windows Live:/c/Program Files (x86)/Common Files/Microsoft Shared/Windows Live:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/
./defs: line 805: priv-check.11388: Permission denied
++ pwd
/home/peda/automake/tests/tap-driver-stderr.dir
+ fetch_tap_driver
+ case $am_tap_implementation in
+ sed '1s|#!.*|#! /bin/sh|' /home/peda/automake/lib/tap-driver.sh
+ chmod a+x tap-driver
+ sed 10q tap-driver
#! /bin/sh
# Copyright (C) 2011 Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
+ tst=zardoz
+ for suf in trs log
+ rm -f zardoz.log zardoz.trs
+ touch zardoz.trs
+ chmod a-w zardoz.trs
+ st=0
+ ./tap-driver --test-name zardoz --log-file zardoz.log --trs-file zardoz.trs -- sh -c 'echo 1..1; echo ok 1; echo "Hello, World!"'
+ cat stdout
PASS: zardoz 1
+ cat stderr
awk: cmd. line:324: (FILENAME=- FNR=4) fatal: can't redirect to `zardoz.trs' (Permission denied)
tap-driver.sh: fatal: I/O or internal error
+ cat zardoz.log
1..1
ok 1
PASS: zardoz 1
Hello, World!
+ cat zardoz.trs
+ test 0 -eq 0
+ /bin/grep -F 'Hello, World!' stderr stdout
+ /bin/grep -F zardoz.trs stderr
awk: cmd. line:324: (FILENAME=- FNR=4) fatal: can't redirect to `zardoz.trs' (Permission denied)
+ for suf in trs log
+ rm -f zardoz.log zardoz.trs
+ touch zardoz.log
+ chmod a-w zardoz.log
+ st=0
+ ./tap-driver --test-name zardoz --log-file zardoz.log --trs-file zardoz.trs -- sh -c 'echo 1..1; echo ok 1; echo "Hello, World!"'
+ st=1
+ cat stdout
+ cat stderr
./tap-driver: line 637: zardoz.log: Permission denied
+ cat zardoz.log
+ cat zardoz.trs
cat: zardoz.trs: No such file or directory
+ :
+ test 1 -eq 0
+ exit_status=1
+ set +e
+ cd /home/peda/automake/tests
+ test no = yes
+ case $am_explicit_skips in
+ test 1 -eq 0
+ keep_testdirs=yes
+ am_keeping_testdirs
+ case $keep_testdirs in
+ return 0
+ set +x
tap-driver-stderr: exit 1

Cheers,
Peter

Message #8 received at 10465 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 10465 <at> debbugs.gnu.org
Subject: Re: bug#10465: MSYS read-only file trouble
Date: Mon, 09 Jan 2012 20:03:45 +0100

On 01/09/2012 11:58 AM, Peter Rosin wrote:
> Hi!
>
Hi Peter.

> MSYS will not allow redirecting on top of an existing r/o file,
> even if the dir is r/w, like this:
> 
> $ mkdir foo
> $ ls -do foo
> drwxr-xr-x 2 peda 0 Jan  9 11:02 foo
> $ cd foo
> $ touch bar
> $ chmod a-w bar
> $ ls > bar
> bash: bar: Permission denied
> $ cat bar
> $
>
Which is good and POSIX-ish, no?

> I think the above causes a testsuite failure for tap-driver-stderr.test.
>
Unlikely: the test is expected to see a failure in the `tap-driver' script,
since that script is trying to write to a read-only file (an action which
should rightfully trigger an error); what we are actually checking is that
this failure is accompanied by a meaningful error message *which does not
get redirected to the test logs*.

Let's see what's happening ...

> Cheers,
> Peter
> 
> For reference, tap-driver-stderr.log:
> 
> Running from installcheck: no
> Using TAP: no
> PATH = /home/peda/automake/tests:/c/Program Files (x86)/Microsoft F#/v4.0/:/c/Program Files (x86)/Microsoft Visual Studio 10.0/VSTSDB/Deploy:/c/Program Files (x86)/Microsoft Visual Studio 10.0/Common7/IDE/:/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/BIN:/c/Program Files (x86)/Microsoft Visual Studio 10.0/Common7/Tools/:/c/Windows/Microsoft.NET/Framework/v4.0.30319:/c/Windows/Microsoft.NET/Framework/v3.5:/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/VCPackages:/c/Program Files (x86)/HTML Help Workshop:/c/Program Files (x86)/Microsoft Visual Studio 10.0/Team Tools/Performance Tools:/c/Program Files (x86)/Microsoft SDKs/Windows/v7.0A/bin/NETFX 4.0 Tools:.:/usr/local/bin:/mingw/bin:/bin:/c/Program Files/Common Files/Microsoft Shared/Windows Live:/c/Program Files (x86)/Common Files/Microsoft Shared/Windows Live:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/
> ./defs: line 805: priv-check.11388: Permission denied
> ++ pwd
> /home/peda/automake/tests/tap-driver-stderr.dir
> + fetch_tap_driver
> + case $am_tap_implementation in
> + sed '1s|#!.*|#! /bin/sh|' /home/peda/automake/lib/tap-driver.sh
> + chmod a+x tap-driver
> + sed 10q tap-driver
> #! /bin/sh
> # Copyright (C) 2011 Free Software Foundation, Inc.
> #
> # This program is free software; you can redistribute it and/or modify
> # it under the terms of the GNU General Public License as published by
> # the Free Software Foundation; either version 2, or (at your option)
> # any later version.
> #
> # This program is distributed in the hope that it will be useful,
> # but WITHOUT ANY WARRANTY; without even the implied warranty of
> + tst=zardoz
> + for suf in trs log
> + rm -f zardoz.log zardoz.trs
> + touch zardoz.trs
> + chmod a-w zardoz.trs
> + st=0
> + ./tap-driver --test-name zardoz --log-file zardoz.log --trs-file zardoz.trs -- sh -c 'echo 1..1; echo ok 1; echo "Hello, World!"'
> + cat stdout
> PASS: zardoz 1
> + cat stderr
> awk: cmd. line:324: (FILENAME=- FNR=4) fatal: can't redirect to `zardoz.trs' (Permission denied)
> tap-driver.sh: fatal: I/O or internal error
>
So far so good: the error goes to stderr ...

> + cat zardoz.log
> 1..1
> ok 1
> PASS: zardoz 1
> Hello, World!
> + cat zardoz.trs
> + test 0 -eq 0
> + /bin/grep -F 'Hello, World!' stderr stdout
> + /bin/grep -F zardoz.trs stderr
> awk: cmd. line:324: (FILENAME=- FNR=4) fatal: can't redirect to `zardoz.trs' (Permission denied)
> + for suf in trs log
> + rm -f zardoz.log zardoz.trs
> + touch zardoz.log
> + chmod a-w zardoz.log
> + st=0
> + ./tap-driver --test-name zardoz --log-file zardoz.log --trs-file zardoz.trs -- sh -c 'echo 1..1; echo ok 1; echo "Hello, World!"'
> + st=1
>
Hmmm... looks like the shell is not returning a non-zero exit status in
face of a I/O redirection failure.

Could you try what happens doing the following?

  $ > foo; chmod a-w foo; sh -c ': > foo; echo one: $?'; echo two: $?

> + cat stdout
> + cat stderr
> ./tap-driver: line 637: zardoz.log: Permission denied
>
(This is good as well BTW, this error goes to stderr too).

Thanks,
  Stefano

Message #11 received at 10465 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 10465 <at> debbugs.gnu.org
Subject: Re: bug#10465: MSYS read-only file trouble
Date: Mon, 09 Jan 2012 20:11:35 +0100

Stefano Lattarini skrev 2012-01-09 20:03:
>> + ./tap-driver --test-name zardoz --log-file zardoz.log --trs-file zardoz.trs -- sh -c 'echo 1..1; echo ok 1; echo "Hello, World!"'
>> + st=1
>>
> Hmmm... looks like the shell is not returning a non-zero exit status in
> face of a I/O redirection failure.
> 
> Could you try what happens doing the following?
> 
>   $ > foo; chmod a-w foo; sh -c ': > foo; echo one: $?'; echo two: $?

sh: foo: Permission denied
two: 1

Cheers,
Peter

Message #14 received at 10465 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 10465 <at> debbugs.gnu.org
Subject: Re: bug#10465: MSYS read-only file trouble
Date: Mon, 09 Jan 2012 20:52:49 +0100

On 01/09/2012 08:11 PM, Peter Rosin wrote:
> Stefano Lattarini skrev 2012-01-09 20:03:
>>> + ./tap-driver --test-name zardoz --log-file zardoz.log --trs-file zardoz.trs -- sh -c 'echo 1..1; echo ok 1; echo "Hello, World!"'
>>> + st=1
>>>
>> Hmmm... looks like the shell is not returning a non-zero exit status in
>> face of a I/O redirection failure.
>>
>> Could you try what happens doing the following?
>>
>>   $ > foo; chmod a-w foo; sh -c ': > foo; echo one: $?'; echo two: $?
> 
> sh: foo: Permission denied
> two: 1
> 
So the shell catches the redirection error correctly after all.  Hmmm.

Is the failure of tap-driver-stderr.test reproducible?

Regards,
  Stefano

Message #17 received at 10465 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 10465 <at> debbugs.gnu.org
Subject: Re: bug#10465: MSYS read-only file trouble
Date: Mon, 09 Jan 2012 23:14:31 +0100

Stefano Lattarini skrev 2012-01-09 20:52:
> On 01/09/2012 08:11 PM, Peter Rosin wrote:
>> Stefano Lattarini skrev 2012-01-09 20:03:
>>>> + ./tap-driver --test-name zardoz --log-file zardoz.log --trs-file zardoz.trs -- sh -c 'echo 1..1; echo ok 1; echo "Hello, World!"'
>>>> + st=1
>>>>
>>> Hmmm... looks like the shell is not returning a non-zero exit status in
>>> face of a I/O redirection failure.
>>>
>>> Could you try what happens doing the following?
>>>
>>>   $ > foo; chmod a-w foo; sh -c ': > foo; echo one: $?'; echo two: $?
>>
>> sh: foo: Permission denied
>> two: 1
>>
> So the shell catches the redirection error correctly after all.  Hmmm.
> 
> Is the failure of tap-driver-stderr.test reproducible?

Yes, fails in the same way every time.

Cheers,
Peter

Message #20 received at 10465 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 10465 <at> debbugs.gnu.org
Subject: Re: bug#10465: MSYS read-only file trouble
Date: Mon, 09 Jan 2012 23:42:22 +0100

Peter Rosin skrev 2012-01-09 23:14:
> Stefano Lattarini skrev 2012-01-09 20:52:
>> On 01/09/2012 08:11 PM, Peter Rosin wrote:
>>> Stefano Lattarini skrev 2012-01-09 20:03:
>>>>> + ./tap-driver --test-name zardoz --log-file zardoz.log --trs-file zardoz.trs -- sh -c 'echo 1..1; echo ok 1; echo "Hello, World!"'
>>>>> + st=1
>>>>>
>>>> Hmmm... looks like the shell is not returning a non-zero exit status in
>>>> face of a I/O redirection failure.
>>>>
>>>> Could you try what happens doing the following?
>>>>
>>>>   $ > foo; chmod a-w foo; sh -c ': > foo; echo one: $?'; echo two: $?
>>>
>>> sh: foo: Permission denied
>>> two: 1
>>>
>> So the shell catches the redirection error correctly after all.  Hmmm.
>>
>> Is the failure of tap-driver-stderr.test reproducible?
> 
> Yes, fails in the same way every time.

FWIW, this "fixes" it, but I don't actually know why a subshell would
make a difference?

$ sh --version
GNU bash, version 3.1.17(1)-release (i686-pc-msys)
Copyright (C) 2005 Free Software Foundation, Inc.

Cheers,
Peter

From c0bc106cbbd40225cd761124adaf434c004ad269 Mon Sep 17 00:00:00 2001
From: Peter Rosin <peda <at> lysator.liu.se>
Date: Mon, 9 Jan 2012 23:40:45 +0100
Subject: [PATCH] tap/awk: run the awk program in a subshell

MSYS bash (3.1.17) apparently has problems with the exit status of a
grouping without a subshell.

Fixes automake bug#10465.

* lib/tap-driver.sh: Use a full blown subshell for running the awk script.
---
 lib/tap-driver.sh |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/tap-driver.sh b/lib/tap-driver.sh
index c011298..6e9df79 100755
--- a/lib/tap-driver.sh
+++ b/lib/tap-driver.sh
@@ -115,7 +115,7 @@ else
   init_colors=''
 fi
 
-{
+(
   (
     # Ignore common signals (in this subshell only!), to avoid potential
     # problems with Korn shells.  Some Korn shells are known to propagate
@@ -634,7 +634,7 @@ exit 0
 '
 
 # TODO: document that we consume the file descriptor 3 :-(
-} 3>"$log_file"
+) 3>"$log_file"
 
 test $? -eq 0 || fatal "I/O or internal error"
 
-- 
1.7.5.1

Message #23 received at 10465 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 10465 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: Re: bug#10465: MSYS read-only file trouble
Date: Mon, 09 Jan 2012 16:34:31 -0700

[Message part 1 (text/plain, inline)]

On 01/09/2012 03:42 PM, Peter Rosin wrote:
> FWIW, this "fixes" it, but I don't actually know why a subshell would
> make a difference?
> 
> $ sh --version
> GNU bash, version 3.1.17(1)-release (i686-pc-msys)

>  
> -{
> +(
>    (
>      # Ignore common signals (in this subshell only!), to avoid potential
>      # problems with Korn shells.  Some Korn shells are known to propagate
> @@ -634,7 +634,7 @@ exit 0
>  '
>  
>  # TODO: document that we consume the file descriptor 3 :-(
> -} 3>"$log_file"
> +) 3>"$log_file"

Ah - the classic bash bug documented in the autoconf manual:

https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins

Bash 3.2 (and earlier versions) sometimes does not properly set ‘$?’
when failing to write redirected output of a compound command. This
problem is most commonly observed with ‘{...}’; it does not occur with
‘(...)’. For example:

          $ bash -c '{ echo foo; } >/bad; echo $?'
          bash: line 1: /bad: Permission denied
          0
          $ bash -c 'while :; do echo; done >/bad; echo $?'
          bash: line 1: /bad: Permission denied
          0

To work around the bug, prepend ‘:;’:

          $ bash -c ':;{ echo foo; } >/bad; echo $?'
          bash: line 1: /bad: Permission denied
          1

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #26 received at 10465 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Eric Blake <eblake <at> redhat.com>
Cc: 10465 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: Re: bug#10465: MSYS read-only file trouble
Date: Tue, 10 Jan 2012 00:52:41 +0100

Eric Blake skrev 2012-01-10 00:34:
> On 01/09/2012 03:42 PM, Peter Rosin wrote:
>> FWIW, this "fixes" it, but I don't actually know why a subshell would
>> make a difference?
>>
>> $ sh --version
>> GNU bash, version 3.1.17(1)-release (i686-pc-msys)
> 
>>  
>> -{
>> +(
>>    (
>>      # Ignore common signals (in this subshell only!), to avoid potential
>>      # problems with Korn shells.  Some Korn shells are known to propagate
>> @@ -634,7 +634,7 @@ exit 0
>>  '
>>  
>>  # TODO: document that we consume the file descriptor 3 :-(
>> -} 3>"$log_file"
>> +) 3>"$log_file"
> 
> Ah - the classic bash bug documented in the autoconf manual:
> 
> https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins
> 
> Bash 3.2 (and earlier versions) sometimes does not properly set ‘$?’
> when failing to write redirected output of a compound command. This
> problem is most commonly observed with ‘{...}’; it does not occur with
> ‘(...)’. For example:
> 
>           $ bash -c '{ echo foo; } >/bad; echo $?'
>           bash: line 1: /bad: Permission denied
>           0
>           $ bash -c 'while :; do echo; done >/bad; echo $?'
>           bash: line 1: /bad: Permission denied
>           0
> 
> To work around the bug, prepend ‘:;’:
> 
>           $ bash -c ':;{ echo foo; } >/bad; echo $?'
>           bash: line 1: /bad: Permission denied
>           1
> 

That works too, and is cheaper!  Thanks for pointing to that workaround!

So, better version:

From 38c4a7e2fcfe17a27bd16744f12d53e0968d1e52 Mon Sep 17 00:00:00 2001
From: Peter Rosin <peda <at> lysator.liu.se>
Date: Tue, 10 Jan 2012 00:50:22 +0100
Subject: [PATCH] tap/awk: add workaround for bash 3.2 and earlier

Fixes automake bug#10465.

* lib/tap-driver.sh: Add workaround for bash 3.2 and earlier which has
problems with compound statements, failing to redirect and exit status,
as documented in the Autoconf manual.

The workaround was pointed out by Eric Blake.
---
 lib/tap-driver.sh |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/lib/tap-driver.sh b/lib/tap-driver.sh
index c011298..39de9c4 100755
--- a/lib/tap-driver.sh
+++ b/lib/tap-driver.sh
@@ -115,7 +115,9 @@ else
   init_colors=''
 fi
 
-{
+# :; is there to work around a bug in bash 3.2 (and earlier) which
+# does not always set $? properly on redirection failure.
+:;{
   (
     # Ignore common signals (in this subshell only!), to avoid potential
     # problems with Korn shells.  Some Korn shells are known to propagate
-- 
1.7.5.1

Message #29 received at 10465 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 10465 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#10465: MSYS read-only file trouble
Date: Tue, 10 Jan 2012 09:48:33 +0100

Hi Eric, Peter, and thanks to both for the super-quick diagnosis and fix.

On 01/10/2012 12:52 AM, Peter Rosin wrote:
> Eric Blake skrev 2012-01-10 00:34:
>> On 01/09/2012 03:42 PM, Peter Rosin wrote:
>>> FWIW, this "fixes" it, but I don't actually know why a subshell would
>>> make a difference?
>>>
>>> $ sh --version
>>> GNU bash, version 3.1.17(1)-release (i686-pc-msys)
>>
>>>  
>>> -{
>>> +(
>>>    (
>>>      # Ignore common signals (in this subshell only!), to avoid potential
>>>      # problems with Korn shells.  Some Korn shells are known to propagate
>>> @@ -634,7 +634,7 @@ exit 0
>>>  '
>>>  
>>>  # TODO: document that we consume the file descriptor 3 :-(
>>> -} 3>"$log_file"
>>> +) 3>"$log_file"
>>
>> Ah - the classic bash bug documented in the autoconf manual:
>>
>> https://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Builtins
>>
>> Bash 3.2 (and earlier versions) sometimes does not properly set ‘$?’
>> when failing to write redirected output of a compound command. This
>> problem is most commonly observed with ‘{...}’; it does not occur with
>> ‘(...)’. For example:
>>
>>           $ bash -c '{ echo foo; } >/bad; echo $?'
>>           bash: line 1: /bad: Permission denied
>>           0
>>           $ bash -c 'while :; do echo; done >/bad; echo $?'
>>           bash: line 1: /bad: Permission denied
>>           0
>>
>> To work around the bug, prepend ‘:;’:
>>
>>           $ bash -c ':;{ echo foo; } >/bad; echo $?'
>>           bash: line 1: /bad: Permission denied
>>           1
>>
> 
> That works too, and is cheaper!  Thanks for pointing to that workaround!
> 
> So, better version:
>
The patch is good, but I have a couple of nits below.  Addressing them is
not a requirement for an ACK, though (even if I'd prefer to have them
addressed obviously).  Feel free to push when you are ready.

Thanks!

> From 38c4a7e2fcfe17a27bd16744f12d53e0968d1e52 Mon Sep 17 00:00:00 2001
> From: Peter Rosin <peda <at> lysator.liu.se>
> Date: Tue, 10 Jan 2012 00:50:22 +0100
> Subject: [PATCH] tap/awk: add workaround for bash 3.2 and earlier
>
s/add workaround for/fix redirection issues with/ perhaps?

> Fixes automake bug#10465.
> 
> * lib/tap-driver.sh: Add workaround for bash 3.2 and earlier which has
> problems with compound statements, failing to redirect and exit status,
> as documented in the Autoconf manual.
>
What about stealing the wording of the autoconf manual, to make this entry
clearer?  Something like this:

  Add workaround for bash 3.2 and earlier, which sometimes does not
  properly set '$?' when failing to write redirected output of a compound
  command.  See the Autoconf manual for more details.

> The workaround was pointed out by Eric Blake.
> ---
>  lib/tap-driver.sh |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/lib/tap-driver.sh b/lib/tap-driver.sh
> index c011298..39de9c4 100755
> --- a/lib/tap-driver.sh
> +++ b/lib/tap-driver.sh
> @@ -115,7 +115,9 @@ else
>    init_colors=''
>  fi
>  
> -{
> +# :; is there to work around a bug in bash 3.2 (and earlier) which
> +# does not always set $? properly on redirection failure.
>
For the sake of completeness (and at cost of being repetitive), I'd add a
reference to the Autoconf manual here as well, as: "See the Autoconf manual
for more details."

> +:;{
>    (
>      # Ignore common signals (in this subshell only!), to avoid potential
>      # problems with Korn shells.  Some Korn shells are known to propagate
>

Regards,
  Stefano

Message #32 received at 10465 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 10465 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#10465: MSYS read-only file trouble
Date: Tue, 10 Jan 2012 10:07:36 +0100

Stefano Lattarini skrev 2012-01-10 09:48:
> Hi Eric, Peter, and thanks to both for the super-quick diagnosis and fix.
> 
> On 01/10/2012 12:52 AM, Peter Rosin wrote:
>> Eric Blake skrev 2012-01-10 00:34:
*snip*
>>> Ah - the classic bash bug documented in the autoconf manual:
>>>
*snip*
>>
>> That works too, and is cheaper!  Thanks for pointing to that workaround!
>>
>> So, better version:
>>
> The patch is good, but I have a couple of nits below.  Addressing them is
> not a requirement for an ACK, though (even if I'd prefer to have them
> addressed obviously).  Feel free to push when you are ready.

Ok, I have now pushed as below.

Cheers,
Peter


From 8525b870d5caa0a04858aa436ad6949ec277fc0c Mon Sep 17 00:00:00 2001
From: Peter Rosin <peda <at> lysator.liu.se>
Date: Tue, 10 Jan 2012 10:01:29 +0100
Subject: [PATCH] tap/awk: avoid redirection issues with bash 3.2 and earlier

Fixes automake bug#10465.

* lib/tap-driver.sh: Add workaround for bash 3.2 and earlier, which
sometimes does not properly set '$?' when failing to write redirected
output of a compound command.  See the Autoconf manual for more details.

The workaround was pointed out by Eric Blake.
---
 lib/tap-driver.sh |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/lib/tap-driver.sh b/lib/tap-driver.sh
index c011298..725e779 100755
--- a/lib/tap-driver.sh
+++ b/lib/tap-driver.sh
@@ -115,7 +115,10 @@ else
   init_colors=''
 fi
 
-{
+# :; is there to work around a bug in bash 3.2 (and earlier) which
+# does not always set '$?' properly on redirection failure.
+# See the Autoconf manual for more details.
+:;{
   (
     # Ignore common signals (in this subshell only!), to avoid potential
     # problems with Korn shells.  Some Korn shells are known to propagate
-- 
1.7.5.1

Message #35 received at 10465 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 10465 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#10465: MSYS read-only file trouble
Date: Fri, 13 Jan 2012 13:26:13 +0100

tags 10465 patch
close 10465
thanks

On 01/10/2012 10:07 AM, Peter Rosin wrote:
> Stefano Lattarini skrev 2012-01-10 09:48:
>> Hi Eric, Peter, and thanks to both for the super-quick diagnosis and fix.
>>
>> On 01/10/2012 12:52 AM, Peter Rosin wrote:
>>> Eric Blake skrev 2012-01-10 00:34:
> *snip*
>>>> Ah - the classic bash bug documented in the autoconf manual:
>>>>
> *snip*
>>>
>>> That works too, and is cheaper!  Thanks for pointing to that workaround!
>>>
>>> So, better version:
>>>
>> The patch is good, but I have a couple of nits below.  Addressing them is
>> not a requirement for an ACK, though (even if I'd prefer to have them
>> addressed obviously).  Feel free to push when you are ready.
> 
> Ok, I have now pushed.
> 
> Cheers,
> Peter
> 
Thanks.  I'm thus closing this bug.

Regards,
 Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.