Bug 11721

Summary:	ash subshell vs. arithmetic bracket parsing issue
Product:	Busybox	Reporter:	Chris Renshaw <osm0sis>
Component:	Standard Compliance	Assignee:	unassigned
Status:	RESOLVED WONTFIX
Severity:	normal	CC:	busybox-cvs
Priority:	P5
Version:	1.30.x
Target Milestone:	---
Hardware:	All
OS:	All
Host:		Target:
Build:

Description Chris Renshaw 2019-03-10 20:19:02 UTC

Nesting brackets as follows in ash does not follow the standard in bash, mksh or even busybox's hush:

this=$((blah || blarg) 2>/dev/null);

To better test remove the redirect for the following command (noting the space to preserve the nesting):

this=$((blah || blarg) );

On any shell I've tested but ash this correctly gives error 127 for the commands grouped not being able to run. ash instead incorrectly interprets it as an arithmetic statement, presumably due to the $((, despite it not closing with )), and will hang awaiting )) or in a script will error out it missing the )).

Comment 1 Denys Vlasenko 2019-06-09 15:17:09 UTC

I'm actually surprised bash looks that far into the input to determine what $(( means. hush does not do that: (unless math support is disabled,) it will interpret $(( as the start of arithmetic substitution.

Comment 2 Chris Renshaw 2019-06-10 00:46:47 UTC

Hmm, odd, you're right, I seem to have been mistaken that hush treats it differently from ash. bash and mksh however definitely do seem to be able to interpret it correctly.

Comment 3 Denys Vlasenko 2019-06-11 13:16:22 UTC

It's not obvious what "correctly" is.
For example, in C syntax, the longest sequence of chars which forms a valid token is taken as next token - no lookahead. In this case, this rule would see "$((" as next token.