On 9/27/2018 5:42 AM, Dennis Williamson wrote:
[include stdalias] #[include Types] #if type-checking include Types+line below lshift () { (($#)) || return 1 int nshift=1 if [[ $1 =~ ^[0-9]+$ ]]; then nshift=$1; shift;fi #if ! isArr $1; then echo >&2 "Need arrayname"; return 1; fi my ar=$1; shift my h="$ar[@]" ... "my" - What is this, Perl?
Um...it's a "std" alias! :-)... It gets included from a bash include file "stdalias.shh" the first time it is included. It's really more perl than "int" (or "array" or "map") that I use for other data types. I certainly find 'my' and 'int' easier to type and read than 'declare [-i]' or 'typeset [-i]'. FWIW, if I wanted it to be more perl-like, I'd at least use 'sub' before lshift (an alias for 'function') which is slightly more clear than 'name()', as the empty parens, at first glance, might indicate the function takes no parameters, vs. being a syntax element. The parens are slightly more concise, so I usually use them.
array_shift=2 arr=("${arr[@]:$array_shift}")
--- I don't think I was aware that slicing syntax worked with arrays. Certainly that's much more efficient (which was why I included my code, cuz I figured my request was valid, OR there had to be a tighter or better construct than what I'd thrown together
Done.
Much thanks! Your example certainly lessens the need for shift to handle other arrays, although it still would be a nice, simple and unambiguous syntax, though: "shift 2 arr" still looks simpler and clearer than slice syntax.