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

[Greg Wooledge]

On Wed, Nov 19, 2014 at 09:59:38PM +0100, Piotr Grzybowski wrote:
> On Wed, Nov 19, 2014 at 9:56 PM, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> >
> > That would break existing scripts.  $#a already means "argc followed by
> > the letter a".
> >
> > If you meant ${#a}, that would *still* break existing scripts, because
> > ${#a} when a is an array currently means "the length of a[0]".
> 
>  yes, right of course. but dont you think that there should be
> something that returns length of an object, in the above sense?

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.

You can't get the length of an "object", as you call it.  You can't get
its value.  You can't assign to it.  You can't even determine WHAT IT IS.
Nothing works correctly!

You know what else you can't do in bash?  You can't return a value from
a function.  Mathematically speaking, bash has no functions.  It just
has recursive procedure calls with local variables.  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.

So no, I do not agree with you.  Every variable in your script should be
YOURS, and you should know what it is, because you put it there yourself.