diff options
author | Tom Ryder <tom@sanctum.geek.nz> | 2013-07-30 14:58:54 +1200 |
---|---|---|
committer | Tom Ryder <tom@sanctum.geek.nz> | 2013-07-30 14:58:54 +1200 |
commit | f2ed10433e2dcf4a57f04b4e10e0ec8e0d30d119 (patch) | |
tree | e564125478224eade8cc6218418ca4c93ae08ab1 /bash/bashrc.d/ls.bash | |
parent | Bracing variable for safety (diff) | |
download | dotfiles-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/ls.bash')
-rw-r--r-- | bash/bashrc.d/ls.bash | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/bash/bashrc.d/ls.bash b/bash/bashrc.d/ls.bash index 03150fea..5dd65b48 100644 --- a/bash/bashrc.d/ls.bash +++ b/bash/bashrc.d/ls.bash @@ -1,5 +1,5 @@ # Function returns calculated options for ls -function __lsopts { +__lsopts() { local lsopts= local lshelp=$(ls --help) echo $lshelp | grep -- --color &>/dev/null \ |