3 ms·
Yes, in writing my bash parser/interpreter (see below) I explored the non-nested arrays and assoc arrays issue. I think it mainly has to do with the fact that
by chubot 10y ago
Yes, in writing my bash parser/interpreter (see below) I explored the non-nested arrays and assoc arrays issue.
I think it mainly has to do with the fact that bash has no references and garbage collection. When you create an array like [1, 2, [a, b]] in Python/Ruby/Perl, you are introducing the concept of references, as well introducing hte potential for reference cycles.
In contrast, an array in bash is just a value, and it took me awhile to figure out how to even copy it. None of these work:
a=('x y' z)
b=${a}
b=${a[*]}
b=${a[@]}
b="${a[*]}"
b="${a[@]}"
b=( ${a} )
b=( ${a[*]} )
b=( ${a[@]} )
b=( "${a}" )
b=( "${a[*]}" )
This works:
b=( "${a[@]}" )
In other words, it takes 11 characters to properly copy an array! This syntax is horrible.
- jstimpfle 10y agoWhat's more horrible about it is that the simpler sh constructs are somehow not respected in bash culture. In sh, each function has a local array, and you use that array with "$@". And typically you can get along with only that array. Not so bad. my_b() { somefunc foo "$@" bar }
- catuskoti 10y agoAgreed about the array syntax too. They missed the ball in bash about nested arrays, because freeing them is indeed a non-trivial problem. Bash can happily operate with just simplistic malloc() and free() calls. Nesting arrays breaks that simplicity. My personal opinion is that they should not have added such broken array implementation, but rather let the user load an external library to deal with it, through an external tool like ctypes.sh: https://github.com/taviso/ctypes.sh/wiki https://github.com/taviso/ctypes.sh/wiki. Not all programs need nested arrays. Adding support for them, comes with a price tag attached. By keeping it external, the user only pays for what he really uses.