RE: Problem with ghc on Windows ME
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 (*).
No, the effect is that the arguments are passed unmodified to the program. The implementation of rawSystem might have to do some compensation under the hood (eg. on Windows), but that's not visible to the client.
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..
This is an unfortunate situation, granted. ghc-6.0.x had a version of rawSystem that was not very raw: on Windows there was a layer of translation between rawSystem and the invoked program, and on Unix it didn't even allow you to pass any arguments to the program. We thought this was wrong, and decided to make rawSystem truly raw. Unfortunately we got it slightly wrong in 6.2. 6.2.1 will be better (I hope), and in the meantime we can offer an implementation of rawSystem that you can use locally to work around the differences - how does that sound?
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])
I don't think it's necessary to do any of this, if rawSystem works as it's intended. But I may have misunderstood your intention... Cheers, Simon
No, the effect is that the arguments are passed unmodified to the program. The implementation of rawSystem might have to do some compensation under the hood (eg. on Windows), but that's not visible to the client.
As I've learned to interpret the uncompensated arguments, I'd prefer a rawSystem without compensation, on the grounds that it'll work as anything else on this system, with more backslashes, but only one possible source of bugs instead of two. But that's just my preference.
This is an unfortunate situation, granted. ghc-6.0.x had a version of rawSystem that was not very raw: on Windows there was a layer of translation between rawSystem and the invoked program, and on Unix it didn't even allow you to pass any arguments to the program. We thought this was wrong, and decided to make rawSystem truly raw.
The translation layer is standard on Windows, isn't it? Of course, rawSystem needs to be in a form that works on Unix as well.
Unfortunately we got it slightly wrong in 6.2. 6.2.1 will be better (I hope), and in the meantime we can offer an implementation of rawSystem that you can use locally to work around the differences - how does that sound?
In released software, I'm using only system so far, so won't be affected negatively. But I still haven't managed to work around the "works in win98"/"fails in winXP" problem I mentioned, and have so far avoided trying rawSystem because of the version problem. If you can offer a workaroung to the version problem, I'll try whether rawSystem is any help in my case. Generally, it'd be great if working code would less often break with new releases (oh, and a portable popen2, while we're at it!-).
I don't think it's necessary to do any of this, if rawSystem works as it's intended. But I may have misunderstood your intention...
My intention was to get access both to the raw rawSystem and to the compensating rawSystem. Exporting both would be a simpler option. Cheers, Claus PS. On Windows98, System.system always returns ExitSuccess. Is there a way of fixing that, or at least return ExitFailure instead of ExitSuccess, to alert unsuspecting testers to the problem?
participants (2)
-
C.Reinke -
Simon Marlow