unshift

unshift

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]

Can we unshift the positional params?  I have a complex function that 
has shifts throughout and at one point there's a while loop:

shift
while [ "$1" ]; do
     if [ a ]; then b; c  fi
     if [ d ]; then e; f  fi
     if [ g ]; then h; i  fi
...
shift
done

... works fine, but I'm thinking to restructure it:

shift
while [ "$1" ]; do
     if [ a ]; then b; c; continue fi
     if [ d ]; then e; f; continue fi
     if [ g ]; then h; i; continue fi
...
shift
done

... because only one 'if' test will be relevant per loop and the 
remaining 'if' tests might even do some bad stuff.  The problem of 
course is that if I 'continue', the final 'shift' is missed.  I could do 
this:

# shift
while [ "$2" ]; do
     shift
     if [ a ]; then b; c; continue fi
     if [ d ]; then e; f; continue fi
     if [ g ]; then h; i; continue fi
...
# shift
done

... except that the leading (commented) 'shift' might happen in any 
number of places and changing them all would be troublesome.  It can be 
done of course, but I'm wondering if we have some way of  faking this:

shift
unshift
while [ "$1" ]; do
     shift
     if [ a ]; then b; c; continue fi
     if [ d ]; then e; f; continue fi
     if [ g ]; then h; i; continue fi
...
# shift
done

... it looks pointless above, however note that the leading 'shift' 
might in fact have happened in any one of several different places all 
of which would need to be reworked and it's fragile, so the 'unshift' 
would take care of it in one place, at least temporarily.  I know we 
don't have an official unshift, but can it be faked?  Of course there's 
also this:

     ...
     if [ a ]; then b; c; shift; continue fi
     ...

... but I'm wondering about a more succinct logic.  The quick and dirty 
'unshift' idea would solve a temporary problem very nicely.



[-- Attachment #2: Type: text/html, Size: 2880 bytes --]

Re: unshift

[Mark J. Reed]

[-- Attachment #1: Type: text/plain, Size: 2323 bytes --]

I haven't read your whole message yet, but to unshift a new value in front
of the positional params, all you have to do is this:


    set -- "$new" "$@"

And now $1 is "$new", $2 is whatever $1 used to be, and so on.

On Mon, Apr 1, 2024 at 9:52 AM Ray Andrews <rayandrews@eastlink.ca> wrote:

> Can we unshift the positional params?  I have a complex function that has
> shifts throughout and at one point there's a while loop:
>
> shift
> while [ "$1" ]; do
>     if [ a ]; then b; c  fi
>     if [ d ]; then e; f  fi
>     if [ g ]; then h; i  fi
> ...
> shift
> done
>
> ... works fine, but I'm thinking to restructure it:
>
> shift
> while [ "$1" ]; do
>     if [ a ]; then b; c; continue fi
>     if [ d ]; then e; f; continue fi
>     if [ g ]; then h; i; continue fi
> ...
> shift
> done
>
> ... because only one 'if' test will be relevant per loop and the remaining
> 'if' tests might even do some bad stuff.  The problem of course is that if
> I 'continue', the final 'shift' is missed.  I could do this:
>
> # shift
> while [ "$2" ]; do
>     shift
>     if [ a ]; then b; c; continue fi
>     if [ d ]; then e; f; continue fi
>     if [ g ]; then h; i; continue fi
> ...
> # shift
> done
>
> ... except that the leading (commented) 'shift' might happen in any number
> of places and changing them all would be troublesome.  It can be done of
> course, but I'm wondering if we have some way of  faking this:
>
> shift
> unshift
> while [ "$1" ]; do
>     shift
>     if [ a ]; then b; c; continue fi
>     if [ d ]; then e; f; continue fi
>     if [ g ]; then h; i; continue fi
> ...
> # shift
> done
>
> ... it looks pointless above, however note that the leading 'shift' might
> in fact have happened in any one of several different places all of which
> would need to be reworked and it's fragile, so the 'unshift' would take
> care of it in one place, at least temporarily.  I know we don't have an
> official unshift, but can it be faked?  Of course there's also this:
>
>     ...
>     if [ a ]; then b; c; shift; continue fi
>     ...
>
> ... but I'm wondering about a more succinct logic.  The quick and dirty
> 'unshift' idea would solve a temporary problem very nicely.
>
>
>
>

-- 
Mark J. Reed <markjreed@gmail.com>

[-- Attachment #2: Type: text/html, Size: 3926 bytes --]

Re: unshift

[Mark J. Reed]

[-- Attachment #1: Type: text/plain, Size: 194 bytes --]

... ah, I see, you want to just *undo* a shift. Well, AFAIK you can't do
that without manually saving the value that was in $1 before the shift
somewhere. Then you can use *set *to put it back.

[-- Attachment #2: Type: text/html, Size: 233 bytes --]

Re: unshift

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]


On 2024-04-01 06:54, Mark J. Reed wrote:
> I haven't read your whole message yet, but to unshift a new value in 
> front of the positional params, all you have to do is this:
>
>
>     set -- "$new" "$@"
>
> And now $1 is "$new", $2 is whatever $1 used to be, and so on.
>
... ah, I see, you want to just /undo/ a shift. Well, AFAIK you can't do 
that without manually saving the value that was in $1 before the shift 
somewhere. Then you can use *set *to put it back.

No problemo.  saving the previous '$1' is no issue, I can hardly expect 
it to be saved somewhere automatically, that would be a courtesy hardly 
of much use and not worth the bother.  The 'set' trick above is exactly 
perfect.

Thanks Mark.

[-- Attachment #2: Type: text/html, Size: 1412 bytes --]

Re: unshift

[Stephane Chazelas]

On 2024-04-01 14:54, Mark J. Reed wrote:
> I haven't read your whole message yet, but to unshift a new value in
> front of the positional params, all you have to do is this:
> 
>     set -- "$new" "$@"
> 
> And now $1 is "$new", $2 is whatever $1 used to be, and so on.
[...]

Or

argv[1,0]=$new

-- 
Stephane

Re: unshift

[Roman Perepelitsa]

On Mon, Apr 1, 2024 at 3:52 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Can we unshift the positional params?

That's an interesting challenge. A start:

  alias shift='emulate zsh -o typeset_silent -c "local -a _shift_a _shift_n"
               _shift_a+=("$@")
               _shift_n+=(-$#)
               shift'

  alias unshift='set -- "${(@)_shift_a[_shift_n[-1],-1]}"
                 _shift_a[_shift_n[-1],-1]=()
                 _shift_n[-1]=()'

unshift undoes the last call to `shift [ -p ] [ n ]`. I think (not
entirely sure) that it works with all options. Unfortunately, it does
not work for `shift [ -p ] [ n ] name ...`.

Roman.

Re: unshift

[Ray Andrews]

On 2024-04-01 07:38, Roman Perepelitsa wrote:
> On Mon, Apr 1, 2024 at 3:52 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> Can we unshift the positional params?
> That's an interesting challenge. A start:
Very interesting!  Could it be official?  Maybe not worth it's weight 
but ...
=================================
>
>    alias shift='emulate zsh -o typeset_silent -c "local -a _shift_a _shift_n"
>                 _shift_a+=("$@")
>                 _shift_n+=(-$#)
>                 shift'
>
>    alias unshift='set -- "${(@)_shift_a[_shift_n[-1],-1]}"
>                   _shift_a[_shift_n[-1],-1]=()
>                   _shift_n[-1]=()'
>
> unshift undoes the last call to `shift [ -p ] [ n ]`. I think (not
> entirely sure) that it works with all options. Unfortunately, it does
> not work for `shift [ -p ] [ n ] name ...`.
>
> Roman.
>

Re: unshift

[Roman Perepelitsa]

On Mon, Apr 1, 2024 at 6:11 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2024-04-01 07:38, Roman Perepelitsa wrote:
> >
> > That's an interesting challenge. A start:
>
> Very interesting!  Could it be official?  Maybe not worth it's weight
> but ...

It doesn't seem super useful to be honest. The semantics are odd, too.
What should this do?

    shift
    set blah
    unshift

Or this?

    foo=(42)
    shift foo
    integer foo
    unshift

There is no obvious answer, only options with pros and cons. The path
from a special-purpose hack to a general solution is long and arduous.

Roman.

Re: unshift

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]



On 2024-04-01 09:20, Roman Perepelitsa wrote:
> It doesn't seem super useful to be honest. The semantics are odd, too.
> What should this do?
>
>      shift
>      set blah
>      unshift
>
> Or this?
>
>      foo=(42)
>      shift foo
>      integer foo
>      unshift
>
> There is no obvious answer, only options with pros and cons. The path
> from a special-purpose hack to a general solution is long and arduous.
>
Sure, that's what I expected to here.  Come to that, I've never used 
shift for anything other than the positionals which is all I'm 
considering, but if there was an unshift it would obviously have to be 
globally useful not, as you say, some single use hack.  And since the 
hack is easy, your way or Stephane's, the functionality is already there.







[-- Attachment #2: Type: text/html, Size: 1257 bytes --]

Re: unshift

[Bart Schaefer]

On Mon, Apr 1, 2024 at 9:40 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> I've never used shift for anything other than the positionals which is all I'm considering, but if there was an unshift it would obviously have to be globally useful

"Undo the most recent shift" is not how "unshift" is defined in other
languages, e.g., perldoc: "shift" and "unshift" do the same thing to
the left end of an array that "pop" and "push" do to the right end.

If for some reason you don't want to declare a temporary for the old
value of $1, you can also do something like this:

set -- "${(@)argv[2,-1]}" "${argv[1]}"
...
set -- "${argv[-1]}" "${(@)argv[1,-2]}"

That is, rotate the positionals and then rotate them back again.  I
would actually usually do something like

set -- "${(@)argv[2,-1]}" -- "${argv[1]}"
while [[ $1 != -- ]]; do ...; shift; done

but what can be used as a such flag value is context-dependent.

Re: unshift

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]



On 2024-04-01 12:41, Bart Schaefer wrote:
> That is, rotate the positionals and then rotate them back again.  I
> would actually usually do something like
I was thinking the same thing.  Not that it's worth the trouble, but the 
memory holding the value is probably not released so it's still there in 
the same way a deleted file is still there, just not officially 
recognized -- until the space is used for something else.  I just assume 
the shift moves a pointer.  Nevermind, all the suggestions have been 
more than sufficient.

[-- Attachment #2: Type: text/html, Size: 1004 bytes --]

Re: unshift

[Bart Schaefer]

On Mon, Apr 1, 2024 at 6:52 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> shift
> while [ "$1" ]; do
>     if [ a ]; then b; c; continue fi
>     if [ d ]; then e; f; continue fi
>     if [ g ]; then h; i; continue fi
> ...
> shift
> done
>
> ... because only one 'if' test will be relevant per loop and the remaining 'if' tests might even do some bad stuff.  The problem of course is that if I 'continue', the final 'shift' is missed.

shift
while [ "$1" ]; do
  repeat 1 do
    if [ a ]; then b; c; break; fi
    if [ d ]; then e; f; break; fi
    if [ g ]; then h; i; break; fi
    ...
  done
  shift
done

Re: unshift

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]



On 2024-04-01 09:03, Bart Schaefer wrote:
> shift
> while [ "$1" ]; do
>    repeat 1 do
>      if [ a ]; then b; c; break; fi
>      if [ d ]; then e; f; break; fi
>      if [ g ]; then h; i; break; fi
>      ...
>    done
>    shift
> done
>
Ah!  So a 'break' quits the inner loop then hits the 'shift' which has 
the same effect as putting the shift at the top of the outer loop.  
That's very clever.  Never seen 'repeat' used in a real life way.  There 
are tools which aren't used often, but still very useful when needed.

[-- Attachment #2: Type: text/html, Size: 961 bytes --]

Re: unshift

[Dennis Eriksen]

Hi,

On Mon, Apr 01, 2024 at 06:52:00AM -0700, Ray Andrews wrote:
>shift
>while [ "$1" ]; do
>    if [ a ]; then b; c; continue fi
>    if [ d ]; then e; f; continue fi
>    if [ g ]; then h; i; continue fi
>...
>shift
>done
>
>... because only one 'if' test will be relevant per loop and the
>remaining 'if' tests might even do some bad stuff.  The problem of
>course is that if I 'continue', the final 'shift' is missed.

Why not just use 'elif'? :)

shift
while [ "$1" ]; do
     if   [ a ]; then b; c;
     elif [ d ]; then e; f;
     elif [ g ]; then h; i;
     fi
     shift
done

If 'a' matches, the rest of the conditional won't run.

You could even use 'case'

shift
while [ "$1" ]; do
     case $1 in
         a) b; c;;
         d) e; f;;
         g) h; i;;
     esac
     shift
done

The execution terminates on ';;'.

-- 
Dennis Eriksen

Re: unshift

[Ray Andrews]

On 2024-04-02 05:41, Dennis Eriksen wrote:
>
>
> Why not just use 'elif'? :)
>
> shift
> while [ "$1" ]; do
>     if   [ a ]; then b; c;
>     elif [ d ]; then e; f;
>     elif [ g ]; then h; i;
>     fi
>     shift
> done
>
> If 'a' matches, the rest of the conditional won't run.
>
Good idea but in my particular case there's a block of code half way 
down the loop that applies to everything below it.  I should have shown 
that in my original.  Or as I have it now:

while [ "$2" ]; do
     shift
     if [ a ]; then b; c; continue fi
     if [ d ]; then e; f; continue fi
     code-applies-to-all-below; more(of-the-same)
     if [ g ]; then h; i; continue fi
     if [ j ]; then k; l; continue fi
done

... so elif won't work.  Yeah,  I should have made that clear from the 
start, it's what narrows the field of possible solutions.




> You could even use 'case'
>
> shift
> while [ "$1" ]; do
>     case $1 in
>         a) b; c;;
>         d) e; f;;
>         g) h; i;;
>     esac
>     shift
> done
>
> The execution terminates on ';;'.
>

Re: unshift

[Roman Perepelitsa]

On Tue, Apr 2, 2024 at 4:03 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> while [ "$2" ]; do
>      shift
>      if [ a ]; then b; c; continue fi
>      if [ d ]; then e; f; continue fi
>      code-applies-to-all-below; more(of-the-same)
>      if [ g ]; then h; i; continue fi
>      if [ j ]; then k; l; continue fi
> done
>
> ... so elif won't work.

It'll work with one `else` in the mix.

Roman.

Re: unshift

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]



On 2024-04-02 12:59, Roman Perepelitsa wrote:
> On Tue, Apr 2, 2024 at 4:03 PM Ray Andrews<rayandrews@eastlink.ca>  wrote:
>> while [ "$2" ]; do
>>       shift
>>       if [ a ]; then b; c; continue fi
>>       if [ d ]; then e; f; continue fi
>>       code-applies-to-all-below; more(of-the-same)
>>       if [ g ]; then h; i; continue fi
>>       if [ j ]; then k; l; continue fi
>> done
>>
>> ... so elif won't work.
> It'll work with one `else` in the mix.
>
> Roman.
I'm happy with it as it is now, it seems clean.  I've always tended to 
be a good Protestant and do:

    ...
    shift
    ...
    ...
    while [ $1 ]
    ...


... get the shifting done ASAP, but the more I think about it the more I 
like:

    ...
    while [ $2 ]
         shift
    ...

... more Catholic ... do it when you need to do it.   The function is 
quite a bit simpler that way.  Cross bridges when I get to them.



[-- Attachment #2: Type: text/html, Size: 1801 bytes --]