Path: csiph.com!goblin3!goblin.stu.neva.ru!panix!usenet.stanford.edu!not-for-mail From: Eli Schwartz Newsgroups: gnu.bash.bug Subject: Re: Syntax error in a Map/Hash initializer -- why isn't this supported? Date: Mon, 10 Aug 2020 18:44:02 -0400 Lines: 115 Approved: bug-bash@gnu.org Message-ID: References: NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TdfmH8XLHPEYRadhDYWdlXhD4gsyEvALq" X-Trace: usenet.stanford.edu 1597099464 12726 209.51.188.17 (10 Aug 2020 22:44:24 GMT) X-Complaints-To: action@cs.stanford.edu To: bug-bash@gnu.org Envelope-to: bug-bash@gnu.org X-Spam-BL-Results: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=archlinux.org; s=orion; t=1597099445; bh=6V2nZ1gDYJC86hUiZzmu16deKx5H/vuTFMdpVFiocR4=; h=Subject:To:References:From:Date:In-Reply-To; b=FeIJlV4ko/sykwFa+sTrtm7Fknz/DbOREADrkNbyJ8auqAwArcAXvNr4sIV8AXxeD 2EDs08mie3JNIAae3M65iYxkU+9Vwr57BAM2LiWNWKsS/7K/FMgbnOyYIPebm8QTbI /fzcYXBmUkTHh9/vg7lmikyUeUIX6R0Dn3nFws0IFWaOoLjkeVEAWy+BtZJc2nCDVs mwjuyzK0td7bWipk+7k+/PZ2ysyHj0NBvKgRO1TvTrZ+TgNeJHdv94EPsfXWPyh7a0 CW+AGNBDizonCKJAM5EXSOThuJCKwUampKe5m8z0o1s1EsiExxAHUYqpr3+sIG2FTi oM7S5/HSknSpqLqoFPeIWkYFBxLKpmLg7TrpQty8i4TBuKS775VeL8Wf/UkGnLUX0w yCwRcw3R0NNH/m6oyI6zn/8DtoICJj5Pt2070t1qJ7FTU2nWIRbkri+ehjJZ43tzu4 +sV027QzA83OWfQLxMOl9WogsD7dxlUzJiPG4Oo0eXu8A+lxrT+4D0ylMAXJrVuMgx JeudtRVhK8APIhC6Sf2FnXZBwh6LH/UOfy6ZoCF26Yd7gAq/6Hk0qXAL0OCvDK1O5Y cgF5LdgrB6M19uXBcExCDyOSlskKbA3KS/RyUMN7zOoOrWBjXhjS08I32DM4a1HuZk 6Qv60UMO0sKMUfFL93DQsWA4= X-Clacks-Overhead: GNU Terry Pratchett In-Reply-To: Received-SPF: pass client-ip=2a01:4f8:160:6087::1; envelope-from=eschwartz@archlinux.org; helo=orion.archlinux.org X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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: X-Mailman-Original-References: Xref: csiph.com gnu.bash.bug:16735 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TdfmH8XLHPEYRadhDYWdlXhD4gsyEvALq Content-Type: multipart/mixed; boundary="dXc85qM6KMpNzJF9F6iAor8JHgvg39Yg6" --dXc85qM6KMpNzJF9F6iAor8JHgvg39Yg6 Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: quoted-printable On 8/10/20 5:56 PM, L A Walsh wrote: > I wanted to use a map that looked like this: >=20 > declare -A switches=3D([num]=3D(one two three)), where '(one two three)= ' > is an associated list. Ideally, I could access it like other arrays: > for types in ${switches[num][@]}; do... > or > switches[num]=3D(one two three) #gives: > -bash: switches[num]: cannot assign list to array mem= ber > or > echo ${switches[num][0]} (=3D"one"). >=20 > I defaulted to going around it by making it a string, like: > switches[num]=3D"one|two|three" Correct, bash does not implement multidimensional arrays and its syntax error if you try anyway, implements the minimum heuristics necessary to convey that fact to you. > or > switches[num]=3D"(one two three)" but why? It seems obvious that bash > knows what I'm trying to do, so why not just do it? =2E. I'm sorry, did you just state your disapproval at bash for not implementing something, but having a useful error message in the process? Would you prefer "bash: error: an unknown error occurred"? > Some nested constructs seem to work: >> b=3D(1 2 3) >> a=3D(4 5 6) >> echo ${a[${b[1]}]} > 6 This is not a multidimensional array, obviously. It is two single-dimensional arrays, with a value lookup in one array that is then reused as the input key to perform another lookup in the second array. > but more often than not, they don't. Is there a reason to disallow suc= h? Today's session of "Linda Walsh is year-by-year terrible at asking questions". Instead of asking: "Can bash please implement multidimensional arrays as I think they're nifty and would like to use them." We are getting: "Bash supports multidimensional arrays because $HACK but it doesn't let me do them in X Y Z manner, is there a reason to arbitrarily forbid them or can this pointless restriction be lifted." This is a variant of http://catb.org/~esr/faqs/smart-questions.html#sympt= oms Please read the whole article, but pay particular attention to the section on "don't describe your problem in terms of the incorrect diagnostic theory you've already decided is the real problem". --=20 Eli Schwartz Arch Linux Bug Wrangler and Trusted User --dXc85qM6KMpNzJF9F6iAor8JHgvg39Yg6-- --TdfmH8XLHPEYRadhDYWdlXhD4gsyEvALq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvSewel70XCra9w4EhIGKaBmvSpsFAl8xzbIACgkQhIGKaBmv SpunGQ//TckseEYbSo7z0RVZ0P1Eo9fV0eCtd8W1npYAJ6fIn+nhxMzXhn/N4w7A +gkwJYr6KiMTvshqepvLL0s3qbOUDw356eZaamWEaf0b8iyG14AWZuN5Sgaujg3j 9zkLx/mkALXtQ7G0riuuHZFMuJ2LlXbTPPf4D8rbAtSwj+GqM8sYOXoCpGy57JGh 7kqnRw1ZjjAiOKSeJqLIqgBpbTamxXaTFOCLDsnlnmGve6GxK7hZF9RnihZqGa5I CLzQeSiMbx7po+NpN2Rm9SHuIr/7ZLEhCVQb83dT2OL/UKdhp1At9rn201IsbKLw eaLxQYvptctDAR18CktwV1p0jgCzX1Zvec5UIgSlhNdS8278bChgYjw+yDL+v/Rp DTC9KcSmZc/txMKO5zhO3o1GB7QOOpHxNdYRYw8SOc5AARd+rxSJp1+zQE1jkSa3 LFUgJG2VoU/cvo3OyY3s3PRpOQg9R8d44FvxpD3bBO09/UQZKuBRpDLTTie/XI8j ldSgnbsPjm4IIL0ffZbkFr18MbNzJ53hZDVcfRVynvlXbst+ofyb3ciG9JK46OHG Ax1PqgZ01eASLgWAfOyHKKu+KVxzZYGq9mBkP8o/2bfCYOIYjasqpM8TJKNieCUP u6WC7Hxz9fEQFbdqldXbxM5/XHLODLbhYmfGZ/204OTXclEwV5OJAjMEAQEKAB0W IQRgQRMEwJ02YoNA7v/OsWfvtXIr1gUCXzHNsgAKCRDOsWfvtXIr1l0FD/4pd06k Oh/XE6kxVTD8JiHLdEMGhSD3O9FGF3mn5iIf6x6ktp1Yt202PeFA7hRjvZoabJRS Xpye7yGEcpqZcQuaSF9549+7wuQ4MoV+uEVSZqpdwbXSF40M6kmRp5/AZLN8xcyQ Z8ltLl+gVFBqO1NoM7I6ZKnnB94kJ6t0E0iltvXRUNdDFiq1GhyfknXOuLz2ucZv K/6jDrPQ/EVdxrap38GB1sxPn2RfATd9ixwogBa0PB++a/zYOkjGrYM4o5w7/SAc mRlgkKCC0s+q4ckAermu5PMc8BkZfb3G3wD3WReyV9JH1+CkMFMjelLwMe68azkg w3m+PhxbrM7LL/xYeX6jO/jSN5hgueRR07olDIqNQZvg3SaMPDvwD3XS4wa989af OfZAlBTbK9WL0QnJ2+4XjGpzGjGJzcJiMeLvEp2kEJ7kxUtACw9eaMuxnM5oQNcB 7kZidZUfiY8trpJYRCgVfieJyqGnt23q7dBIPSGsISADQKnWDuZR+q3Ayhh4LLFU DVn6bqwfJKx+nQ/vy81b8NTBPhi0zhNAeJTv/z0TMo+urQ/Lw3ShGIZ86TwnQDG1 7UNTuD3IX/0pPbGX6eHvx95hdbreyiaK7Czu7GjEsmQ3wqt9287c5LGE99rPImNq 6NbgiF9Qqq0VxHSI/wn1gZ8nDF/IsHWNxFK5pg== =yRdQ -----END PGP SIGNATURE----- --TdfmH8XLHPEYRadhDYWdlXhD4gsyEvALq--