Re: declare [-+]n behavior on existing (chained) namerefs

There is also an issue when doing something like `declare -n r=a' in a function if the same has been done in a higher scope. Instead of creating a new variable r in the function's scope, it modifies the local `a' to be a self-referencing nameref.. $ declare -nt r=a; f() { declare a; declare -n r=

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

On Thu, Apr 28, 2016 at 3:14 PM, Piotr Grzybowski wrote: > b. we can forbid ># declare -n T >when T is a readonly variable > This is the one that makes the most sense to me. It shouldn't however be forbidden to do `declare -nr RO=foo' if RO is not already a readonly variable. This fee

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

ok, after some thinking, this one seems certain: 1. forbid adding nameref when the value is not a valid identifier: # declare -n reference=/ should be forbidden, as well as later assignments to nameref with strings being illegal identifiers, as we discussed/patched. what remains (rest of t

Re: Race condition in handling SIGHUP

On 4/28/16 11:49 AM, David Kaspar [Dee'Kej] wrote: > I'm going to insert the missing verb into that sentence ("remove") and > answer "yes, we're going to try it and see how it goes." > > ​Yes, you have assumed it right that I missed the word "remove"... :)​ > > ​And I think it should be

Re: Cannot grep jobs list when jobs called in a function

On Thu, Apr 28, 2016 at 12:38 PM, Eric Blake wrote: > On 04/28/2016 07:26 AM, Bishop Bettini wrote: > > Hi! > > > > As described in this Stack Overflow question > > , I'm experiencing what > > appears to me as unusual behavior with the jobs command, w

Re: Cannot grep jobs list when jobs called in a function

On 04/28/2016 07:26 AM, Bishop Bettini wrote: > Hi! > > As described in this Stack Overflow question > , I'm experiencing what > appears to me as unusual behavior with the jobs command, when jobs is > within a function. In short: > > $ jobs > [1]+ Ru

Re: Race condition in handling SIGHUP

On Thu, Apr 28, 2016 at 5:35 PM, Chet Ramey wrote: > YP was the original one; now you have things like LDAP and other directory > services. Something you use when you don't want to have everyone in the > password file. These are somewhat out of favor now. > ​Yeah, I was thinking about LDAP, but

Re: Race condition in handling SIGHUP

On Thu, Apr 28, 2016 at 2:49 PM, Chet Ramey wrote: > Because systems using a networked password database can hang at a priority > that doesn't interrupt the system call when a SIGHUP arrives. > ​I'm sorry, but what exactly do you mean by 'networked password database'? I'm not sure I follow you co

Cannot grep jobs list when jobs called in a function

Hi! As described in this Stack Overflow question , I'm experiencing what appears to me as unusual behavior with the jobs command, when jobs is within a function. In short: $ jobs [1]+ Running vim [2]+ Stopped matlab $ type realjob

Re: Race condition in handling SIGHUP

On 4/28/16 11:23 AM, David Kaspar [Dee'Kej] wrote: > On Thu, Apr 28, 2016 at 2:49 PM, Chet Ramey > wrote: > > Because systems using a networked password database can hang at a priority > that doesn't interrupt the system call when a SIGHUP arrives. > > ​I'm so

Re: Race condition in handling SIGHUP

On 4/27/16 6:04 AM, Siteshwar Vashisht wrote: > While this issue was fixed by backporting somes changes (See attached > patch) from [4] to bash-4.2 or older versions, there is still a corner > case which may cause race condition in handling SIGHUP in current upstream. > > 'bash_tilde_expand ()'