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


Groups > gnu.bash.bug > #14672

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

From Ilkka Virta <itvirta@iki.fi>
Newsgroups gnu.bash.bug
Subject Re: comment on RFE: 'shift'' [N] ARRAYNAME
Date 2018-09-27 18:47 +0300
Message-ID <mailman.1403.1538063267.1284.bug-bash@gnu.org> (permalink)
References <5BAAD017.4010806@tlinx.org> <20180927123551.j5attjixprhoxavx@eeg.ccf.org>

Show all headers | View raw


On 27.9. 15:35, Greg Wooledge wrote:
> Shift already takes one optional argument: the number of items to shift
> from the argv list.  Adding a second optional argument leads to a quagmire.
> Do you put the optional list name first, or do you put the optional number
> first?  If only one argument is given, is it a list name, or is it a number?
> 
> (OK, granted, in bash it is not permitted to create an array whose name
> is strictly digits, but still.)

Can you make an array whose name even starts with a digit?

With no overlap between array names and valid numbers,
shift [arrayname] [n]   would be unambiguous, as you said.

Though  shift [n [arrayname]]   would be even more backward-compatible 
since the new behaviour would always require two arguments, which is now 
an error.


Even so, deciding how to handle sparse arrays might an interesting 
issue, too.

If one wants a command that looks like the current shift, Dennis's 
obvious slice-assignment could be wrapped in a function. Doing it this 
way of course collapses the indices to consecutive numbers starting at zero.

  ashift() {
      typeset -n _arr_="$1";
      _arr_=("${_arr_[@]:${2-1}}");
  }
  somearray=(a b c d)
  ashift somearray 2


-- 
Ilkka Virta / itvirta@iki.fi

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


Thread

Re: comment on RFE: 'shift'' [N] ARRAYNAME Ilkka Virta <itvirta@iki.fi> - 2018-09-27 18:47 +0300

csiph-web