[Haskell-cafe] [Haskell] ANNOUNCE: silently-0.0.1 (prevent IO actions from writing to stdout)

[trystan.s at comcast.net]

Thanks for the feedback! I'll definitely update the documentation. I agree that temp files are a weird way to go about it but they're the least surprising and dangerous way I could think of handling it. 




Unix has /dev/null and Windows has a NUL device that works the same way so I could use those. 

* I could see what OS it is and try those options and use a temp file only if it's an unexpected os. Unfortunately System.Info.os reports windows (and some other os's) as "mingw32", I think it's because of how GHC was compiled. Who knows what the real os is or what each os will be reported as in the future or how they appear to other compilers and runtimes. 

* I could write to /dev/null or NUL if they exist and use a temp file if neither does, but if there's a legitimate /dev/null or NUL file then having some unrelated program write to them would be very very bad and a major pain for whoever has to figure that one out. 




I'd rather not use temp files but both of these seem problematic. Does anyone have a better idea or think that either of those are acceptable? 




Trystan Spangler 


----- Original Message ----- 
From: "Felipe Almeida Lessa" <felipe.lessa at gmail.com> 
To: "Trystan Spangler" <trystan.s at comcast.net> 
Cc: haskell-cafe at haskell.org 
Sent: Monday, March 7, 2011 3:41:07 AM 
Subject: Re: [Haskell] ANNOUNCE: silently-0.0.1 (prevent IO actions from writing to stdout) 

Hello! 

I wouldn't expect that a function that ignores the output directs it 
to a temporary file. I think that should be clearly stated on the 
documentation, as this may be undesirable. I don't know if there is a 
better way of solving this problem, though. 

(Note, however, that on Unix systems you could probably direct the 
output to /dev/null.) 

Cheers, 

-- 
Felipe. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110307/59c24e24/attachment.htm>