Re: command substitution when timing grouped commands fails

[Kerin Millar]

On Thu, 07 Sep 2023 05:50:49 -0700
hackerb9@member.fsf.org wrote:

> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security -Wall
> uname output: Linux abyssal 6.4.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
> 6.4.11-1 (2023-08-17) x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
> 
> Bash Version: 5.2
> Patch Level: 15
> Release Status: release
> 
> Description:
> 
>       Bash gives a syntax error when using the $(...) form of
>       command substitution and timing grouped commands.
> 
>       However, Bash works correctly when using the `...` form of
>       command substitution.
> 
> 
> Repeat-By:
> 
>       The 'time' built-in command can measure a group of commands
>       run in a subshell, for example:
> 
>           $ time (date; sleep 1)
>           Thu Sep  7 05:19:21 AM PDT 2023
> 
>           real    0m1.005s
>           user    0m0.003s
>           sys     0m0.001s
> 
>       Attempting to save the output of time to a variable fails when
>       using $(...) command substitution. For example,
> 
>           $ x=$( time ( date; sleep 1 ) 2>&1 )
>           -bash: syntax error near unexpected token `date'
> 
>       However, old versions of bash (~2016) used to work correctly.
>       And, indeed, even the current version of bash works if one
>       uses backticks for command substitution.
> 
>           $ x=` time ( date; sleep 1 ) 2>&1 `
>           $                                           # no error
> 
>       There should be no difference between $(...) and `...`.

This issue, which affects 5.2, was previously reported here:

https://lists.gnu.org/archive/html/bug-bash/2023-08/msg00124.html

It was fixed in the devel branch in the fashion described by:

https://lists.gnu.org/archive/html/bug-bash/2023-09/msg00013.html

The issue has not yet been addressed by any available 5.2 patchlevel. Should 
you wish to patch 5.2 yourself - as I did - apply the above-mentioned change 
while ignoring the addition of "case DOLBRACE:".

-- 
Kerin Millar