prompt update and TRAPCHLD

prompt update and TRAPCHLD

[Vincent Lefevre]

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)

Re: prompt update and TRAPCHLD

[Bart Schaefer]

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?

Re: prompt update and TRAPCHLD

[Vincent Lefevre]

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)

Re: prompt update and TRAPCHLD

[Bart Schaefer]

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.

Re: prompt update and TRAPCHLD

[Vincent Lefevre]

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)