$ crystal -v
Crystal 0.24.1 (2018-01-27)
LLVM: 5.0.1
Default target: x86_64-apple-macosx
execute the following commands in your terminal (I've reproduced on sh, bash, and zsh):
echo "exit 1" > foo.cr
crystal build foo.cr
echo "#\!/bin/bash\n./foo\nfor i in {1..5000}; do echo -n \"\$i \"; done" > bar.sh
chmod 775 bar.sh
./bar.sh
Note: you may need to run ./bar.sh multiple times
bar.sh prints numbers 1 to 5000
bar.sh behaves erratically, usually failing to print most numbers, echo occasionally printing errors.
In general, I observe this behaviour any time that _within a script_ a crystal-compiled program is executed, and returns non-zero, then a substantial amount of text is printed to STDOUT.
I don't think I understand enough about binaries/STDIN/STDOUT/whatever to get much further on debugging this myself :)
Duplicate of #2713 (with incomplete workaround in #5017) ?
Ah yes, seems like we need a restore_blocking_state in exit. I'd say this is a separate bug report on the code in #5017.
And as always I maintain that STDIN and STDOUT should be left blocking as it is semantically wrong to change the blocking state on them.
Duplicate of #2713
Ah, sorry about that, I saw that ticket but didn't manage to figure out a workaround so I figured it could be different.
As a work-around, I can just put this at the start of every program?
STDIN.blocking = true
STDOUT.blocking = true
STDERR.blocking = true
@keriwarr for now, yes. Or always call Crystal.restore_blocking_state before exit. Or use at_exit { Crystal.restore_blocking_state }
I think this is fixed now (at least the offending code now seems to work fine)
Most helpful comment
@keriwarr for now, yes. Or always call
Crystal.restore_blocking_statebeforeexit. Or useat_exit { Crystal.restore_blocking_state }