Hi all,
when I try to use runghc to execute cgi scripts in apache (on redhat
linux), they all fail with with the message HOME: getEnv: does not
exist. I assume this means that GHC is trying to find the HOME dir of
the user for some reason, and fails since apache runs as nobody. Could
someone shed
Niklas Broberg [EMAIL PROTECTED] writes:
when I try to use runghc to execute cgi scripts in apache (on redhat
linux), they all fail with with the message HOME: getEnv: does not
exist. I assume this means that GHC is trying to find the HOME dir of
the user for some reason, and fails since
Hi all,
I'm trying to use runghc (6.4 release version, redhat linux), but it
appears to be badly broken. It only processes the first argument given
to it, so while
---
runghc Foo.hs
hello
with Foo.hs being simply
main = putStrLn hello
---
works
I think runghc is acting like GHCi, and trying to read the file
$HOME/.ghci on startup.
Thanks, that may well be the case. Too bad you can't tell it not to,
see my other post about runghc and flags. :-(
/Niklas
___
Glasgow-haskell-users mailing list
Malcolm Wallace [EMAIL PROTECTED] writes:
I think runghc is acting like GHCi, and trying to read the file
$HOME/.ghci on startup.
I toyed with this, and it seems like runghc is forking off a ghc
process, which then tries to read .ghci (and possibly .inputrc) from
the $HOME directory.
when I try to use runghc to execute cgi scripts in apache (on redhat
linux), they all fail with with the message HOME: getEnv: does not
exist. I assume this means that GHC is trying to find the HOME dir of
the user for some reason, and fails since apache runs as nobody. Could
someone shed
when I try to use runghc to execute cgi scripts in apache (on redhat
linux), they all fail with with the message HOME: getEnv: does not
exist. I assume this means that GHC is trying to find the HOME dir of
the user for some reason, and fails since apache runs as nobody. Could
someone
I'm trying to use runghc (6.4 release version, redhat linux), but it
appears to be badly broken. It only processes the first argument given
to it...
[snip]
As a friend pointed out to me, some of this behavior may not be so
strange. Clearly, if you give arguments _after_ the specified source
GHC 6.4 objects to the following simple program, pointing to the partial
application of the type constructor AddL. Is there a work-around?
{-# OPTIONS -fglasgow-exts #-}
data LMap a b
type AddL arr a b = a `arr` LMap a b
data DFunA arr a b = DFunA (a `arr` b) (DFunA (AddL arr) a
