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

[Greg Wooledge]

On Thu, Feb 16, 2012 at 07:44:47AM -0600, Peng Yu wrote:
> I recall now that I have seen this before. I think that it is probably
> better to have some function like 'unshift' [...]

You can implement an unshift function for your scripts if you want.
Would you like help writing it?  No?  You just want to keep complaining
that Bash doesn't have every conceivable feature from every other
programming language you've ever worked with?

Well, you see, Bash is a SHELL.  It is a command interpreter designed
to give users a flexible interface to their operating system and their
files, with a little bit of ability to write scripts for automating simple
tasks.  It is not a high-level programming language with 13 terabytes of
bloated libraries or features that you need a PhD in mathematics to
understand how to use.  It is not INTENDED to be.

Shift is very simple to implement.  It mimics the natural argv[]
processing in C, where you just write "argv++;" to increase the pointer
so that it goes to the next argument in the vector.  There's no safe
way to go BACKWARDS doing this, because you might accidentally underflow
the vector, so you don't do that.  You just go forward until you hit NULL.
That's safe, and it's easy, and it's totally the NATURAL way to process
arguments, because you process arguments left to right, in one pass, and
then you stop.

Now, let's look at your proposed "unshift".  What would it do if you have
this array:

 a=([0]=foo [1]=bar [2]=baz [3]=quux)

Most likely it would iterate backwards through the indices, and copy each
element to the next-higher index:

  a[4]=${a[3]}
  a[3]=${a[2]}
  a[2]=${a[1]}
  a[1]=${a[0]}
  a[0]=$input

But what would it do if you had this array:

 b=([0]=look [13]=there [14]=is [15]=a [16]=gap)

Would it move all the indices up by 1?  Would it just move the first
element up by 1 and leave the others alone?  See, it's not so obvious.

The real problem here is that you are perceiving arrays as *lists*, but
they are not.  They are (potentially sparse) indexed arrays.  The only
array that cannot be sparse is @, and that isn't even a true array,
though it shares many of the syntactic operators.