The only thing left here is that we can't have error control like when we
are to create generally shared library scripts e.g.:
function lib_something {
declare -n VAR=$1 &>/devnull || { # error message is not suppressed
: can_t go here if referred variable's name is invalid
return 1 # or do other things like proper error messaging
}
VAR["XYZ.1324"]="Some Value." &>/dev/null || { # error message is not
suppressed
: can_t go here if referred variable is not of associative array
type
return 1 # or do other things like proper error messaging
}
}
We might think that this may not be needed for hard codes but what about
soft / large codes where it needs tracing? Also on large codes where it
runs in loops. And some do just prefer easier error logging / tracing:
http://sourceforge.net/p/playshell/code/ci/377ccc3307bdb617ecdc4643acbde5329001e0b3/tree/source/assume.sh
http://sourceforge.net/p/playshell/code/ci/377ccc3307bdb617ecdc4643acbde5329001e0b3/tree/source/log.sh
This we could do if we have a builtin-level function.
On Thu, Apr 4, 2013 at 8:51 PM, konsolebox <konsole...@gmail.com> wrote:
> Another "feature" of this kind of construct is that you can put the name
>> of the variable-to-be-assigned into another variable:
>>
>> ptr=some_variable
>> setvalue "$ptr" "$foo"
>>
>> Which may be a good thing or a bad thing, but either way it's definitely
>> a thing that someone will (ab)use if it's available.
>>
>
> Well I did considered that noting that many people already tend to use the
> eval hack just to assign values to variables carried inside another
> variable most likely through passing of functions..
>
>
>> That said, I don't think bash needs this. Bash 4.3 is going to have
>> "namerefs" (declare -n) to allow passing arguments by reference to a
>> function.
>>
>
> I should have seen this sooner (have bash-devel but didn't check new
> features). I think it would be enough for the need.
>
> Thanks for telling me. Can't wait to use the feature soon. That would
> simplify many parts of my codes.
>
>
>
