inconsistent handling of closing brace inside no-fork command substitution

[Oğuz]

See:

$ ${ case } in }) echo uname; esac }
Linux
$ ${ case }x in }x) echo uname; esac }
bash: command substitution: line 25: syntax error near unexpected token `x'
bash: command substitution: line 25: `}x)'
$ ${ case }x in \}x) echo uname; esac }
Linux
$

I don't think this should be a syntax error because the closing brace
is not in a place it can terminate the command substitution.

Oğuz

Re: bash encountered a coredump issue with stepping on memory

[Ángel]

On 2023-12-06 at 07:20 -0500, Greg Wooledge wrote:
> On Wed, Dec 06, 2023 at 05:28:19PM +0800, wang yuhang via Bug reports for the 
> GNU Bourne Again SHell wrote:
> > When the for loop reaches env, the values of each env are: 
> >  
> [...]
> > (gdb) p env[16] 
> > $21 = 0x7ffce3c2e25a "DIRNAME_ALIAS" 
> > (gdb) p env[17] 
> > $22 = 0x7ffce3c2e279 "PID="
> 
> The missing '=' in DIRNAME_ALIAS appears to be noteworthy.
> 
> I could imagine a library function scanning through these strings, and
> for each one, iterating from the start and looking for '='.  In the
> case of DIRNAME_ALIAS, it never finds one, so it marches off past the
> edge of the allocated memory chunk.
> 
> This is pure speculation, of course, until someone actually tests it.
> 

Good point, but...

bash skips such variables, and they are not passed to the child
environment:

variables.c:382
+  /* If there are weird things in the environment, like `=xxx' or a
+string without an `=', just skip them. */
+  if (char_index == 0)
+continue;

which have been there at least since... 1997 (bash 2.01)


So there's no need to use any arena by glibc. That entry will be
skipped...


I don't see how this may end up in such situation (assuming bash itself
is not modified, and there are not weird libraries or modules enabled)

Re: inconsistent handling of closing brace inside no-fork command substitution

[Chet Ramey]

On 1/3/24 8:41 AM, Oğuz wrote:

See:

 $ ${ case } in }) echo uname; esac }
 Linux
 $ ${ case }x in }x) echo uname; esac }
 bash: command substitution: line 25: syntax error near unexpected token `x'
 bash: command substitution: line 25: `}x)'
 $ ${ case }x in \}x) echo uname; esac }
 Linux
 $

I don't think this should be a syntax error because the closing brace
is not in a place it can terminate the command substitution.


I agree. It looks like a problem with reconsituting the text of the command
substitution from the parse tree. I'll fix it for the next devel branch
push.

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: inconsistent handling of closing brace inside no-fork command substitution

[Martin Schulte]

Hello Oğuz!

> See:
> 
> $ ${ case } in }) echo uname; esac }
> Linux
> $ ${ case }x in }x) echo uname; esac }
> bash: command substitution: line 25: syntax error near unexpected token 
> `x'
> bash: command substitution: line 25: `}x)'
> $ ${ case }x in \}x) echo uname; esac }
> Linux

I couldn't reproduce this with neither 5.1.4 nor 5.2.15 - in both cases

${ case } in }) echo uname; esac }

results in

bash: syntax error near unexpected token `)'

Any help appreciated!

Thanks,

Martin

Re: inconsistent handling of closing brace inside no-fork command substitution

[Kerin Millar]

On Wed, 3 Jan 2024 22:36:34 +0100
Martin Schulte  wrote:

> Hello Oğuz!
> 
> > See:
> > 
> > $ ${ case } in }) echo uname; esac }
> > Linux
> > $ ${ case }x in }x) echo uname; esac }
> > bash: command substitution: line 25: syntax error near unexpected token 
> > `x'
> > bash: command substitution: line 25: `}x)'
> > $ ${ case }x in \}x) echo uname; esac }
> > Linux
> 
> I couldn't reproduce this with neither 5.1.4 nor 5.2.15 - in both cases

Neither of those versions support the non-forking command substitution syntax. 
You would need to build bash from the devel branch to reproduce it.

-- 
Kerin Millar