Re: [Help-bash] opposite of 'shift'

[Dan Douglas]

On Thursday, February 16, 2012 09:35:28 AM Greg Wooledge wrote:
> On Thu, Feb 16, 2012 at 08:26:59AM -0600, Dan Douglas wrote:
> > You can't. nonlocal positional parameters are inacceessable.
> parameters.  (I gave two example input arrays.)  Sorry for the confusion.

Ah, misinterpreted.

But for arrays, it's almost worse! One of the few possible implementations... 
It's completely incomprehensible, won't work on sparse arrays, and can only 
return arrays directly to the scope of the caller (or global).

# usage: eval "$(unshift arrname arg1 arg2 ...)"

unshift() {
    set -- "$1"{,address@hidden,x{,address@hidden "$@"    # indirect parameter 
names
    local -a "$3"='("${@:6}" "${!2}")' "$1"='("${!4}")'
    declare -p "$1"
}

f() {
    local a=("$@")
    eval "$(unshift a 1st 2nd 3rd)"
    printf '<%s> ' "address@hidden"; echo
}

f a 'b c' d

... output: <1st> <2nd> <3rd> <a> <b c> <d>

The only other way I can think of is printf -v 'arr[i]' in a loop, which fixes 
the scope thing. "declare" has the nasty effect of forcing a NEW local, or 
global, even with +=. To make matters worse, declaration commands unset the 
variable name they're about to assign BEFORE expanding arithmetic variables 
and single-quoted expansions. This means copying the array to an intermediary 
local that's guaranteed to be globally unique (by incorporating the 
destination name into the intermediary name).

On second thought, printf -v is quite a lot better, but still yuck.

On Thursday, February 16, 2012 08:33:08 AM Eric Blake wrote:
> anything that is too complex to shell script using
> just POSIX features already deserves to be written in a full-featured
> language in the first place, rather than bloating the shell

To be fair, OP wasn't asking to implement an XML parser or a half dozen regex 
flavors.  This is basic operations on basic datastructures. If that causes 
excessive "bloat" (relative to the current "too big/slow") then somethings not 
right.

Frankly, it's difficult to deny the gap between the size of sysadmin tasks 
practical in POSIX sh vs other high-level langs. Extending the capabilities of 
the shell enough to fill the gap while disturbing the syntax as little as 
possible is far more realistic than e.g., switching over to Python for jobs 
involving moderately complex I/O on external processes for no other reason 
than a few array manipulations. Everybody knows one of the most painful parts 
of scripting is working with what few built-in types are available.

Granted, "X has Y, Bash doesn't" is a lame argument, and I can think of a few 
more important things to do than support this feature.
-- 
Dan Douglas

signature.asc
Description: This is a digitally signed message part.