Re: Home made backup system
On Thu, Dec 19, 2019 at 10:03:57AM +0200, Andrei POPESCU wrote:
> On Mi, 18 dec 19, 21:42:21, rhkramer@gmail.com wrote:
> > On Wednesday, December 18, 2019 12:26:04 PM tomas@tuxteam.de wrote:
> > > #!/bin/bash
> > > home=${HOME:-~}
>
> It will set the variable 'home' to the value of the variable 'HOME' if
> set (yes, case matters), otherwise to '~'.
It appears to expand the ~, rather than assigning a literal ~ character
to the variable.
wooledg:~$ x=${FOO:-~}; echo "$x"
/home/wooledg
I'm not sure I would trust this, though. Even if the standards require
this behavior (and I'd have to lawyer my way through them to try to
figure out whether they actually DO require it), I wouldn't trust all
shell implementations to get it right.
And in any case, $HOME and ~ should normally both be the same thing,
so long as the ~ isn't quoted, and the $HOME isn't single-quoted.
Tilde Expansion
[...]
If this login name is the null string, the tilde is replaced with the
value of the shell parameter HOME. If HOME is unset, the home direc‐
tory of the user executing the shell is substituted instead.
So, home=${HOME:-~} seems like some sort of belt-and-suspenders fallback
check in case the script is executed in a context where $HOME hasn't been
set. Maybe in a systemd service or something similar? That's all I
can think of.
If that's the intent, then I might prefer something more explicit,
and less likely to trigger an obscure shell bug, like:
if [ -z "$HOME" ]; then HOME=~; export HOME; fi
Then you can simply use $HOME in the rest of the script.
(See also <https://mywiki.wooledge.org/BashPitfalls#pf28>. And if you're
a set -u person, too bad. Mangle it for -u compatibility yourself. You
should know how, or else you shouldn't be using -u.)
Reply to: