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

[Piotr Grzybowski]

 Greg, I swear to you, to anyone, this was not about writing libraries
in bash. I would never dare to write to you about reusable code.
 From the code perspective, the information about what kind of object
the identifier points to is present. And I use words "object" and
"identifier" not to make you mad ;-) but in an abstract way, to refer
to those "things". It is possible, to add either a builtin, or another
test argument, or some wicked $@a syntax to the dereference, that will
return number of elements if given "object" is currently an array or
number of "characters" if it currently is a "scalar".
 I too consider variables in scripts mine, and I would never try to
convince you to think otherwise. Love the spirit in your mails though
:)
 I do understand your point. Dont you understand the need to check in
a simple (I know, nothing works, nothing is simple ;-)) way that given
variable has value? no matter what it is?

cheers,
pg


On Wed, Nov 19, 2014 at 10:14 PM, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> 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:
>
> 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.