-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@ close-tab
remote-control does not appear to run synchronously
#5895
Comments
Doesnt repro for me running it with 130 iterations (from master). Does it still repro if you add --no-response to the @ close-tab command? |
Basically, what I suspect is happening is in your system kitty is shutting down before the response is written for the close-tab command. There is no good way to fix this, I would suggest just using --no-response for @ close-tab if you expect it to potentially cause kitty to quit. |
Yes, the bug still reproduces with Modified
Built kitty from source with |
Doesnt reproduce for me at all, with the original or modified script. Add set -o verbose to see which command is hanging. |
Actually from your screenshot its probably launch not getting a response, try adding --no-response to launch to confirm |
kitty @ set-tab-title $'\U1f527'
kitty @ env WORKDIR=/tmp
for i in {1..5}; do kitty @ launch --tab-title tab_$i --type tab --no-response; done
kitty @ close-tab --match env:WORKDIR --no-response
kitty @ close-tab --self --no-response Lucky enough to get kitty to hang on the very first iteration:
|
Then I'm out of ideas without being able to reproduce there isnt much |
Oh and see if theis commit helps: 0c7b4df |
I pulled the changes from I will work on attaching a script to reproduce the bug. |
It doesnt reproduce with --no-response (on all the @ commands) anymore, at least for me. it will still reproduce rarely without --no-response. |
Describe the bug
The
@ close-tab
remote-control does not appear to run synchronously. The issue is that if I put two separate@ close-tab
remote-control commands immediately after one another, the second command seems to affect the first one.To Reproduce
/tmp/workrc
:kitty @ close-tab --match all
is broken #5894 yet, I am choosing to close all tabs in two steps.)i=0; while :; do kitty --config NONE -o 'allow_remote_control yes' bash --rcfile /tmp/workrc; sleep 0.1; (( ++i )); echo iteration $i; done
.Observed Behavior
At some random point in time, kitty fails to close all tabs and the script hangs. Probably because the second
@ close-tab
affected the first one?In the screenshot below, observe that kitty is sitting idle with tab_1 in iteration 9. (kitty should have exited.)
Environment details
Additional context
sleep 0.5
in between the two@ close-tab
commands withinworkrc
to calm down any potential race condition. My observation is that this bug then does not reproduce.The text was updated successfully, but these errors were encountered: