#10171: runghc has problem when the argument list is too big -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: POSIX | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #7980 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #7980 Comment: Usually there is a limit on the size of an individual argument as well as a (much larger) limit on the total size of all the arguments. So the `':main ["arg1", "arg2"]'` argument can end up exceeding the former limit even when the original command was nowhere near either limit. See #7980. This may be what is going wrong for you too (despite the wording of the error message "Argument ''list'' too long"; note that it is the same in the linked ticket). The way to fix this would be to preserve the original argument list as a suffix of the argument list to ghc, with something like {{{ -ignore-dot-ghci -x hs -e ':set prog "script.hs"' -e ':main' script.hs --with-remaining-arguments arg1 arg2 }}} That still leaves the original issue, though. If `xargs` really leaves ''no'' extra room in the argument list size, I would consider that more than a bit crazy. Recall also that `runhaskell` is a symbolic link to `runghc` and the user could invoke the latter directly, which gives you 4 fewer characters to work with. For that matter, the user could invoke `runghc` through another symlink named `r`, and then you are really stuck! For this reason I think playing games with the lengths of GHC's options is a bit misguided. It may be the simplest solution to both issues to have `runghc` simply invoke the GHC API directly (ideally reusing the code of `ghci`) rather than launching a separate `ghc` process. Now that we have dynamic libraries, the extra binary size is no concern right? :) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10171#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler