-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
STDIN.raw changes stty mode #2065
Comments
We have to review |
#triage Output appears the same to me
This does not confirm nor refute @asterite 's last comment about reviewing how STDIN.raw works, but it makes sense to review. The methods in question were most recently touched by #2442 where it may have fixed this issue. I have not yet confirmed this. |
It does not work for me. It may be dependent on OS or shell (I'm on OS X and zsh): crystal git:4b30588 ❯ ./bin/crystal -v
Using compiled compiler at .build/crystal
Crystal 0.18.4+56 [4b30588] (2016-06-22)
crystal git:4b30588 ❯ ./bin/crystal run.cr
Using compiled compiler at .build/crystal
"gfmt1:cflag=4b00:iflag=6b02:lflag=5cb:oflag=3:discard=f:dsusp=19:eof=4:eol=ff:eol2=ff:erase=7f:intr=3:kill=15:lnext=16:min=1:quit=1c:reprint=12:start=11:status=14:stop=13:susp=1a:time=0:werase=17:ispeed=9600:ospeed=9600\n"
"gfmt1:cflag=4b00:iflag=6b02:lflag=200005cb:oflag=3:discard=f:dsusp=19:eof=4:eol=ff:eol2=ff:erase=7f:intr=3:kill=15:lnext=16:min=1:quit=1c:reprint=12:start=11:status=14:stop=13:susp=1a:time=0:werase=17:ispeed=9600:ospeed=9600\n" |
@veelenga This now seems more likely a zsh-induced issue, since the stty settings amy be set/overridden on a terminal-by-terminal basis. |
@miketheman you are right, this seems to be zsh-induced issue: bash-3.2$ ./bin/crystal run.cr
Using compiled compiler at .build/crystal
"gfmt1:cflag=4b00:iflag=6b02:lflag=200005cb:oflag=3:discard=f:dsusp=19:eof=4:eol=ff:eol2=ff:erase=7f:intr=3:kill=15:lnext=16:min=1:quit=1c:reprint=12:start=11:status=14:stop=13:susp=1a:time=0:werase=17:ispeed=9600:ospeed=9600\n"
"gfmt1:cflag=4b00:iflag=6b02:lflag=200005cb:oflag=3:discard=f:dsusp=19:eof=4:eol=ff:eol2=ff:erase=7f:intr=3:kill=15:lnext=16:min=1:quit=1c:reprint=12:start=11:status=14:stop=13:susp=1a:time=0:werase=17:ispeed=9600:ospeed=9600\n" |
I believe that the reason i can't prove it (yet) is that my crystal script in its entirety is as follows:
If i make a commit hook in bash, python, or anything else that just exits, everything is fine. Make it in crystal and something is borked. My bash script in its entirety
Check out this I will readily admit that there is a possibility that this is being exposed because of my particular vim configuration, or by the fact that i use Fish shell, but that's not the point. The point is that the modes are being screwed and it's not possible to write a crystal app that does NOT screw them, but you can in any other language. If anyone can suggest a way to prove without a doubt that it's the mode I'm all ears. Currently i'm wondering if i can convince git to execute something that would write the mode into the commit template. And yes, if i run the crystal script NOT as part of a git hook then using vim immediately afterwards in the same terminal works fine. So, there's something that lingers when in that particular chain of events that makes this consistently reproducible. |
This issue is a big deal to me. I've been writing a cli tool that I really want to use a git hook, to solve some problems at work. I'm happy to go poke the compiler to try and fix it, but this isn't an area I'm particularly familiar with. If someone could help point me in the right area of the code to get me started I'll see if i can improve things, but with the |
A good starting point should be attaching a strace to see what it does to the IO. |
@jhass Assuming that's the Linux env we're talking about. |
well, other platforms should have similar tools. |
FWIW here's what I get. First, let's examine what require "io/console"
STDIN.raw { }
You can see the
Here we query the current state before setting the raw mode.
This sets the raw mode
and this restores the FD exactly like it previously was. Now onto: exit(0)
The only suspicious calls here I can spot are:
Which set stdout (1) and stderr (2) into non blocking mode. This is probably done by libevent2, we should look into whether it has a teardown call that would undo it. |
But I'm not certain it can affect the parent process. You can try to unset it manually to see whether it makes any difference: STDOUT.blocking = true
STDERR.blocking = true |
setting STDOUT and STDERR to blocking absolutely fixed my problem @jhass. Thank you! What's particularly interesting (to me at least) is that setting either of them to blocking fixes it. It doesn't seem to matter which one, as long as ONE is set that way. I'd be curious if this fixes @veelenga 's problem too. Also, I'm not sure if we have 2 different problems, or if the |
The practical effect of this was that it screwed up vim when you used changelog_manager as a pre-commit hook. details here: crystal-lang/crystal#2065
I just spent a couple of hours debugging a terminal redraw issue. Since I'm writing a commandline utility I assumed it had something to do with my terminal escape codes. Imagine my surprise when I discovered I could replicate the issue with This issues breaks My workaround is to put @jhass's code into an For future reference I'm on Crystal Terrible bug. Please fix this or point me to where I can fix it myself (presumably in the teardown code). NOTE: This bug also affects the |
See also issue #2713 |
Patch restores blocking mode of file desriptors in exchange of potential runtime deadlocks when dealing with stdio. As it's a potentially invasive patch it's not enabled by default and is available only under USE=blocking-stdio-hack Reported-by: Renich Bon Ciric Bug: crystal-lang/crystal#2065 Bug: https://bugs.gentoo.org/616256 Package-Manager: Portage-2.3.5, Repoman-2.3.2
Closing as duplicate of #2713 |
It is still raw mode after
STDIO.raw
call but i expect it to match the mode used before the call.It is not documented, but i guess IO.raw! should change stty mode, and IO.raw shouldn't.
The text was updated successfully, but these errors were encountered: