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
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
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 -
> 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-
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.
>
> T
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='ba
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 no
