Crystal command line tool leaves terminal in bad state

[garybernhardt]

Here's a little screencast showing what I'll describe: https://vimeo.com/233411965

When I run the Crystal compiler, it's doing something to the terminal that causes vim to redraw incorrectly. Specifically, in that video you see:

1. I run vim with all plugins and my .vimrc disabled (vim --noplugin -u /dev/null), to ensure that it's not a configuration issue.
2. I run the Crystal compiler on an empty file "hello.cr".
3. After Crystal exits, vim's UI is mangled: some but not all of the bars below and between splits are missing. The mangling appears random; changing the terminal size will change how it gets mangled. I created the two splits before running Crystal because that makes the mangling more apparent.
4. If I background and foreground vim (^z followed by fg), it redraws correctly.
5. The terminal seems to work correctly after that.

Here are some things that I tested:

• It still happens if I execute crystal run hello.cr && reset, resetting the terminal after crystal exits.
• Likewise for && clear.
• I thought that crystal might be printing control codes on stdout or stderr, but it's not. I faked a TTY output using expect's unbuffer command to make a realistic check: unbuffer crystal build hello.cr 2>&1 | wc -c gives 0, indicating no output to stdout or stderr.

If it's not writing control codes, it must be messing with the TTY directly somehow. Unsurprisingly, redirecting stdout to dev null (crystal run hello.cr >/dev/null) doesn't fix the problem; nor does redirecting stderr to dev null (crystal run hello.cr 2>/dev/null). However, redirecting both descriptors (crystal run hello.cr >/dev/null 2>&1) does fix it. This makes sense, since crystal can't see the TTY without a stdout or stderr.

It seems like crystal is grabbing the terminal (via stdout or stderr; whichever it can get its hands on), then doing something to it that doesn't involve writing any data, but does change the terminal state such that vim redraws incorrectly. I assume that this happens via stty, or maybe via ioctl or fcntl.

I searched for issues and didn't find this mentioned; hopefully I didn't miss one. I don't feel confident digging into crystal itself to do further analysis, since I have only five minutes of experience with crystal so far. Pardon my wordiness; this seems like a very subtle bug and I didn't want you to have to duplicate my experiments.

[garybernhardt]

I forgot to mention the most basic thing: I'm running the latest release (0.23.1) installed via homebrew on a Mac. My terminal is iTerm 2, but this also happens in Apple's Terminal.app.

$ crystal --version
Crystal 0.23.1 (2017-09-08) LLVM 4.0.1

[asterite]

Probably a duplicate of #2713

[garybernhardt]

Interesting. I agree that they probably have the same root cause. I also noticed that binaries built from crystal source (even from an empty source file) cause the same problem, which points toward it being a deeper issue with TTY IO in crystal, not the command line tool.

[RX14]

Almost certainly #2713.