aboutsummaryrefslogtreecommitdiff
path: root/bash/bashrc.d
diff options
context:
space:
mode:
authorTom Ryder <tom@sanctum.geek.nz>2016-07-15 21:06:11 +1200
committerTom Ryder <tom@sanctum.geek.nz>2016-07-15 21:06:11 +1200
commita7ca17b7dc5884bf5ecc9e61923afeb6e972bffd (patch)
treed0ef4554efdd4de274d520c6384c3aacffc16c98 /bash/bashrc.d
parentClean up and document syl(6) (diff)
downloaddotfiles-a7ca17b7dc5884bf5ecc9e61923afeb6e972bffd.tar.gz
dotfiles-a7ca17b7dc5884bf5ecc9e61923afeb6e972bffd.zip
Replace use of ${var:?} with explicit errors
<http://mywiki.wooledge.org/BashFAQ/100#Default_or_alternate_values> >Nobody ever uses ${var?word} or ${var:?word}. Please pretend they don't >exist, just like you pretend set -e and set -u don't exist. ><tejr> from FAQ 100: >Nobody ever uses ${var?word} or ${var:?word}. ><tejr> why is that? just because it's unwieldy, or are there other >technical reasons? ><ormaaj> tejr: Putting random fatal unhandlable errors into a script is >generally useless. ><tejr> ormaaj: is it less handleable than a more explicit check, like >`[[ $var ]] || exit 1` ? ><ormaaj> yes ><ormaaj> # : ; ${_[RANDOM%2]?:you win} ><shbot> ormaaj: no output ><ormaaj> didn't win ><tejr> i was thinking more as a terse means of perhaps asserting a >variable had a value, like a positional parameter; are you saying if >you really did just want to write to stderr and exit with failure, it's >still inappropriate? ><ormaaj> depends on the complexity I suppose but I'd not consider that >unless it's the global scope in a file you know isn't going to be >sourced and has no other explicit error handling. Even then it's ugly >because it bails out in the middle of evaluating parameters that >technically could have side-effects and such. ><tejr> ahh yes, kinda a separation of concerns ><tejr> that makes more sense now! thank you > * tejr combs his scripts to see if he's used it anywhere ><ormaaj> tejr: another reason is the type of error is a bash error >which usually indicates a problem with the script where bash itself >can't continue. An unset var isn't a " bash error", You can even make >it print counterintuitive error messages that look like bash internal >errors. ><tejr> ormaaj: also compelling ><tejr> i've found a few "{@:?}"s in here so i'm fixing them up now ><tejr> thanks for the analysis
Diffstat (limited to 'bash/bashrc.d')
-rw-r--r--bash/bashrc.d/hgrep.bash10
1 files changed, 9 insertions, 1 deletions
diff --git a/bash/bashrc.d/hgrep.bash b/bash/bashrc.d/hgrep.bash
index 855fbcc8..e5a5d4c9 100644
--- a/bash/bashrc.d/hgrep.bash
+++ b/bash/bashrc.d/hgrep.bash
@@ -4,5 +4,13 @@
# $ history | grep PATTERN
#
hgrep() {
- grep "${@:?}" "${HISTFILE:?}"
+ if ! (($#)) ; then
+ printf >&2 '%s: Need a pattern\n' "$FUNCNAME"
+ exit 2
+ fi
+ if ! [[ $HISTFILE ]] ; then
+ printf >&2 '%s: No HISTFILE\n' "$FUNCNAME"
+ exit 2
+ fi
+ grep "$@" "$HISTFILE"
}