Re: param expansion with single-character special vars in the environment

[Chet Ramey]

On 4/27/16 4:07 PM, Eduardo A. Bustamante López wrote:
> Here's the updated list of cases:

Thanks for the list of test cases; these were very helpful.

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: PATCH: fixes to BASHOPT and -O optname behavior

[Chet Ramey]

On 5/1/16 3:24 AM, Grisha Levit wrote:
> Please consider the patch below, which fixes the following:
> 
> * When starting a shell with both $BASHOPTS in the environment and -O
> optname options, processing of environmental $BASHOPTS was blocked due to
> the variable already being present and readonly by this time.
> * When extdebug was toggled, it caused toggling only of functrace, not of
> both functrace and errtrace, as described in the docs
> * When extdebug was toggled, SHELLOPTS were not being updated to reflect
> the new err/functrace state
> * When the shell did not enable extdebug due to the debugger init file not
> being present, $BASHOPTS was not being updated to reflect this change.

Thanks for the fix.  This will be in bash-4.4.

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: Global variable modification by nameref chain

[Dan Douglas]

On Fri, May 6, 2016 at 8:28 AM, Grisha Levit  wrote:
> The issue I was trying to raise is that assignment modifies the global
> variable but expansion uses the local value.
> If the assignment to the global variable is intentional, then shouldn't
> expansion use the global variable's value as well?

Nope. There's no workaround other than to unset every variable with a
conflicting name that lies between you and the global. Even if you
want to try that, there's no way to know how many such variables there
are and which one is currently visible.

declare -g is still sometimes useful though. I use it to set bash
special variables and configurations in bashrc to better ensure
they're being put into the actual global scope and should apply
everywhere. `declare -gn` is a little unusual since normally you
wouldn't use -n with other options, but I can see the use for `-gn`.

Re: Global variable modification by nameref chain

[Chet Ramey]

On 4/27/16 9:05 AM, Grisha Levit wrote:
> Is the behavior below expected? In the presence of a local $var, the
> /global/ $var can be modified by assigning a value to a local nameref that
> points to a global nameref that points to $var. However, the local nameref
> expands to the /local/ value of $var.

Yes, that's how it works.  The nameref resolution search doesn't re-start
back at the original context.  It's like a symbolic link -- it continues
at the same context as the resolved nameref.

I don't have any plans to change this before bash-4.4.

-- 
``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/