bash-5.0: problem with variable scoping in posix-mode
Configuration Information:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -O0 -fno-omit-frame-pointer -ggdb -pipe -Wno-
parentheses -Wno-format-security
uname output: Linux gentoo-test 4.14.78-gentoo #1 SMP Wed Oct 24
20:06:13 MSK 2018 x86_64 Westmere E56xx/L56xx/X56xx (IBRS update)
GenuineIntel GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 2
Release Status: release
Description:
There is a problem with variable scoping when variable is created from
assignment statement preceding function call in posix-mode. See an
example below.
Repeat-By:
$ cat test.sh
#!/bin/sh
myecho() {
echo $var
}
foo() {
local var="foo: FAIL"
var="foo: bar" myecho
}
foo
$ bash test.sh
foo: bar
$ bash --posix test.sh
foo: FAIL
Re: case statement: wrong behaviour of the ";;&" operator
On 1/26/19 12:30 AM, Norman Krebs wrote: > Bash Version: 5.0 > Patch Level: 2 > Release Status: release > > Description: > > "echo x" shouldn't be executed here, but it gets: > > case "1" in > 1) : ;;& > 2) : ;; > *) echo x ;; > esac > > Following the man page, the ';;&' operator should cause testing the _next_ > pattern: '2)' only and not _all_ following patterns. Well, it should have "as if the pattern list had not matched." at the end there. The idea is that you move to the next pattern list and continue executing the command. It's a way to have multiple patterns match if you want to do that. It's not a frequently-used feature, it seems. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: bash-5.0: problem with variable scoping in posix-mode
On 1/27/19 7:58 AM, Alexander Tsoy wrote:
> Bash Version: 5.0
> Patch Level: 2
> Release Status: release
>
>
> Description:
>
> There is a problem with variable scoping when variable is created from
> assignment statement preceding function call in posix-mode. See an
> example below.
>
>
> Repeat-By:
>
> $ cat test.sh
> #!/bin/sh
>
> myecho() {
> echo $var
> }
>
> foo() {
> local var="foo: FAIL"
> var="foo: bar" myecho
> }
>
> foo
>
> $ bash test.sh
> foo: bar
> $ bash --posix test.sh
> foo: FAIL
This is a consequence of a combination of two POSIX features. First, POSIX
requires assignment statements preceding special builtins to create global
variables (POSIX has no local variables) that persist in the shell context
after the special builtin completes. Second, POSIX requires* that
assignment statements preceding function calls have the same variable-
assignment behavior as special builtins.
So the variable assignment preceding the function call creates a global
variable, and the local variable is found before that global when `myecho'
is executed according to the standard bash dynamic scoping rules. If you
add an `echo $var' after the call to foo, you'll see this behavior.
(*) The most recent version of the standard has removed this requirement
for shell functions, and I will change that behavior for the next release
of bash. Until then, the old behavior persists.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: `complete -p -- ` doesn't yield reusable input when "-F" is assigned an invalid identifier
On 1/24/19 12:24 PM, Great Big Dot wrote: > Bash Version: 5.0 > Patch Level: 0 > Release Status: release > > > Description: > According to the manual's section on the `complete` builtin: > > > "If the -p option is supplied, or if no options are supplied, > existing completion specifications are printed in a way that allows > them to be reused as input." > > Unfortunately, there is at least one edge cases that, despite being > invalid, are considered valid by `complete`, and the proper measures to > deal with it are not taken. Namely: > > $ complete -F 'bad func' -- cmd# No error is triggered here... > $ complete -p -- cmd # > => complete -F bad func cmd# Not quoted!! > > The expected behavior ought to be either that the first line yields an > error (e.g., "bash: `'bad func'': not a valid identifier"), I prefer this behavior, at least to the extent that the function name argument to -F can't contain any shell metacharacters. Since those characters would have to be quoted when defining the function, and you can't quote function names when defining the function (at least for the time being), you would not be able to define a valid shell function with that name. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
