Re: Should VAR[n]=val cmd export VAR?
Bart Schaefer <[email protected]> Sat, 11 Jul 2026 16:07:32 -0700
| Newsgroups | gmane.comp.shells.zsh.devel |
|---|---|
| Message-ID | <CAH+w=7aO3HZNB0zReqaDxhRbfk4hazP5nsgwQ6rRODh6WLK1jQ@mail.gmail.com> |
On Fri, Jul 10, 2026 at 8:37 PM Philippe Altherr <[email protected]> wrote: > > This discrepancy looks strange to me. I expected that "VAR[n]=val cmd" would export VAR. I find the lack of export even stranger given that "VAR[n]=val" exports VAR when ALL_EXPORT is enabled. > > Wdyt? I think the current behavior falls out because ... 1. You can't export arrays (neither simple nor associative). 2. You can't export individual array elements, and subscripting "looks like" an array element. 3. ALL_EXPORT is implemented in a completely separate part of the flow, that isn't paying attention to *how* the variable got its value. That is, conceptually ALL_EXPORT just causes the "is exported" flag to be set, the actual export isn't simultaneous with the assignment. > Could we change inline assignments to also export parameters with a subscript? The question to my thinking is whether "X=Y cmd" is defined as exporting an "object" X associated with its current value (which is what ALL_EXPORT definitely means), or defined as inserting the string "X=Y" into the environment of "cmd". If the latter, exporting VAR[n] is impossible, you can't export part of an object, an environment containing "VAR[n]=VAL" is not a valid construct.