Re: bin/54292: sh local variable assignment broken

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/54292; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/54292: sh local variable assignment broken
Date: Thu, 13 Jun 2019 08:13:47 +0700

     Date:        Wed, 12 Jun 2019 21:10:01 +0000 (UTC)
     From:        christos%netbsd.org@localhost
     Message-ID:  <20190612211001.249F57A1DA%mollari.NetBSD.org@localhost>
 
 
   | f() {
   | local x=$(echo 1 2 3)
 
 That's not broken, it is incorrect usage.
 
   | [3:44pm] 376>bash
   | bash-5.0$ . f.sh
   | bash-5.0$ f
   | 1 2 3
   | 1 2 3
 
 Bash parses "local" commands, and many others, as if they were syntax.
 Hence, it uses different rules for the local command than it would for
 any other.
 
 Try
 	dd if=$(echo 1 2 3) ...
 
 and see what happens in bash and sh.
 
 In sh (and in any sane, simple, shell) when presented with a command
 the shell expands the words that are the args (including the command
 name) which includes command substuitution, and later field splitting.
 
 In the example you have that results in
 
 	local x=1 2 3
 
 (4 words) at which point the "local" comand is recognised, and executed,
 and attempts to make sense of that nonsense.   When it can't, you get
 an error.
 
 In bash, the parser sees "local" (which is an alias, internally, for
 typedef, or declare, or something) and switches into a different parsing
 mode, where args that look like var assigns are parsed the same way a
 var assign preceding the command would be.
 
 I really do not believe we want that amount of complexity.
 
 kre