Problem with STDOUT after non-zero exit of crystal binary in script

[keriwarr]

$ crystal -v
Crystal 0.24.1 (2018-01-27)

LLVM: 5.0.1
Default target: x86_64-apple-macosx

Steps to reproduce

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

expected behaviour

bar.sh prints numbers 1 to 5000

actual behaviour

bar.sh behaves erratically, usually failing to print most numbers, echo occasionally printing errors.

details

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 :)

[ysbaddaden]

Duplicate of #2713 (with incomplete workaround in #5017) ?

[RX14]

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.

[keriwarr]

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

[RX14]

@keriwarr for now, yes. Or always call Crystal.restore_blocking_state before exit. Or use at_exit { Crystal.restore_blocking_state }

[asterite]

I think this is fixed now (at least the offending code now seems to work fine)

[RX14]

Fixed by #5802