Created attachment 5780 [details] Reproduce setps in the yocto environment Pushing python to the background in Yocto system by pressing Ctrl-Z causes the shell terminal to become unusable. Reproduce steps: 1. Setup Yocto 1.7 Environment by following below link: http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html 2. Launch Yocto by executing command: runqemu qemux86 3. Change default shell Yocto shell default point to "bash", Just changing soft link and point to busybox.nosuid by command: sh-4.2#ln -sf /bin/bushbox.nosuid /bin/sh sh-4.2#sh ( Change default shell to busybox ) ~# 4. Run python and pressing "Ctrl-Z" to pushing python to the background ~#python Python 2.7.3 (default, May 21 2014, 15:09:26) [GCC 4.8.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> >>> Press 'Ctrl-Z' >>> [1]+ Stopped python Shell become unusable and no response after pushing python to background.
This problem also found in the below busybox version: Yocto 1.5.4 Busybox.nosuid Version: 1.21.1 Yocto 1.7 Busybox.nosuid Version: 1.22.1 Intel Edison Busybox.nosuid Version: 1.22.1
The cause is that python doesn't restore termios attributes, they remain set to raw input and no echo. Thus, you don't see entered chars, and [enter] key sends \r, not \n. Fixed in git, thanks!
I merged Busybox upstream patch and found it has not fixed ^Z issue completely . It's OK When just pushing one python instance into the background, But it still has display problem when launched send one, the line feed does not work and there is no character display even you had input some python command. root@edison:~# jobs [1]+ Stopped python root@edison:~# python Python 2.7.3 (default, Dec 3 2014, 17:17:19) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> Type help() for interactive help, or help(object) for help about object. >>> >>> >>> >>> File "<stdin>", line 1 echo help ^ SyntaxError: invalid syntax >>>
This is a tough call. ash can do what bash is doing, but should it? commit 098b713c7b5b22fc60b606be97da431eaedc6639 Author: Denys Vlasenko <vda.linux@googlemail.com> Date: Wed Jan 11 19:59:03 2017 +0100 ash: commented-out possible fix for 7694 bash has a feature: it restores termios after a successful wait for a foreground job which had at least one stopped or sigkilled member. The probable rationale is that SIGSTOP and SIGKILL can preclude task from properly restoring tty state. Should we do this too? A reproducer: ^Z an interactive python: $ python Python 2.7.12 (...) >>> ^Z { python leaves tty in -icanon -echo state. We do survive that... } [1]+ Stopped python { ...however, next program (python no.2) does not survive it well: } $ python Python 2.7.12 (...) >>> Traceback (most recent call last): { above, I typed "qwerty<CR>", but -echo state is still in effect } File "<stdin>", line 1, in <module> NameError: name 'qwerty' is not defined The implementation is modeled on bash code and seems to work. However, I'm not sure we should do this. For one: what if I'd fg the stopped python instead? It'll be confused by "restored" tty state.
Could something be done about this? We had the problem that other programs trigger a behaviour like this. For example when doing something like this: busybox ash /bin/su ^C # Pressing enter now echos $PS1 without \n Using the fix in the reference commit fixes the issue.