[Bug 266627] stty -f <file> should be non-blocking
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 266627] stty -f <file> should be non-blocking"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 26 Sep 2022 21:19:40 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266627 --- Comment #6 from Stefan Eßer <se@FreeBSD.org> --- (In reply to Konstantin Belousov from comment #1) > What would you expect in this case to happen? TIOCSETA override the job > control rules? I do not think this is wise. Or TIOCSETA returning EAGAIN > for instance. The later may be reasonable, but I am not sure how much code > would break. Yes, I'm also afraid that making "stty sane &" return with an error code instead of waiting for the terminal to be controlled by the stty process might cause a violation of POLA. A program that runs in the background must not change the setting of a terminal in use by the foreground process. Both, blocking until the stty program has control of the terminal, or exiting with an error code seem to be possible approaches. But I can imagine that programs that want to set the terminal mode to "raw" may rather want to wait for access to the terminal when started in the background, but this would still work if the terminal is not opened with O_NONBLOCK. According to the documentation "stty sane" does not imply O_NONBLOCK, thus the blocking behavior would still be available. If there is a way that a shell script can determine whether "stty sane" would block, I could skip that call in the script running in the background. But I do not know of a reliable method to detect that case. > Anyway, the later option probably could be done by the attached change. Do you > know what e.g. Linux does in this case? Linux blocks the system call in the same way as FreeBSD: $ stty sane & [1] 8 $ fg stty sane $ -- You are receiving this mail because: You are the assignee for the bug.