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
Terminal (non)blocking #588
Comments
Sorry for the late followup, but which version of Elvish were you on and do you have a reliable way to reproduce this? Elvish used to use nonblocking IO, but it has stopped doing so for quite a while. In fact, current HEAD of Elvish doesn't do any fnctl at all; we used to have a binding for fcntl but it was removed after nonblocking IO was no longer needed. |
That was 0.11 (binary download for macOS). Sorry, I don't know a reliable way to reproduce. If anything, it seems to happen more rarely of late, but it still happens from time to time. I have not been able to figure out a pattern to it: It seems totally random. |
It can also happen when an external program exits while its file descriptors are non-blocking, and the editor don't modify the non-blocking flag before running the next command. |
Indeed, that is what the second C program in my original post does. So in that sense, I know how to reproduce it. But what I don't know is if that is the only way it happens. |
I was able to reproduce this on master using @hanche's code:
|
Well, if you manually put the terminal in nonblocking mode, it is certainly going to break programs... :) Elvish itself does not manipulate the nonblocking flag of files at all. What could be the culprit though, is Go's builtin file poller, which will put files under nonblocking mode. If that's what is happening, fixing the issue will require understanding how the file poller works... |
See also #822. Of course, nobody willingly leaves the terminal in nonblocking mode, except for testing purposes. But many programs do use nonblocking mode, and if such a program dies and is unable to turn blocking mode back on, elvish ought to be able to recover gracefully. |
Once in a while, stdin ends up in a non-blocking state. Then this happens:
Interestingly,
exec bash
followed byexec elvish
resolves this when it happens. Easier is to run this little C program:and conversely, the issue can always be triggered by running the opposite program:
Fish fixed a similar issue once. A similar fix to elvish may be a good idea. IOW, make sure the
O_NONBLOCK
flag is turned off on stdin before running an external command. As explained in the link, other shells don't do similar checks on stdout or stderr; perhaps because the problem is much less likely to happen there.In case it's relevant, I had this issue on macos High Sierra. These lines from
<sys/stdin.h>
serve to explain the misleading error message:(Aside: I ran into the same issue with my old shell (es), and switched to elvish largely for that reason. Now I probably know enough to fix the problem in es and switch back, but I think I'll stay with elvish.)
The text was updated successfully, but these errors were encountered: