makepkg: remove bash4 style output redirection

06-20-2010, 04:15 PM

On Sun, Jun 20, 2010 at 11:21, Allan McRae <allan@archlinux.org> wrote:
> convert bash-4 "&>" style redirection to "2>&1" to maintain
> compatibility with bash-3.2
>
> Signed-off-by: Allan McRae <allan@archlinux.org>
> ---

&> style redirection is supported by bash 3, as far as I know. Maybe
even bash 2, but I don't have that on hand to test. Was this added in
bash 3.3, or does 3.2 support it?

06-20-2010, 05:25 PM

On Sun, Jun 20, 2010 at 12:19 PM, Cedric Staniewski <cedric@gmx.ca> wrote:
> I don't have access to a bash3 anymore, but you're right. It's mentioned
> in bash-3.2.48's man page. Maybe there was a bug that prevented it from
> working correctly or [1] is just wrong.
>
>> * *&>filename
>> * * * # Redirect both stdout and stderr to file "filename."
>> * * * # This operator is now functional, as of Bash 4, final release.
>
>
> [1] http://tldp.org/LDP/abs/html/io-redirection.html
>

No, the bash 4 only construct is appending:
$ foo &>> bar

Redirs of the form &>, which a *single* >, are fully functional in bash 3.2

Andres P

06-21-2010, 01:47 AM

On Sun, Jun 20, 2010 at 8:38 PM, Allan McRae <allan@archlinux.org> wrote:
> On 21/06/10 03:25, Andres P wrote:
>>
>> On Sun, Jun 20, 2010 at 12:19 PM, Cedric Staniewski<cedric@gmx.ca> *wrote:
>>>
>>> I don't have access to a bash3 anymore, but you're right. It's mentioned
>>> in bash-3.2.48's man page. Maybe there was a bug that prevented it from
>>> working correctly or [1] is just wrong.
>>>
>>>> * *&>filename
>>>> * * * # Redirect both stdout and stderr to file "filename."
>>>> * * * # This operator is now functional, as of Bash 4, final release.
>>>
>>>
>>> [1] http://tldp.org/LDP/abs/html/io-redirection.html
>>>
>>
>> No, the bash 4 only construct is appending:
>> $ foo&>> *bar
>>
>> Redirs of the form&>, which a *single*>, are fully functional in bash 3.2
>>
>
> I have tested and it looks like this has always worked in bash. *Testing
> v3.0 on an old FC3 install showed no issues. *I can only assume there must
> be some bug in it for the comment in [1] to be made, but until we strike it,
> I think there is no need to patch these out.

OK, we'll scratch this patch then.