diff options
author | Tom Ryder <tom@sanctum.geek.nz> | 2016-07-15 21:06:11 +1200 |
---|---|---|
committer | Tom Ryder <tom@sanctum.geek.nz> | 2016-07-15 21:06:11 +1200 |
commit | a7ca17b7dc5884bf5ecc9e61923afeb6e972bffd (patch) | |
tree | d0ef4554efdd4de274d520c6384c3aacffc16c98 /bash/bashrc.d/hgrep.bash | |
parent | Clean up and document syl(6) (diff) | |
download | dotfiles-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/hgrep.bash')
-rw-r--r-- | bash/bashrc.d/hgrep.bash | 10 |
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" } |