Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: Ilkka Virta Newsgroups: gnu.bash.bug Subject: Re: No word splitting for assignment-like expressions in compound assignment Date: Tue, 28 Jul 2020 23:14:48 +0300 Lines: 26 Approved: bug-bash@gnu.org Message-ID: References: <6614fa7668daf7f2b450e319a28b624c@ispras.ru> <58020735-2ddb-e1a4-a513-a09560876e87@case.edu> <071ced16-0537-133d-8c1b-f54fefac1e33@iki.fi> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1595967313 718 209.51.188.17 (28 Jul 2020 20:15:13 GMT) X-Complaints-To: action@cs.stanford.edu To: chet.ramey@case.edu, Alexey Izbyshev , bug-bash@gnu.org Envelope-to: bug-bash@gnu.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <58020735-2ddb-e1a4-a513-a09560876e87@case.edu> Content-Language: en-US X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; h=subject:to:references:from:message-id:date:mime-version:in-reply-to:content-type:content-transfer-encoding; s=smtp; bh=Me+TbsHrSZ25mGd/MUJyKWOTIJRe1RhcHzU9LXXi2Qw=; b=ssY98+auNAhAl/QGrXpOyJrPI4PjYNm8hrWVaWrjVegxVdKzNF0hD11Rxnvl9ZUPQ4IP6UfjQUuGBy3A59ZBCH/jDXVc853Lh//BnQeXOQiLSh16MK1TYbKV5Hy6ydKBTVwJa/Fhkj8s27t2KHHmUZopgsI67J0rzgyOxZDyvTUpEBUH3qY+Towh/HjvaNvygAF+oindwg0h58KHKRn02K7uoQ74i4zolzFVB8DY8Dy4Nis5c5G/GM/981F5SiY9jNyC3II4SJ+MzaBgWFwDuZsGXRJKNXq1+afMl/UoJUv3vomHQ8uBDkYF/9Xti53wIH+NtfT+CisAy91Hk4h5Fw== Received-SPF: neutral client-ip=157.24.2.213; envelope-from=itvirta@iki.fi; helo=smtp-in-1.cc.lut.fi X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/28 16:14:57 X-ACL-Warn: Detected OS = FreeBSD 8.x X-Spam_score_int: -31 X-Spam_score: -3.2 X-Spam_bar: --- X-Spam_report: (-3.2 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: <071ced16-0537-133d-8c1b-f54fefac1e33@iki.fi> X-Mailman-Original-References: <6614fa7668daf7f2b450e319a28b624c@ispras.ru> <58020735-2ddb-e1a4-a513-a09560876e87@case.edu> Xref: csiph.com gnu.bash.bug:16640 On 28.7. 17:22, Chet Ramey wrote: > On 7/23/20 8:11 PM, Alexey Izbyshev wrote: >> $ Z='a b' >> $ A=(X=$Z) >> $ declare -p A >> declare -a A=([0]="X=a b") > It's an assignment statement in a context where assignment statements are > accepted (which is what makes it different from `echo X=$Z', for instance), > but the lack of a subscript on the lhs makes it a special case. I'll take a > look at the semantics here. This is also a bit curious: $ b=( [123]={a,b,c}x ) $ declare -p b declare -a b=([0]="[123]=ax" [1]="[123]=bx" [2]="[123]=cx") It does seem to have a subscript on the LHS, but it didn't work as one. To be in line with a plain scalar assignment, the braces should probably not be expanded here. -- Ilkka Virta / itvirta@iki.fi