Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <160121111355.ZM25640@torch.brasslantern.com>
Date: Thu, 21 Jan 2016 11:13:55 -0800
In-Reply-To: <20160121135120.GC21104@cventin.lip.ens-lyon.fr>
Comments: In reply to Vincent Lefevre <vincent@vinc17.net>
        "Re: prompt update and TRAPCHLD" (Jan 21,  2:51pm)
References: <20160114171631.GC12351@cventin.lip.ens-lyon.fr> 
	<160114185941.ZM18307@torch.brasslantern.com> 
	<20160121135120.GC21104@cventin.lip.ens-lyon.fr>
To: zsh-workers@zsh.org
Subject: Re: prompt update and TRAPCHLD
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Jan 21,  2:51pm, Vincent Lefevre wrote:
} Subject: Re: prompt update and TRAPCHLD
}
} On 2016-01-14 18:59:41 -0800, Bart Schaefer wrote:
} > The right thing is to explicitly tell ZLE to update the prompt:
} > 
} > TRAPCHLD() {
} >   psvar[1]=$RANDOM
} >   [[ -o zle ]] && zle reset-prompt
} > }  
} 
} There's something wrong with it:
} 
} TRAPCHLD:zle: widgets can only be called when ZLE is active

Oops, that should be

    zle && zle reset-prompt

} > Or perhaps your complaint is that the TRAP* function should run sooner?
} 
} I think I was surprised when doing some tests. I thought that there
} was some race condition in my code because the TRAPCHLD was run too
} soon, but that's the opposite! So, the problem is something else.

The rule actually is that traps are executed as early as it is "safe" to
do so (memory management, etc.), and one of those times is immediately
before another command is going to be run; so the trap could execute for
example at any time during your precmd function, or during zle-line-init,
etc.

So in that sense yes, there is a race condition.