Re: jobs race condition

On Mon, May 16, 2016 at 8:50 PM, Chet Ramey wrote: > jobs don't get removed from the jobs table until the user is notified > by the interactive shell. Thanks, that makes perfect sense. I'll make a new thread with a better description of the other ^C issue. It's actually not related to `jobs'

Re: jobs race condition

On 5/16/16 7:16 PM, Grisha Levit wrote: > I would expect the following loop to exit after one (or maybe two) > iterations but it runs until PIDs get recycled: > > |$ : & while [[ $(jobs) ]]; do :; done [1] 61589 TRACE: pid 51259: > delete_old_job: found pid 61589 in job 0 with state 4 | > > The l

jobs race condition

I would expect the following loop to exit after one (or maybe two) iterations but it runs until PIDs get recycled: $ : & while [[ $(jobs) ]]; do :; done [1] 61589 TRACE: pid 51259: delete_old_job: found pid 61589 in job 0 with state 4 The loop does not terminate because jobs just keeps printing [

Re: coproc and existing variables

A couple of minor things after the change (i don’t know if they’re worth looking at..) - If coproc name is a nameref to an unset variable, a nameref/array is left over: $ declare -n ref=x; coproc ref { :; }; wait; declare -p ref [1] 13267 [1]+ Donecoproc ref { :; }decla

Re: nameref in temp environment

On 5/12/16 8:58 PM, Grisha Levit wrote: > The 20160506 snapshot changes assign_in_env to do some nameref-related > checks on the variable name, but these don’t really seem to make sense > since assignments in the temporary env just create regular variables and > don’t follow the nameref chain other

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

On 5/14/16 12:16 PM, Grisha Levit wrote: > One more case, which currently segfaults: > > |declare -n REPLY; read <<< / | > > easy fix: Thanks for the fix. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey,

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

On 5/14/16 12:41 PM, Grisha Levit wrote: > On Mon, May 2, 2016 at 2:30 PM, Chet Ramey > wrote: > > I ended up writing a new function: valid_nameref_value(name, flags) which > I can customize to serve this purpose. > > Looks like this ends up getting bypassed i

Re: avoid mktemp/mkstemp internally

On 16 May 2016 10:02, Chet Ramey wrote: > On 5/13/16 2:40 PM, Mike Frysinger wrote: > > i was pointed at a bug report for FreeBSD systems [1] where running lots > > of processes in parallel would randomly fail with errors like: > > cannot make pipe for process substitution: File exists > > > > u

Re: avoid mktemp/mkstemp internally

On 5/13/16 2:40 PM, Mike Frysinger wrote: > i was pointed at a bug report for FreeBSD systems [1] where running lots > of processes in parallel would randomly fail with errors like: > cannot make pipe for process substitution: File exists > > upstream FreeBSD addressed this by defining USE_MKTEM