On 8/2/20 4:01 AM, Oğuz wrote:
> $ set -u
> $ unset foo bar
> $ typeset -i foo bar
> $
> $ foo+=foo+1
> $
> $ foo+=bar+1
> bash: bar: unbound variable
>
> Only referencing `bar' triggers the _unbound variable_ error, it makes
> sense that the name being assigned is
On 8/2/20 3:34 AM, Lawrence Velázquez wrote:
>>> % bash -c 'set -u; typeset -i v; v+=1; printf "<%s>\\n" "$v"'
>>> <1>
>>> % ksh -c 'set -u; typeset -i v; v+=1; printf "<%s>\\n" "$v"'
>>> <1>
>>> % zsh -c 'set -u; typeset -i v; v+=1; printf "<%s>\\n" "$v"'
>>> <1>
>
> ...which contrasts with the
On 8/1/20 8:47 PM, Lawrence Velázquez wrote:
>> 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
On 8/1/20 2:48 PM, Kristof Burek wrote:
> Bash Version: 5.0
> Patch Level: 3
> Release Status: release
>
> (Machine is a Raspberry Pi running Raspbian "Buster")
>
> Description:
> After set -u in a script: when x has not yet been bound to a value,
> I would expect the statements
However,
> In arithmetic evaluation context, if a variable for which the integer
attribute is set appears at the LHS of an assignment operator, it shouldn't
be expanded.
would be a reasonable feature request I guess.
--
Oğuz
2 Ağustos 2020 Pazar tarihinde Lawrence Velázquez yazdı:
> > On Aug 2, 2020, at 2:51 AM, Oğuz wrote:
> >
> > `u' has no members, so there's nothing to expand. If you use `${u[0]}'
> for
> > example, you'll see an error, I think how bash and ksh behave is
> perfectly
> > reasonable.
>
> Agreed. T
> On Aug 2, 2020, at 2:51 AM, Oğuz wrote:
>
> `u' has no members, so there's nothing to expand. If you use `${u[0]}' for
> example, you'll see an error, I think how bash and ksh behave is perfectly
> reasonable.
Agreed. Their behavior logically follows from POSIX's carveout for $@.
>> % bash -c
2 Ağustos 2020 Pazar tarihinde Lawrence Velázquez yazdı:
> > On Aug 1, 2020, at 8:47 PM, Lawrence Velázquez wrote:
> >
> > Presumably none of these shells implements u+=(t) as u=("${u[@]}" t).
>
> Granted, they do disagree on ${u[@]}.
>
> % bash -c 'set -u; unset u; u=("${u[@]}" t); typeset -p u
> On Aug 1, 2020, at 8:47 PM, Lawrence Velázquez wrote:
>
> Presumably none of these shells implements u+=(t) as u=("${u[@]}" t).
Granted, they do disagree on ${u[@]}.
% bash -c 'set -u; unset u; u=("${u[@]}" t); typeset -p u'
declare -a u=([0]="t")
% ksh -c 'set -u; unset u; u=("${u[@]}" t); t
> On Aug 1, 2020, at 2:48 PM, Kristof Burek 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
Configuration Information [Automatically generated, do not change]:
Machine: arm
OS: linux-gnueabihf
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-kjgNqe/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
unam
11 matches
Mail list logo
