Re: access exported var

[Peng Yu]

On 1/16/23, Britton Kerin <britton.kerin@gmail.com> wrote:
> On Mon, Jan 16, 2023 at 11:16 AM Peng Yu <pengyu.ut@gmail.com> wrote:
>>
>> On 1/16/23, Leonid Isaev <leonid.isaev@ifax.com> wrote:
>> > On Mon, Jan 16, 2023 at 12:07:25PM -0600, Peng Yu wrote:
>> >> Given arrays cannot be exported, is it better to export nothing or
>> >> export the first element?
>> >
>> > You asked a very philosophical (not in a good sense) question: if I
>> > know
>> > that
>> > an array "${a[@]}" can't be exported, and want to export its 1st
>> > element, I
>> > will do just that: export a variable "${a[0]}"...
>>
>> Then, you are then suggesting ${Z[0]} instead $Z for the first element
>> of the Z array, for the same logic.
>>
>> I'd rather have $Z as a shorthand notation of ${Z[0]} for the fewer
>> keystrokes. Bash is for command line interaction, every keystroke
>> counts. If you want verbosity, you can use java. It is notorious in
>> this aspect so that people literally have to use an IDE to deal with
>> the bloated code in java.
>
> I agree export and assign should behave the same way,
> but I'd also
> very much prefer both to be errors.

For backward compatibility, I doubt error on assign is something that
can be changed. However, if there is a switch to enable/disable such
error reporting, then it is acceptable. So the old code still can work
without changes, but new code may be programmed with error reporting
disabled or enabled.

>  The major barrier to array use
> in bash is that it's infrequently used enough

That is because bash was mostly not used as an extensible library.

> that most people never
> bother to figure out how it works given the other nearby alternatives.
> Strange silent behaviors make this issue worse.

I've used bash to make my own extensible library with thousands of
bash functions, so that arrays become quite frequently used. In this
case, it would be beneficial to have better support in arrays.

-- 
Regards,
Peng