Is there a return keyword in bash?

Question

In the code below I need a return keyword in the first if statement. I need to exit the function after the echo.b

push() {
  a=$1
  b=$2
  if [ $# -eq 0 ]
  then
     echo "Enter git shortname for first argument"
  fi

  if [ $# -eq 1 ]
  then
      b=$(timestamp)
  fi
  git add -A .
  git commit -m $b
  git push $a
  echo "push() completed."
}

Research

Google pulls up SO article

score 2 · Answer 1 · answered Dec 06 '15 at 14:24

BASH does have return but you may not need it in your function. You can use:

push() {
  a="${1?Enter git shortname for first argument}"

  [[ $# -eq 1 ]] && b=$(timestamp)
  b=$2

  git add -A .
  git commit -m $b
  git push $a
  echo "push() completed."
}

a="${1?Enter git shortname for first argument}" will automatically return from function with given error message if you don't pass any argument to it.

score 1 · Answer 2 · answered Dec 06 '15 at 14:20

1

Rewrite it such that it always exits at the bottom. Use nested if constructs so yo don't have to bail out in the middle.

answered Dec 06 '15 at 14:20

nicomp

4,344
4
27
60

an else statement is one way to do this – Jeff Clayton Dec 06 '15 at 14:21

score 1 · Answer 3 · answered Dec 06 '15 at 14:26

What's wrong with bash's return statement?

push() {
  a=$1
  b=$2
  if [ $# -eq 0 ]
  then
     echo "Enter git shortname for first argument"
     return
  fi

  if [ $# -eq 1 ]
  then
      b=$(timestamp)
  fi
  git add -A .
  git commit -m $b
  git push $a
  echo "push() completed."
}

score 1 · Accepted Answer · edited Jun 20 '20 at 09:12

push() {
  local a="$1" b="$2" #don't overwrite global variables
  [ "$#" -eq 0 ] && { 
    1>&2 echo "Enter git shortname for first argument" #stderr
    return 64 #EX_USAGE=64
  }
  : "${b:=`timestamp`}" #default value
  git add -A .
  git commit -m "$b"  #always quote variables, unless you have a good reason not to
  git push "$a"
  1>&2 echo "push() completed."
}

The above should run in dash as well as bash, if case you want to make use of the faster startup time.

Why quote?

If you don't quote, variables will get split on characters present in $IFS, which by default is the space, the newline, and the tab character. Also, asterisks within the contents of unquoted variables are glob-expanded. Usually, you want neither the splitting nor the glob expansion, and you can unsubscribe from this behavior by double quoting your variable.

I think it's a good practice to quote by default, and comment the cases when you don't quote because you really want the splitting or the globbing there.

(Bash doesn't split or glob-expand in assignments so local a=$1 is safe in bash, however other shells (most prominently dash) do. a="$1" is ultra-safe, consistent with how variables behave elsewhere, and quite portable among shells.)

I added the `local` as I'v heard about global pollution in JS before it had strict mode ... but why should I quote variables. What does that do ? — cade galt, Dec 06 '15 at 14:42
@cadegalt Thanks for accepting the answer. I've added an explanation on why quoting is a good practice. — Petr Skocik, Dec 06 '15 at 14:59

Is there a return keyword in bash?

4 Answers4

Why quote?