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 <wool...@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 <wool...@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.
