piping output to less and quitting leads to missing exception handler

[kmsquire]

I find that if I run a simple command in Julia, pipe the output to less, and quit less before Julia finishes, I get the following

$ julia -e 'for i=1:1000000; println(i); end' | less
ERROR: write: broken pipe (EPIPE)
 in yieldto at ./task.jl:21
 in wait at ./task.jl:309
 in stream_wait at ./stream.jl:289
 in uv_write at stream.jl:851
 in buffer_or_write at stream.jl:864
 in write at stream.jl:904
 in print at string.jl:5
 in print at string.jl:6
 in println at string.jl:8
 in println at stream.jl:242
 in anonymous at no file:1
 in process_options at ./client.jl:281
 in _start at ./client.jl:405
fatal: error thrown and no exception handler available.
Base.UVError(prefix="write", code=-32)
rec_backtrace at /Users/kmsquire/Source/julia/src/task.c:644
jl_switchto at /Users/kmsquire/Source/julia/usr/lib/libjulia.dylib (unknown line)
yieldto at ./task.jl:21
wait at ./task.jl:309
stream_wait at ./stream.jl:289
uv_write at stream.jl:851
buffer_or_write at stream.jl:864
write at stream.jl:904
println at string.jl:8
jl_apply at /Users/kmsquire/Source/julia/src/./julia.h:1260
jl_f_invoke at /Users/kmsquire/Source/julia/src/builtins.c:1065
println at stream.jl:242
jl_apply at /Users/kmsquire/Source/julia/src/gf.c:1632
_start at ./client.jl:453
jlcall__start_18748 at /Users/kmsquire/Source/julia/usr/lib/julia/sys.dylib (unknown line)
true_main at /Users/kmsquire/bin/julia (unknown line)
main at /Users/kmsquire/bin/julia (unknown line)

I assume that what ever signal is being thrown by the pipe closing (SIGPIPE?) isn't being handled properly.

This is on a fresh clone:

julia> versioninfo()
Julia Version 0.4.0-dev+5609
Commit 412918a* (2015-06-26 03:54 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin14.3.0)
  CPU: Intel(R) Core(TM)2 Extreme CPU X7900  @ 2.80GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Core2)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

[kmsquire]

Actually, the same bug is slightly less verbose, but also happens in 0.3.9.

[kmsquire]

(Maybe it's less verbose because the backtraces are truncated...?)

[ihnorton]

related: #9719 #9724

[JeffBezanson]

The first error is ok; you need to catch the exception caused by EPIPE if you want to silence it. The second error was the real problem.

[carnaval]

Maybe we should get an actual roadmap for IO improvements :

• can read stdout without spawning cat
• can read stderr without spawning cat