From f2ed10433e2dcf4a57f04b4e10e0ec8e0d30d119 Mon Sep 17 00:00:00 2001
From: Tom Ryder <tom@sanctum.geek.nz>
Date: Tue, 30 Jul 2013 14:58:54 +1200
Subject: 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
---
 bash/bashrc.d/grep.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'bash/bashrc.d/grep.bash')

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 \
-- 
cgit v1.2.3