Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #14674

Re: comment on RFE: 'shift'' [N] ARRAYNAME

Show all headers | View raw

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.

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

Re: comment on RFE: 'shift'' [N] ARRAYNAME L A Walsh <bash@tlinx.org> - 2018-09-27 10:45 -0700

csiph-web