You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If an urwid app is started from a shell script wrapper and is suspended with ^Z, when you try to resume the script/app with fg, the shell script wrapper is resumed, but the urwid app is still in the stopped state.
So what seems to happen is that trying to do some terminal ioctls causes the python process to receive SIGTTOU, that stops the process while it's still inside the SIGTSTP handler. Then the process is resumed while still in the sigtstp handler, where it happily re-sends SIGTSTP to itself and gets stopped again.
When the process is suspended and resumed the second time, the normal SIGCONT handler runs and everything is fine.
Description:
If an urwid app is started from a shell script wrapper and is suspended with
^Z
, when you try to resume the script/app withfg
, the shell script wrapper is resumed, but the urwid app is still in the stopped state.Affected versions (if applicable)
master
branch (specify commit)pypi
Seems to have been broken between 2.1.2 and 2.2.0
Steps to reproduce (if applicable)
but
You can check the process state from another terminal, and the python process will be in the stopped state.
At this stage you can
^Z
andfg
it again, and it will get resumed the second time round.Expected/actual outcome
fg
resumes an urwid app launched from a wrapper script every time, not every other time.The text was updated successfully, but these errors were encountered: