Hi, Here is a simple shell script (upper.hs): import Data.Char main = interact $ map toUpper which composes fine with other scripts: bash-3.2$ yes | head -n 3 | runghc upper.hs Y Y Y but not always: bash-3.2$ yes | runghc upper.hs | head -n 3 Y Y Y <stdout>: hFlush: resource vanished (Broken pipe) Any idea why this error occurs/how to avoid it? (running just: yes | runghc upper.hs gives the expected infinite stream of Ys) Thanks! -- Éric
Hello,
this happens because "head" probably closes the file descriptor after 3
lines, and then the Haskell program tries to write to a closed handle
(i.e., it's stdout is not there anymore). The best thing to do depends on
the program. One fairly simple option would be to handle the exception, and
do something (perhaps ignore it).
-Iavor
On Mon, Aug 27, 2012 at 10:55 AM, Eric Tanter
Hi,
Here is a simple shell script (upper.hs):
import Data.Char main = interact $ map toUpper
which composes fine with other scripts:
bash-3.2$ yes | head -n 3 | runghc upper.hs Y Y Y
but not always:
bash-3.2$ yes | runghc upper.hs | head -n 3 Y Y Y <stdout>: hFlush: resource vanished (Broken pipe)
Any idea why this error occurs/how to avoid it?
(running just: yes | runghc upper.hs gives the expected infinite stream of Ys)
Thanks!
-- Éric
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Mon, Aug 27, 2012 at 1:55 PM, Eric Tanter
Here is a simple shell script (upper.hs):
"shell script" means a script written in the shell's programming language. This is probably best referred to as a Haskell script.
bash-3.2$ yes | runghc upper.hs | head -n 3 Y Y Y <stdout>: hFlush: resource vanished (Broken pipe)
Any idea why this error occurs/how to avoid it?
It's normal, and shells normally ignore it when programs in the middle of a pipeline die with SIGPIPE. Problem here is the Haskell runtime is itself intercepting the SIGPIPE and throwing a verbose Haskell exception. Possibly the runtime should detect that stdout is a pipe and disable the usual SIGPIPE handler, or if it must run cleanup stuff then it should not print anything and it should after cleanup raise(SIGPIPE) on itself with the default SIGPIPE handler so the shell will react properly. You might be able to do this yourself with (System.Posix.Signals.installHandler openEndedPipe Default Nothing). -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms
Thanks Brandon and Iavor for your (fast!) responses. Installing a silent handler as suggested by Brandon worked nicely. -- Éric
participants (3)
-
Brandon Allbery -
Eric Tanter -
Iavor Diatchki