aboutsummaryrefslogtreecommitdiff
path: root/bash/bashrc.d/ls.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/ls.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/ls.bash')
-rw-r--r--bash/bashrc.d/ls.bash2
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 \