On 2020-10-19 04:55, Greg Wooledge wrote:
On Sat, Oct 17, 2020 at 03:01:13PM -0700, David Christensen wrote:
I try to use all lower case letters for variable names and all upper case
letters for constants.
ALL_UPPER_CASE is reserved for internal shell variables, and environment
variables.
Please provide a citation (for Bourne shell scripts).
If you abuse it for "constants" as well, on your head be it. You must
take care to ensure that your ALL_CAPS variable does not collide with
any internal shell variables, or environment variables.
Yes.
I use braces whenever evaluating a variable -- '${Params}'. I forget the
details why, but I do recall that this practice is important.
It isn't. It's entirely stylistic.
https://stackoverflow.com/questions/8748831/when-do-we-need-curly-braces-around-shell-variables
I don't use Bourne arrays, and I barely understand how the shell
Bourne shell does not have arrays. Neither does POSIX shell.
interpolates lists and preserves items containing whitespace. When I can't
figure it out, I switch to Perl.
OK.
No wonder I don't use arrays (or Bash) in shell scripts.
cd /home/mike
I prefer scripts that I can run from anywhere.
... hence, the cd inside the script. Doesn't matter where you call it
from, as long as the script cd's to the right location to do its work,
**AND VERIFIES THAT THE cd ACTUALLY WORKED**.
Another reason why I use 'set -e':
2020-10-19 20:06:06 dpchrist@tinkywinky ~/sandbox/sh
$ cat /etc/debian_version ; uname -a
9.13
Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05)
x86_64 GNU/Linux
2020-10-19 20:06:08 dpchrist@tinkywinky ~/sandbox/sh
$ cat set-e.sh
#!/bin/sh
set -x
cd /no/such/directory
echo $?
set -e
cd /another/bad/directory
echo $?
2020-10-19 20:06:14 dpchrist@tinkywinky ~/sandbox/sh
$ /bin/sh set-e.sh
+ cd /no/such/directory
set-e.sh: 3: cd: can't cd to /no/such/directory
+ echo 2
2
+ set -e
+ cd /another/bad/directory
set-e.sh: 6: cd: can't cd to /another/bad/directory
If the script must change the working directory, I would display that --
'set -x', 'cd ...', and 'set +x'.
For god's sake, why?
Sometimes I debug a script by opening another terminal and entering the
commands that the script executed.
Sometimes I tee(1) the output of script to a log file so I have a record
of what the script did.
I use 'set -e'
NOOOOOOOOOOO!!!!
On 2020-10-19 12:16, Greg Wooledge wrote:
> https://mywiki.wooledge.org/BashFAQ/105
I am sorry, but your article does not convince me to not set 'errexit'
in my Bourne shell scripts. If and when I do need to deal with exit
values manually, I will disable 'errexit' for the relevant stretch of
code and then re-enable errexit afterwards.
On 2020-10-19 05:00, Greg Wooledge wrote:
> using an explicit /usr/bin/rsync is sketchy at best. You
> should already have /usr/bin in your PATH
AIUI using absolute paths for tools in shell scripts is a security best
practice -- it helps defend against attacks where PATH is compromised
and/or trojaned system tools are inserted into directories at the front
of PATH.
Using absolute paths for tools also means that the script will work when
cron(8) runs it (or runs something that runs it).
David
