nounset option and arrays
In the following example, I was expecting var2 not to be seen as an unbound
variable after it was declared. Wouldn't it be more consistent with the
treatment of var1 not to issue the unbound variable error in this case? What
is the rationale behind the current behavior?
bash-3.2$ shopt -s -o nounset
bash-3.2$ declare var1
bash-3.2$ echo $var1
bash-3.2$ declare -a var2
bash-3.2$ echo $var2
bash: var2: unbound variable
bash-3.2$ echo ${va...@]}
bash: va...@]: unbound variable
--
Yorick
Re: Migrating from tcsh to bash (issues)
Simos wrote: Regarding printexitvalue, I use trap '__exit_value_bashrc=$?; if [ $__exit_value_bashrc -ne 0 ]; then echo "Exit $__exit_value_bashrc"; fi' ERR so that an exit value is printed when it is other than 0. That shouldn't be necessary. An exit of 0 is not considered an error, and so should not trip an ERR trap. Freddy's example should be sufficient. (WFM with 3.2, anyway.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- ELANG: input is in wrong language (please use English on English lists)
nounset option and arrays
In the following example, I was expecting var2 not to be seen as an unbound
variable after it was declared. Wouldn't it be more consistent with the
treatment of var1 not to issue the unbound variable error in this case? What
is the rationale behind the current behavior?
bash-3.2$ shopt -s -o nounset
bash-3.2$ declare var1
bash-3.2$ echo $var1
bash-3.2$ declare -a var2
bash-3.2$ echo $var2
bash: var2: unbound variable
bash-3.2$ echo ${va...@]}
bash: va...@]: unbound variable
--
Yorick
Re: Fwd: nounset option and arrays
> In the following example, I was expecting var2 not to be seen as an unbound
> variable after it was declared. Wouldn't it be more consistent with the
> treatment of var1 not to issue the unbound variable error in this case? What
> is the rationale behind the current behavior?
>
> bash-3.2$ shopt -s -o nounset
> bash-3.2$ declare var1
> bash-3.2$ echo $var1
>
> bash-3.2$ declare -a var2
> bash-3.2$ echo $var2
> bash: var2: unbound variable
> bash-3.2$ echo ${va...@]}
> bash: va...@]: unbound variable
The bug is actually that the reference to var1 doesn't cause the shell to
exit. `declare' creates invisible "placeholder" variables that don't
actually exist until they're given a value. Until they have a value, they
should be treated as if they're unset.
Bash-4.0 treats both cases (array and scalar) as unset.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Migrating from tcsh to bash (issues)
On Thu, Feb 5, 2009 at 7:12 PM, Matthew Woehlke wrote: > Simos wrote: >> >> Regarding printexitvalue, I use >> >> trap '__exit_value_bashrc=$?; if [ $__exit_value_bashrc -ne 0 ]; then >> echo "Exit $__exit_value_bashrc"; fi' ERR >> >> so that an exit value is printed when it is other than 0. > > That shouldn't be necessary. An exit of 0 is not considered an error, and so > should not trip an ERR trap. Freddy's example should be sufficient. (WFM > with 3.2, anyway.) That's right. I reverted to the version that Freddy gave earlier. I pushed to http://github.com/simos/bashrc/ Cheers, Simos
infinitive recursion causes segfault
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
uname output: Linux fastshot.yandex.ru 2.6.20-1-686-bigmem #1 SMP Wed Apr 25
11:30:36 UTC 2007 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 3.1
Patch Level: 17
Release Status: release
Description:
Create a function that calls itself. Call it. You'll get segfault.
Expecting message on terminal.
Repeat-By:
f() { f x; }; f
bash segfaults.
Re: infinitive recursion causes segfault
y...@mx1.ru wrote: > Bash Version: 3.1 > Patch Level: 17 > Release Status: release > > Description: > Create a function that calls itself. Call it. You'll get segfault. > Expecting message on terminal. That's not a good expectation. If you want to shoot yourself in the foot, bash will not stop you. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
