Re: set -u not working as expected

[Lawrence Velázquez]

> On Aug 1, 2020, at 2:48 PM, Kristof Burek <contact@kalvr.net> wrote:
> 
> set -u  # Bash complains and exits on first use of an unbound name

With respect to set -u neither the bash man page nor POSIX.1-2017
refer to "use" of parameters, but to their *expansion*.

> s+='t' # Line 8 - Bash should fail here

I don't see any parameter expansion here, and ksh and zsh agree:

% bash --version | head -n 1; ksh --version; zsh --version
GNU bash, version 5.0.17(1)-release (x86_64-apple-darwin18.7.0)
  version         sh (AT&T Research) 93u+ 2012-08-01
zsh 5.8 (x86_64-apple-darwin18.7.0)
% bash -c 'set -u; unset s; s+=t; printf "<%s>\\n" "$s"'
<t>
% ksh -c 'set -u; unset s; s+=t; printf "<%s>\\n" "$s"'
<t>
% zsh -c 'set -u; unset s; s+=t; printf "<%s>\\n" "$s"'
<t>

Presumably none of these shells implements s+=t as s=${s}t.

> #t=''
> t=${t}'t' # Line 12, Bash fails until line 11 loses its starting #

This fails as you expect because you're expanding $t in there.

> u+=('t') # Line 15, Bash should fail here

Again, I don't see any parameter expansion here, and ksh and zsh
agree:

% bash -c 'set -u; unset u; u+=(t); printf "<%s>\\n" "${u[@]}"' 
<t>
% ksh -c 'set -u; unset u; u+=(t); printf "<%s>\\n" "${u[@]}"' 
<t>
% zsh -c 'set -u; unset u; u+=(t); printf "<%s>\\n" "${u[@]}"' 
<t>

Presumably none of these shells implements u+=(t) as u=("${u[@]}" t).

> let v+=1 # Line 18, Once line 11 is uncommented, Bash fails here

I haven't seen the code for arithmetic expansion, but I assume it
treats v+=1 as morally equivalent to v=${v}+1 (à la C99). Thus there
*is* an expansion, which fails under set -u. Regardless of the
particulars, ksh and zsh again agree:

% bash -c 'set -u; unset v; let v+=1; printf "<%s>\\n" "$v"'
bash: v: unbound variable
% ksh -c 'set -u; unset v; let v+=1; printf "<%s>\\n" "$v"'
ksh: let: v: parameter not set
ksh: v: parameter not set
% zsh -c 'set -u; unset v; let v+=1; printf "<%s>\\n" "$v"'
zsh:1: v: parameter not set
zsh:1: v: parameter not set

> When this issue is fixed, I dare say a few perfectly working scripts
> will fall over, but I hope not too many of mine.

It's not clear that there's a bug here.

vq