Problem with ghc on Windows ME

[C.Reinke]

> It's called 'raw' because it is supposed to get the arguments through
> *unmodified* to the called program.  No file globbing, no escape stuff,
> nothing.

That's exactly what I'm worried about: it seems that rawSystem is
*not* passing the arguments unmodified, but tries to compensate for
windows interpretation, from a unix perspective (*).

As long as "raw" means "unmodified", I just have the problem of
finding the appropriate documentation for the system I'm working
on (after all, that's why it's in System). But if there are two
interpreters fighting with each other for some unstable balance,
things do not look so promising.

For instance, I can't use rawSystem in ghc-6.x because there are
already two different versions in circulation, and a third one
planned. So, instead of simplifying my code, I'd have to triplicate
it, and add version testing, which adds preprocessing..

Therefore, my suggestion would be to keep the rawSystem from
ghc-6.0.1 (which doesn't seem to do any interpretation?), and
to provide a system-specific escape function

  System.Cmd.escape :: String -> String -> String
  -- (System.Cmd.escape chars string) escapes occurrences of 
  -- chars in string, according to convention on the current
  -- system

If really necessary, there could be a convenience function
somewhat like:

  -- try to do "the right thing"
  System.Cmd.rawSystem' :: String -> [String] -> IO ExitCode
  System.Cmd.rawSystem' path args =
    rawSystem $ concat (path:[' ':(escape "\\\"" a) | a <- args])

Since the implementation of rawSystem in the current binary
release appears to be buggy, there is still a chance to declare
the original behaviour as the intended one and have the same
code work in all versions of ghc-6 that may be installed out
there..

Claus

(*) I can't think of any case where I could pretend that a
    rawSystem call on unix could be the same as one on any
    other system - not with all the system variations around
    on windows alone (mingw ghc/cygwin ghc/international 
    variants of windows/different versions of windows/..).

    So what I really need is a way to specify different
    code, depending on what system I'm on (which seems to
    be the purpose of System.Info). And for that it doesn't
    really help me if I have to think about what a unix
    system call would do while writing my windows system
    call - it is well-meant, but it just adds complications.