Re: [PATCH 1/1] Properly reset options for run of #!-less script
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 makes them > properly handle some #defines that were previously not being respected. Thanks for the fix. -- ``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: param expansion with single-character special vars in the environment
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
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
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
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?
Re: Global variable modification by nameref chain
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/