[pacman-dev] [PATCH] makepkg: more bash-3.2 compatibility

[Allan McRae]

On 05/02/11 12:15, Dave Reisner wrote:
> On Sat, Feb 05, 2011 at 11:54:04AM +1000, Allan McRae wrote:
>> On 05/02/11 11:02, Dave Reisner wrote:
>>> On Sat, Feb 05, 2011 at 10:26:20AM +1000, Allan McRae wrote:
>>>> Adding the "|| true" to the subshell prevents bash-3.2 setting off the
>>>> error_trap but requires changing the if statement.
>>>>
>>>> Signed-off-by: Allan McRae<allan at archlinux.org>
>>>> ---
>>>>   scripts/makepkg.sh.in |    4 ++--
>>>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in
>>>> index 13415fb..001178a 100644
>>>> --- a/scripts/makepkg.sh.in
>>>> +++ b/scripts/makepkg.sh.in
>>>> @@ -507,8 +507,8 @@ download_sources() {
>>>>
>>>>   	local netfile
>>>>   	for netfile in "${source[@]}"; do
>>>> -		local file
>>>> -		if file=$(get_filepath "$netfile"); then
>>>> +		local file=$(get_filepath "$netfile" || true)
>>>> +		if [[ -n "$file" ]]; then
>>>>   			msg2 "$(gettext "Found %s")" "${file##*/}"
>>>>   			ln -sf "$file" "$srcdir/"
>>>>   			continue
>>>> --
>>>> 1.7.4
>>>>
>>>>
>>>
>>> I don't agree with this. The local keyword will actually mask the return
>>> value of the command substitution and you will always return without
>>> error. It's therefore sufficient to do:
>>>
>>>    local file=$(get_filepath "$netfile")
>>>    if [[ -n $file ]]; then
>>>     ...
>>>
>>> This also applies to any variable defined via the 'declare' builtin.
>>>
>>
>> Not in bash-3.2...
>>
>>
>> allan at mugen /var/abs/local/tmp
>>> makepkg -gc
>> ==>  Retrieving Sources...
>> ==>  ERROR: An unknown error has occurred. Exiting...
>>    ->  Downloading abs-2.4.2.tar.gz...
>> --2011-02-05 11:53:38--  ftp://ftp.archlinux.org/other/abs/abs-2.4.2.tar.gz
>>
>>
>> Allan
>>
>
> Something else is foul, then.
>
> -----8<------------------
> #!/bin/bash3 -e
>
> badfun() {
>    local foo=$(asdlkfjasdf)
>    echo $?
> }
>
> badfunc
> ------------------>8-----
>
> prints the error and echos 0.
>
> d

It may well be a bug in bash-3.2.  Either way, this "fixes" the issue. 
I'm open to suggestions for a better fix.

Allan