Re: test '-v' - associative vs. normal array discrepancy - a bug ?

[konsolebox]

On Thu, Nov 20, 2014 at 4:47 AM, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> On Wed, Nov 19, 2014 at 02:41:13PM -0600, Eduardo A. Bustamante López wrote:
> > People, are we forgetting that this is supposed to work in a function, by
> > passing the name of a variable?
>
> Passing the name of a variable has NEVER worked in ANY function for ANY
> purpose in bash.

I hope you're actually not generalizing but you seriously have to reconsider
that.  This is just one:
https://sourceforge.net/p/playshell/code/ci/master/tree/source/filter.sh

> It only works in ksh93, which has proper namerefs.
> Every time you try to do it in bash, you introduce a security hole, or
> you ride the eval bus to hell.

"eval" is not synonymous to security holes.  There are many ways to sanitize it
(if necessarily needed).  Namerefs (declare -n in 4.3) and indirect variable
references for example can avoid referencing invalid variable names simply by
checking them with a pattern.

> This is precisely why I tell people not to try to write "libraries" of
> reusable code in bash.  You just can't do it.  It's pointless to try.

Sorry but it's not.  Or at least most of the time it's not always.

On Thu, Nov 20, 2014 at 5:14 AM, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> Honestly, I believe a script writer should know, in every situation,
> whether a variable is an array or an associative array or a regular
> variable.
>
> This is because a script writer does not write libraries of code that
> accept unknown variable name references from other people's scripts.
>
> This is because you DO NOT WRITE LIBRARIES IN BASH.  You can't.  This
> issue is just one of so very many pitfalls.  It's an intractable problem.

Granting that it's always the library writer that should care about how the
functions should be called.  The scripter also has the responsibility of making
sure that the type of argument the script is passing to the function is
correct.  Obviously strict typing is not possible in scripts but scripts on
the other hand can always be read in source form - unless they're purposely
scrambled.  Not to mention functions can also be well-documented.

If the caller somewhat produces a dynamic variable with a dynamic type or
dynamic name (like in associative-array-function-like hacks), it's still the
responsibility of the caller's scripter to make sure that the variable is sane
- even if the other side can also make checks on its own - unless the shared
function really has the implied function to check if the variables are valid.

And if it's about typos they're common.  They happen even when passing a name
reference or not and I don't see any difference in risk with respect to those
mistakes so I don't think there's an arguable difference considering them.

> The only way to
> get information out of one is to use the file system, or an open file
> descriptor, or an outer-scope (possibly global) variable.  If you go
> with a variable, the caller AND the function both have to agree on its
> name, because there's no way to pass that name TO the function.  It has
> to be hard-coded INSIDE the function.

This is correct.  I see those variables as shared and volatile.  It means that
the scripter should always consider that values of those variables may be
changed or lost when calling other functions.  It's not difficult to use those
especially if they're common and easy to remember like __, __A0, __I0, etc.


Cheers,
konsolebox