[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bash-bug
Subject:    Re: command substitution when timing grouped commands fails
From:       Kerin Millar <kfm () plushkava ! net>
Date:       2023-09-07 15:06:10
Message-ID: 20230907160610.8c5c4ebcb9f120a4081d12a4 () plushkava ! net
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]