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
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?
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?
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 readon
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, C
On 4/30/16 7:09 AM, Grisha Levit wrote:
> A number of options were not getting reset in reset_shell_flags(),
> reset_shell_options() and reset_shopt_options() so scripts without #!'s
> could sometimes run differently than expected.
>
> The attached patch makes these functions more thorough and mak
