Re: Uxexpected complaint of unbound variable
On 5/4/15 9:03 PM, James Caccese wrote:
I posted the following question to stackoverflow
(http://stackoverflow.com/questions/30042157/why-cant-i-use-declare-r-inside-a-function-fo-mark-a-variable-readonly-while)
and was advised the behavior I was witnessing was a bug in bash.
It's not a bug; it's an application of bash's scoping rules and the rules
about when a varible is not set.
With |GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)|,
|#! /bin/bash
set -u
exec {FD1}tmp1.txt
declare -r FD1
echo fd1: $FD1 # why does this work,
You create a global variable and modify its attributes.
function f1() {
exec {FD2}tmp2.txt
readonly FD2
echo fd2: $FD2 # this work,
You create a global variable and modify its attributes.
}
f1
function f2() {
exec {FD3}tmp3.txt
echo fd3: $FD3 # and even this work,
You create a global variable.
declare -r FD3
You create a `placeholder' local variable that has no value, shadowing the
global variable. When you use `declare' or its synonym `typeset' inside a
shell function, you create local variables.
The variable has no value, since you haven't assigned it one, and so is
technically unset.
echo fd3: $FD3 # when this complains: FD3: unbound variable?
Scoping: the variable with that name in the closest scope is the (unset)
local copy of FD3.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Uxexpected complaint of unbound variable
I posted the following question to stackoverflow
(http://stackoverflow.com/questions/30042157/why-cant-i-use-declare-r-inside-a-function-fo-mark-a-variable-readonly-while)
and was advised the behavior I was witnessing was a bug in bash.
With GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu),#! /bin/bash
set -u
exec {FD1}tmp1.txt
declare -r FD1
echo fd1: $FD1 # why does this work,
function f1() {
exec {FD2}tmp2.txt
readonly FD2
echo fd2: $FD2 # this work,
}
f1
function f2() {
exec {FD3}tmp3.txt
echo fd3: $FD3 # and even this work,
declare -r FD3
echo fd3: $FD3 # when this complains: FD3: unbound variable?
}
f2Is this an actual bug, or am I missing something?
-James
Re: Possible bug in 'unset' builtin
On 5/1/15 2:26 PM, Dreamcat4 wrote:
Hello.
If you unset a function, then a variable argument (argv) specified after
that function will not be unset.
Thanks for the report. Yes, once you unset a function, it's as if you
supplied the `-f' option.
This came in as the result of a fix for the unset-lets-you-unset-readonly-
functions problem in bash-4.2.
[19:24] dualbus for every fix that Chet does, he introduces like 2 bugs.
Nice way of keeping himself busy
That points to the importance of having a good, comprehensive test suite.
It's difficult to test the interaction between features otherwise.
I attached a patch for people to test.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.3-patched/builtins/set.def 2013-04-19 07:20:34.0 -0400
--- builtins/set.def 2015-05-05 13:25:36.0 -0400
***
*** 752,758
--- 797,805
{
int unset_function, unset_variable, unset_array, opt, nameref, any_failed;
+ int global_unset_func, global_unset_var;
char *name;
unset_function = unset_variable = unset_array = nameref = any_failed = 0;
+ global_unset_func = global_unset_var = 0;
reset_internal_getopt ();
***
*** 762,769
{
case 'f':
! unset_function = 1;
break;
case 'v':
! unset_variable = 1;
break;
case 'n':
--- 809,816
{
case 'f':
! global_unset_func = 1;
break;
case 'v':
! global_unset_var = 1;
break;
case 'n':
***
*** 778,782
list = loptend;
! if (unset_function unset_variable)
{
builtin_error (_(cannot simultaneously unset a function and a variable));
--- 825,829
list = loptend;
! if (global_unset_func global_unset_var)
{
builtin_error (_(cannot simultaneously unset a function and a variable));
***
*** 796,799
--- 843,849
name = list-word-word;
+ unset_function = global_unset_func;
+ unset_variable = global_unset_var;
+
#if defined (ARRAY_VARS)
unset_array = 0;
Re: bash --debugger on a script with no arguments
On Tue, May 5, 2015 at 2:54 PM, Chet Ramey chet.ra...@case.edu wrote: On 4/30/15 9:27 AM, Chet Ramey wrote: On 4/29/15 10:31 PM, Rocky Bernstein wrote: $ ./bash --debugger -i /tmp/foo.sh hi $ ./bash --debugger /tmp/foo.sh bash debugger, bashdb, release 4.3-0.91 Copyright 2002, 2003, 2004, 2006-2012, 2014 Rocky Bernstein This is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. (/tmp/foo.sh:2): 2:echo hi bashdb0 I'll have to look at this. The bash-4.3 behavior was changed to solve this problem with running the debugger in an interactive shell: http://lists.gnu.org/archive/html/bug-bash/2012-08/msg00028.html That problem still exists with the version of bashdb installed by default on my Fedora 20 system. It looks like testing for the presence of -i might solve it, but I will have to see. It turned out to be a little more complicated than that, but I think I have something that will result in the debugger being invoked only when the shell is reading a shell script. It will be in the next release. Again, thanks. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/
Re: bash --debugger on a script with no arguments
On 4/30/15 9:27 AM, Chet Ramey wrote: On 4/29/15 10:31 PM, Rocky Bernstein wrote: $ ./bash --debugger -i /tmp/foo.sh hi $ ./bash --debugger /tmp/foo.sh bash debugger, bashdb, release 4.3-0.91 Copyright 2002, 2003, 2004, 2006-2012, 2014 Rocky Bernstein This is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. (/tmp/foo.sh:2): 2:echo hi bashdb0 I'll have to look at this. The bash-4.3 behavior was changed to solve this problem with running the debugger in an interactive shell: http://lists.gnu.org/archive/html/bug-bash/2012-08/msg00028.html That problem still exists with the version of bashdb installed by default on my Fedora 20 system. It looks like testing for the presence of -i might solve it, but I will have to see. It turned out to be a little more complicated than that, but I think I have something that will result in the debugger being invoked only when the shell is reading a shell script. It will be in the next release. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
