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/
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 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" >> bashdb<0> > > 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/
Re: bash --debugger on a script with no arguments
On Tue, May 5, 2015 at 2:54 PM, Chet Ramey 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" > >> bashdb<0> > > > > 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/ >
