aboutsummaryrefslogtreecommitdiff
path: root/bash/bashrc.d/grep.bash
diff options
context:
space:
mode:
authorTom Ryder <tom@sanctum.geek.nz>2013-07-30 14:58:54 +1200
committerTom Ryder <tom@sanctum.geek.nz>2013-07-30 14:58:54 +1200
commitf2ed10433e2dcf4a57f04b4e10e0ec8e0d30d119 (patch)
treee564125478224eade8cc6218418ca4c93ae08ab1 /bash/bashrc.d/grep.bash
parentBracing variable for safety (diff)
downloaddotfiles-f2ed10433e2dcf4a57f04b4e10e0ec8e0d30d119.tar.gz
dotfiles-f2ed10433e2dcf4a57f04b4e10e0ec8e0d30d119.zip
More portable non-surprise syntax for functions
<tyrmored> is this syntax actually problematic? <tyrmored> function whatever { <tyrmored> thangs <tyrmored> } <zendeavor> !pf function <greybot> http://mywiki.wooledge.org/BashPitfalls#pf25 -- Don't do this! -- function foo() <tyrmored> i know it's bashism, but is it bad practice <tyrmored> yeah i know that much <tyrmored> (no parens, that is) <zendeavor> it's not necessarily a bashism, but the function keyword has implications in other shells <zendeavor> and, perhaps someday in the future, for bash as well <tyrmored> hmm, so i should use this syntax even if the scripts are explicitly bash? <ffio> hi zendeavor :) <zendeavor> you should use foo() { echo bar; } <tyrmored> rightoh <zendeavor> no surprising behaviour that way, ever <tyrmored> makes sense <zendeavor> it won't matter *much* but element of least surprise
Diffstat (limited to 'bash/bashrc.d/grep.bash')
-rw-r--r--bash/bashrc.d/grep.bash2
1 files changed, 1 insertions, 1 deletions
diff --git a/bash/bashrc.d/grep.bash b/bash/bashrc.d/grep.bash
index e5a568e1..ea75bd8e 100644
--- a/bash/bashrc.d/grep.bash
+++ b/bash/bashrc.d/grep.bash
@@ -1,5 +1,5 @@
# Function returns calculated options for grep
-function __grepopts {
+__grepopts() {
local grepopts='-I'
local grephelp=$(grep --help)
echo $grephelp | grep -- --color &>/dev/null \