Shift bash arguments from the right

Question

I have a script that users will prefix, rather than append, arguments to, i.e. they might call command C, command B C, command A B C, and so on.

I'd like to be able to simply shift over these arguments from the right, the same way you might shift them from the left with shift.

I'm imaginging a shift-right command that behaves like so:

echo "$@"    # A B C
shift-right
echo "$@"    # A B
shift-right
echo "$@"    # A
shift-right
echo "$@"    # 
echo "$#"    # 0

Is there a clean way to accomplish this? I know I can work around it, but a shift-like solution would be much nicer and simpler.

---

In response to the XY-problem comment, my specific use case is a command that takes either a port or a host and port, e.g. command 123 or command remotehost 123. I don't want users to have to specify these in reverse order (port then host).

It would be fairly clean to say something like (untested, obviously):

port=${@: -1}
shift-right
host=${1:-localhost}

Really though, I'm curious about the question in general, even if there's a better way to solve this specific example.

Here's one reasonably clean way to handle the two-argument case without shift-right, just for reference:

port=${@: -1}
host=${2:+$1}
host=${host:-localhost}

But hopefully you can appreciate how that becomes more cludgy as the number of arguments increases.

Answer 1

If the list of positional parameters is:

$ set -- 0wer 1wdfg 2erty 333 4ffff 5s5s5

Then this will print the arguments without the last:

$ echo "${@:1:$#-1}"
0wer 1wdfg 2erty 333 4ffff

Of course, the parameters could be set to that as well:

$ set -- "${@:1:$#-1}"
$ echo $@
0wer 1wdfg 2erty 333 4ffff

That works in bash version 2.0 or above.

For other simpler shells, you need a (somewhat tricky) loop to remove the last parameter:

unset b; for a; do set -- "$@" ${b+"$b"}; shift; b="$a"; done

Answer 2

You can simply check the number of arguments and handle them in reverse order, e.g. for the simple two argument case where the first argument is optional:

usage() {
  cat << EOF
Usage: $0 [host] port
EOF
}

[ "$#" -eq 0 ] && { usage; exit 1;}

if [ "$#" -gt 1 ]; then
  myhost="$1"
  shift
fi

myport="$1"

However you mention the idea of three arguments as well. It's not really a trivial matter to have three optional arguments that are determined by position—what if you want to specify the first and third but not the second? Such scenarios are nearly impossible to handle with positional parameters alone but very simple with correct use of getopts.

usage() {
  cat << EOF
usage: $0 [OPTIONS]

    -p    port number (required)
    -h    hostname (optional)
EOF
}

while getopts :p:h: opt; do
  case "$opt" in
    p)
      myport="$OPTARG"
      ;;
    h)
      myhost="$OPTARG"
      ;;
    :)
      printf %s\\n "Argument required for option -$OPTARG" >&2
      usage >&2
      exit 1
      ;;
    \?)
      printf %s\\n "Unknown option -$OPTARG" >&2
      usage >&2
      exit 1
      ;;
  esac
done
shift "$((OPTIND-1))"

if [ -z "$myport" ]; then
  printf %s\\n "You must supply a port" >&2
  usage >&2
  exit 1
fi

Answer 3

Coming back to my own question, today I would probably simply implement this with a separate array and check the number of passed arguments, something like:

# Just a demo of a command that "shifts right"
# Usage: url_builder [[[scheme] hostname] port] 
url_builder() {
  local parts=(http localhost 80) # defaults
  if (( $# == 3 )); then
    parts[0]=$1; shift
  fi
  if (( $# == 2 )); then
    parts[1]=$1; shift
  fi
  if (( $# == 1 )); then
    parts[2]=$1; shift
  fi
  printf '%s://%s:%s\n' "${parts[@]}"
}

Usage:

$ url_builder
http://localhost:80

$ url_builder 100
http://localhost:100

$ url_builder example.com 100
http://example.com:100

$ url_builder ftp example.com 100
ftp://example.com:100

Whether that's better than the set approach suggested by user79743 probably depends on the use-case, but for anything more than a couple of arguments I'd start to get skeptical of the pattern in the first place. Users would likely be somewhat surprised by a command with numerous positional arguments that are optional further to the left like this.