bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ${var@A}; hypothetical, related parameter transformations


From: Chet Ramey
Subject: Re: ${var@A}; hypothetical, related parameter transformations
Date: Thu, 21 Mar 2024 16:07:55 -0400
User-agent: Mozilla Thunderbird

On 3/20/24 3:05 PM, Zachary Santer wrote:

That expansion will produce a declare command if the variable has any
attributes, since it needs one to reproduce them. If the variable has a
value, but no attributes, you'll get an assignment  statement. If there
are no attributes and no value, you get nothing.

I hadn't even considered what to do with a variable that's declared,
but without attributes or value.

It really only matters when you use declare in a function, where the
resultant unset variable will be local when its assigned a value.


Let's say we've got two variables defined in a function like so:

func () {
   local -ir number=12
   local color='turquoise;
   local number_message
   generate_declare_command number number_message
   local color_message
   generate_declare_command color color_message
}

One of the changes I'm proposing here is to have ${color_message@A}
generate a declare command (`declare color_message'). It's an omission
that it wasn't there before, and a problem that the expansion was null.
Look at all the work you have to do to compensate.


it's more work
than if there were three separate parameter transformations. one each
to always generate a declare command; an assignment statement; and the
right hand side of a compound assignment statement or standard
assignment statement, depending on whether it's dealing with an
array/assoc or scalar.

I am not convinced that tripling the number of relevant variable
transformations makes the problem any simpler.

Consider that you're talking about changing ${var@A} to expand to a
declare command in the case that the variable has no attributes but is
local to the scope in which the expansion occurs. If you make that
change, then ${var@A} is somewhat unpredictable if you can't assume a
given bash release.

It's semantically wrong otherwise. A simple assignment statement would
create a global variable if the name weren't separately declared local.
That is "recreating the variable" by some definition, but if your goal
is to save a variable, unset it, and then restore it at the same scope,
it doesn't work. Dynamic scoping and using these expansions on a variable
that's declared as local in a previous scope gets messy, of course.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]