getreturn() { | |
command -v "$*" >/dev/null 2>&1 || { | |
echo >&2 | |
return 127; | |
} | |
typeset cmnd="$*" | |
typeset ret_code | |
eval $cmnd >/dev/null 2>&1 | |
ret_code=$? | |
return $ret_code |
#!/bin/bash | |
ask_yn() { | |
# Adapted from http://djm.me/ask by Jeff-Russ | |
if [ "${2:-}" = "Y" ]; then prompt="Y/n"; default=Y | |
elif [ "${2:-}" = "N" ]; then prompt="y/N"; default=N | |
else prompt="y/n"; default= | |
fi | |
while true; do # keeps repeating the question until it gets a valid answer. |
Paths can get somewhat muddled up when you execute a Bash script with dependencies. Each script, when executed, is executed at a certain location as demonstrated by echoing pwd
from the script. This is the directory assumed if ever you try to source
(aka .
) from that script.
This location is subject to change as it traces back to the ORIGINAL caller. By "ORIGINAL" I don't mean the location script that called it, or even the location of the script that called the script that called it, I mean the working directory of the first to initiate the chain of calls, which might be the user in the terminal or the location of the clicked executable.
Thing to consider:
- The caller's location
Bash is designed to automatically reinterpret where one argument ends and a new one begins based on whitespace unless the string is surrounded by double quotes. It's because Bash is so string-centric that you can call a script or function like this:
some_func John Doe "age 24"
and all of those argument will be interpreted as string literals, not variable name or command names. It's because all you can pass is strings that you can omit the quotes. Even when you pass a variable, it needs to be expanded to a string via $
before being passed. If you omit the quotes around "age 24", however, the arg count will increase to four.
Inside the function you have a similar situation. Even if the last arg is passed in with double quotes you can run into