[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: rsync --delete



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


Reply to: