* prompt update and TRAPCHLD
@ 2016-01-14 17:16 Vincent Lefevre
2016-01-15 2:59 ` Bart Schaefer
0 siblings, 1 reply; 5+ messages in thread
From: Vincent Lefevre @ 2016-01-14 17:16 UTC (permalink / raw)
To: zsh-workers
There seems to be a bug in the prompt update. The change of psvar[1]
in TRAPCHLD is not taken into account for the next prompt display,
but for the following one.
cventin% PS1="%*-%1v%% "
18:15:11-% TRAPCHLD() { psvar[1]=$RANDOM }
18:15:17-% sleep 3 & sleep 5 & sleep 7 &
[1] 29121
[2] 29122
[3] 29123
18:15:25-%
[1] done sleep 3
18:15:28-%
[2] - done sleep 5
18:15:30-32134%
[3] + done sleep 7
18:15:32-30185%
18:15:35-25600%
18:15:36-25600%
18:15:37-25600%
18:15:39-25600%
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: prompt update and TRAPCHLD
2016-01-14 17:16 prompt update and TRAPCHLD Vincent Lefevre
@ 2016-01-15 2:59 ` Bart Schaefer
2016-01-21 13:51 ` Vincent Lefevre
0 siblings, 1 reply; 5+ messages in thread
From: Bart Schaefer @ 2016-01-15 2:59 UTC (permalink / raw)
To: zsh-workers
On Jan 14, 6:16pm, Vincent Lefevre wrote:
} Subject: prompt update and TRAPCHLD
}
} There seems to be a bug in the prompt update. The change of psvar[1]
} in TRAPCHLD is not taken into account for the next prompt display,
} but for the following one.
That's because the prompt is being redrawn before TRAPCHILD executes.
If you change it to:
TRAPCHLD() { psvar[1]=$RANDOM; print "set $psvar[1]" }
You can see where the print output appears relative to the prompt:
18:50:09-% sleep 7 & sleep 5 & sleep 9 &
[1] 18276
[2] 18277
[3] 18278
18:50:11-%
[2] - done sleep 5
18:50:16-% set 23539
[1] - done sleep 7
18:50:18-23539% set 5119
[3] + done sleep 9
18:50:20-5119% set 17622
The right thing is to explicitly tell ZLE to update the prompt:
TRAPCHLD() {
psvar[1]=$RANDOM
[[ -o zle ]] && zle reset-prompt
}
Or perhaps your complaint is that the TRAP* function should run sooner?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: prompt update and TRAPCHLD
2016-01-15 2:59 ` Bart Schaefer
@ 2016-01-21 13:51 ` Vincent Lefevre
2016-01-21 19:13 ` Bart Schaefer
0 siblings, 1 reply; 5+ messages in thread
From: Vincent Lefevre @ 2016-01-21 13:51 UTC (permalink / raw)
To: zsh-workers
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:
cventin:~> where TRAPCHLD <14:00:55
TRAPCHLD () {
[[ -o zle ]] && zle reset-prompt
}
cventin:~> echo & <14:00:59
[1] 23998
[1] + done echo
TRAPCHLD:zle: widgets can only be called when ZLE is active
> 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.
I've now a better view of what happens. I have something like:
updprompt()
{
local njobs=$#jobstates
echo "--> $njobs" > /dev/tty
print -nP "\e]2;${njobs}\x07" > /dev/tty
echo "--> $njobs" > /dev/tty
}
(the "echo ..." are mainly added for the test).
precmd() { updprompt }
TRAPCHLD() { if [[ -o interactive && -n $TTY ]] then updprompt; fi }
When I type "echo &", in the command line, I generally get:
cventin:~> echo & <14:45:58
[1] 29151
--> 1
--> 1
[1] + done echo
--> 0
--> 0
with "0" in the terminal window title, but I sometimes get:
cventin:~> echo & <14:45:59
[1] 29153
--> 1
[1] + done echo
--> 0
--> 0
--> 1
with "1" in the terminal window title.
Now, I don't understand how this is possible if TRAPCHLD is run
after the prompt is redrawn, i.e. after updprompt has completed
in precmd!
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: prompt update and TRAPCHLD
2016-01-21 13:51 ` Vincent Lefevre
@ 2016-01-21 19:13 ` Bart Schaefer
2016-01-22 1:42 ` Vincent Lefevre
0 siblings, 1 reply; 5+ messages in thread
From: Bart Schaefer @ 2016-01-21 19:13 UTC (permalink / raw)
To: zsh-workers
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: prompt update and TRAPCHLD
2016-01-21 19:13 ` Bart Schaefer
@ 2016-01-22 1:42 ` Vincent Lefevre
0 siblings, 0 replies; 5+ messages in thread
From: Vincent Lefevre @ 2016-01-22 1:42 UTC (permalink / raw)
To: zsh-workers
On 2016-01-21 11:13:55 -0800, Bart Schaefer wrote:
> 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.
The following code solves it:
updprompt()
{
unset _trapchld_called
[...]
[[ -n $_trapchld_called ]] && updprompt
}
TRAPCHLD()
{
if [[ -o interactive && -n $TTY ]] then
{
updprompt
typeset -g _trapchld_called=1
}
fi
}
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-01-22 1:42 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-14 17:16 prompt update and TRAPCHLD Vincent Lefevre
2016-01-15 2:59 ` Bart Schaefer
2016-01-21 13:51 ` Vincent Lefevre
2016-01-21 19:13 ` Bart Schaefer
2016-01-22 1:42 ` Vincent Lefevre
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).