Chris's Wiki :: blog/programming/BourneShellGlobalVariableOops Commentshttps://utcc.utoronto.ca/~cks/space/blog/programming/BourneShellGlobalVariableOops?atomcommentsDWiki2017-07-06T02:48:20ZRecent comments in Chris's Wiki :: blog/programming/BourneShellGlobalVariableOops.By Twirrim on /blog/programming/BourneShellGlobalVariableOopstag:CSpace:blog/programming/BourneShellGlobalVariableOops:ede8f638cb8822a58b68dd4fadec75e23d6775d8Twirrim<div class="wikitext"><p>Have you tried giving shellcheck a run at your scripts? <a href="https://github.com/koalaman/shellcheck">https://github.com/koalaman/shellcheck</a> It's been catching some interesting potential bugs in stuff. You can hook it in with vim via <a href="https://github.com/vim-syntastic/syntastic">https://github.com/vim-syntastic/syntastic</a></p>
</div>2017-07-06T02:48:20ZBy dwfreed on /blog/programming/BourneShellGlobalVariableOopstag:CSpace:blog/programming/BourneShellGlobalVariableOops:684cc6b8171ab3e5cc4e8c793c5954ad13a803d5dwfreed<div class="wikitext"><p>Declare all the variables you use in a function that shouldn't leave that function as local, eg:</p>
<pre>
reporton() {
local i
for i in foo; do
stuff
done
}
</pre>
<p>You can also use local on exported variables, and your changes will only apply within that function:</p>
<pre>
foobar() {
local TERM=dummy
env | grep TERM=
}
$ export TERM=xterm
$ env | grep TERM=
TERM=xterm
$ foobar
TERM=dummy
$ env | grep TERM=
TERM=xterm
</pre>
</div>2017-07-06T00:04:22ZBy Anon on /blog/programming/BourneShellGlobalVariableOopstag:CSpace:blog/programming/BourneShellGlobalVariableOops:120e8464a32c14bb0479316ea2f27551f7329a22Anon<div class="wikitext"><p>Have you tried ShellCheck for your bash snippets - <a href="http://www.shellcheck.net/">http://www.shellcheck.net/</a> ?</p>
</div>2017-07-05T19:30:42ZBy Chris Siebenmann on /blog/programming/BourneShellGlobalVariableOopstag:CSpace:blog/programming/BourneShellGlobalVariableOops:eae7e94dc53f563187f1d848d22ccbdc25f24995Chris Siebenmann<div class="wikitext"><p>It turns out that the actual script uses the fully correct version of
'<code>for i in "$@"; do</code>'; I just absently left out the quotes around <code>$@</code>
when I wrote the entry and was (re)writing an abstracted version of the
top level loop.</p>
<p>(It doesn't matter for this particular script because no valid argument
to it will ever have spaces in it, and it's only for my own internal
use. But always using <code>"$@"</code> in this sort of context is a good habit
to have.)</p>
</div>2017-07-05T16:51:14ZBy skeeto on /blog/programming/BourneShellGlobalVariableOopstag:CSpace:blog/programming/BourneShellGlobalVariableOops:09cac619eb449f40d0a99e15bbd6c41e72cf95f2skeeto<div class="wikitext"><p>You should wrap that <code>$@</code> in quotes so that it doesn't word split IFS within each argument. Quoting with <code>"$@"</code> is a special case in Bourne shell.</p>
<pre>
for i in "$@"; do
...
done
</pre>
</div>2017-07-05T13:14:38Z