On Thu, Dec 19, 2019 at 10:03:57AM +0200, Andrei POPESCU wrote: > On Mi, 18 dec 19, 21:42:21, rhkra...@gmail.com wrote: > > On Wednesday, December 18, 2019 12:26:04 PM to...@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.)