Expanding an undefined array
Is the following difference intentional, a bug, or do I miss something? unset a set -- [EMAIL PROTECTED] echo $# Output: 0 typeset a set -- [EMAIL PROTECTED] echo $# Output: 1 The man page says, If the word is double-quoted, ... [EMAIL PROTECTED] expands each element of name to a separate word. When there are no array members, [EMAIL PROTECTED] expands to nothing. It doesn't mention a difference between an empty and an unset variable in this context. As a quoted 'nothing' normally counts 1 word, the 'nothing' in the first example appears to be some kind of 'super-nothing'. Regards, Bernd -- Bernd Eggink [EMAIL PROTECTED] http://sudrala.de
nullglob breaks unset of arrays
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux touchndie 2.6.18v1 #1 SMP Thu Sep 21 10:01:41 CEST 2006 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release Description: When nullglob option is enable (shopt -s nullglob), unset of an array does not work. Repeat-By: my_array=(1 2 3 4 5 6) echo Array [EMAIL PROTECTED] shopt -u nullglob # remove first entry unset my_array[0] echo Array [EMAIL PROTECTED] shopt -s nullglob # remove first entry unset my_array[0] echo Array [EMAIL PROTECTED]
Declaring a local variable circumvents -e
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include
-I./lib -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2
-g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables
uname output: Linux blahonga 2.6.25.14-69.fc8 #1 SMP Mon Aug 4
14:20:24 EDT 2008 i686 i686 i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu
Bash Version: 3.2
Patch Level: 33
Release Status: release
Description:
The test case below is pretty self-explanatory.
The assignment in fun_bad() doesn't exit the shell,
despite the set -e.
This is the version in Fedora 8.
Also happens on
* Bash Version: 3.1 Patch Level: 17 (Ubuntu Dapper)
* Bash Version: 3.2 Patch Level: 0 (from ftp.gnu.org))
Repeat-By:
-8-
#!/bin/bash
set -e
fun_bad() {
local bah=$( false )
}
fun_good() {
local bah
bah=$( false )
}
echo start
fun_bad
echo FAIL
fun_good
echo (Does not get here.)
-8-
Fix:
I haven't written a fix.
A workaround is detailed in the test case. In short, if you declare
variable on one line, and assign it on the next, it works as expected.
/August.
Re: nullglob breaks unset of arrays
[EMAIL PROTECTED] wrote: Bash Version: 3.2 Patch Level: 39 Release Status: release Description: When nullglob option is enable (shopt -s nullglob), unset of an array does not work. You're right; it does. `unset' is a builtin, so all of the shell's word expansions are performed before it is run, including globbing. If you don't protect the argument by quoting it, the nullglob extension will remove it when there are no matching filenames. Running the script with `bash -x' will show what's happening. There's no `fix' -- everything is working as it's supposed to. You've just combined things in a way that produces unexpected results. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Declaring a local variable circumvents -e
Björn Augustsson wrote:
Bash Version: 3.2
Patch Level: 33
Release Status: release
Description:
The test case below is pretty self-explanatory.
The assignment in fun_bad() doesn't exit the shell,
despite the set -e.
This is the version in Fedora 8.
Also happens on
* Bash Version: 3.1 Patch Level: 17 (Ubuntu Dapper)
* Bash Version: 3.2 Patch Level: 0 (from ftp.gnu.org))
Repeat-By:
-8-
#!/bin/bash
set -e
fun_bad() {
local bah=$( false )
}
fun_good() {
local bah
bah=$( false )
}
echo start
fun_bad
echo FAIL
fun_good
echo (Does not get here.)
This isn't a bug.
The `local' command returns success if the variable assignment succeeds,
which it does. The command substitution doesn't affect its exit status.
This is how all builtins that affect variable attributes (declare/typeset,
export, readonly) should behave.
A line consisting of only assignment statements returns success unless
it contains a command substitution, in which case it returns the status
of the command substitution. This is as Posix specifies.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Expanding an undefined array
Bernd Eggink wrote: Is the following difference intentional, a bug, or do I miss something? unset a set -- [EMAIL PROTECTED] echo $# Output: 0 This is correct. typeset a set -- [EMAIL PROTECTED] echo $# Output: 1 The question is how to treat the variable created by `typeset'. Bash has traditionally treated `typeset a' as equivalent to `typeset a=' instead of creating a `placeholder' variable that exists in a sort of limbo. That's different from things like `export a' or `readonly a', and probably inconsistent enough to be worth changing for bash-4.0. That's the difference between the examples, not the expansion of [EMAIL PROTECTED]. Chet Chet The man page says, If the word is double-quoted, ... [EMAIL PROTECTED] expands each element of name to a separate word. When there are no array members, [EMAIL PROTECTED] expands to nothing. It doesn't mention a difference between an empty and an unset variable in this context. As a quoted 'nothing' normally counts 1 word, the 'nothing' in the first example appears to be some kind of 'super-nothing'. Regards, Bernd -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Declaring a local variable circumvents -e
Chet Ramey wrote:
Björn Augustsson wrote:
fun_bad() { local bah=$( false ); }
fun_good() { local bah ; bah=$( false ); }
The `local' command returns success if the variable assignment succeeds,
which it does. The command substitution doesn't affect its exit status.
This is how all builtins that affect variable attributes (declare/typeset,
export, readonly) should behave.
Note that this is also the way export works too.
Bob
