- Glasgow-haskell-users

RE: Problem with ghc on Windows ME
by Simon Peyton-Jones 30 Jan '04

30 Jan '04

> *** Literate pre-processor C:\GHC\GHC-6.2\unlit.exe -h Demo.lhs Demo.lhs > C:\WINDOWS\TEMP\ghc-1160737.lpp > > Failed: C:\GHC\GHC-6.2\unlit.exe -h Demo.lhs Demo.lhs > C:\WINDOWS\TEMP\ghc-1160737.lpprawSystem: does not exist (No such file or > directory) *** Deleting temp files Deleting: C:/WINDOWS/TEMP/ghc-1160737.lpp > Warning: deleting non-existent C:/WINDOWS/TEMP/ghc-1160737.lpp Simon and I spent an hour getting to the bottom of Gour's problem. Short answer: It's a bug in GHC6.2 that you really can't get round. It only shows up on Win ME/98/95, and it really makes GHC6.2 unusable on those platforms. We'll fix it in 6.2.1, but apart from that you'll have to back up to 6.0.1. Medium answer: an oversight meant that GHC6.2 invokes Win32 external commands (like gcc, unlit etc) with double-backslashes in the arguments: cat foo\\baz On NT and XP, these double-backslashes are harmless, but not on WinME/98/95, which is why we didn't notice it. The long answer is below for those who are interested, reproduced from new comments in libraries/base/System/Cmd.hs Simon M sent round a source patch yesterday. It'd be great if someone could confirm that it really works. Simon LONG ANSWER GHC uses 'rawSystem' to invoke gcc, unlit etc: rawSystem :: FilePath -> [String] -> IO ExitCode {- | The computation @rawSystem cmd args@ runs the operating system command whose file name is @cmd@, passing it the arguments @args@. It bypasses the shell, so that @cmd@ should see precisely the argument strings @args@, with no funny escaping or shell meta-syntax expansion. (Unix users will recognise this behaviour as @execvp@, and indeed that's how it's implemented.) It will therefore behave more portably between operating systems than @system@. -} {- ------------------------------------------------------------------------ - IMPORTANT IMPLEMENTATION NOTES (see also libraries/base/cbits/rawSystem.c) On Unix, rawSystem is easy to implement: use execvp. On Windows it's more tricky. We use CreateProcess, passing a single command-line string (lpCommandLine) as its argument. (CreateProcess is well documented on http://msdn.microsoft/com.) - It parses the beginning of the string to find the command. If the file name has embedded spaces, it must be quoted, using double quotes thus "foo\this that\cmd" arg1 arg2 - The invoked command can in turn access the entire lpCommandLine string, and the C runtime does indeed do so, parsing it to generate the traditional argument vector argv[0], argv[1], etc. Again, to break it into argument items, any spaces must be quoted using double quote thus cmd "this is arg 1" "this is arg 2" What if an argument itself contains double-quotes? (File names can't can't, on Windows.) Then the quote must be escaped with a backslash. If we call Create Process with this lpArgument: cmd "Foo=\"baz\"" arg2 then cmd will see argv[1] as Foo="baz" However, experiments show that backslashes themselves must *not* be escaped. That is, to get a backslash in an argument, just put backslash, even inside quotes. For eaxmple, this works fine to show the contents of the file foo\baz cat "foo\baz" If you escape the backslash, thus cat "foo\\baz" then @cat@ will see argument foo\\baz, and on WinME/98/95 you'll get "can't find file foo\\baz". (As it happens, WinNT/XP commands don't mind double backslashes, but it's still a bug, given rawSystem's claim to pass exactly args to the command.) [NOTE: this was the bug in 6.2.] BOTTOM LINE: 1 We wrap the command, and each argument, in quotes 2 Inside the quotes, we escape any double-quote characters (but nothing else) 3 Then concatenate all these quoted things together, separated with spaces Steps 1,2 are done by the function 'translate' below. Question: how do you get the string \" into an argument? Turns out that the argument "\\"" does not do the job. (This turns into a single \.) Puzzling but probably not important in practice. Note: CreateProcess does have a separate argument (lpApplicationName) with which you can specify the command, but we have to slap the command into lpCommandLine anyway, so that argv[0] is what a C program expects (namely the application name). So it seems simpler to just use lpCommandLine alone, which CreateProcess supports. ------------------------------------------------------------------------ ----- -}

3 2

RE: Problem with ghc on Windows ME
by Simon Marlow 30 Jan '04

30 Jan '04

> > 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

2 1

RE: Problem with ghc on Windows ME
by Simon Marlow 30 Jan '04

30 Jan '04

After Googling around a bit, I found this description of exactly how Windows interprets command lines in the C runtime: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng /htm/progs_12.asp As you can see, the rules are indeed very strange, but they are invertible. I think this code should do the trick: translate :: String -> String translate str = '"' : snd (foldr escape (True,"\"") str) where escape '"' (_, str) = (True, '\\' : '"' : str) escape '\\' (True, str) = (True, '\\' : '\\' : str) escape '\\' (False, str) = (False, '\\' : str) escape c (_, str) = (False, c : str) Cheers, Simon > -----Original Message----- > From: glasgow-haskell-users-bounces(a)haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of Simon Marlow > Sent: 29 January 2004 11:31 > To: Claus Reinke; Simon Peyton-Jones; > glasgow-haskell-users(a)haskell.org > Subject: RE: Problem with ghc on Windows ME > > > > So does that mean functionality has been lost in the move from > > ghc-6.0.1? > > No, the behaviour is improved in 6.2 because we're now > careful to escape > quotes before passing the command-line to the operating system. > > I think confusion has arisen because Simon pointed out that there's no > way, on Windows, to pass this sequence of characters as an > argument to a > command: > > \" > > This is not entirely true, I just discovered that the > sequence \\\" will > turn into \". But in general, the sequence \\ does not turn into \. > Windows' command-line quoting rules are highly mysterious, to say the > least. > > So the patch I posted is not complete. It looks like rawSystem should > additionally translate \" as \\\". > > > Because that (on win98) happily accepts such useful > > contraptions as > > > > System.Cmd.rawSystem "\"c:\\silly > > space\\Vim\\vim62\\gvim.exe\" --servername GVIM --remote-send > > \":echo \\\"hi \\\\\\\" there\\\"<cr>\"" >>= print > > The idea is that you should pass to rawSystem *exactly* the > command and > arguments you want to run, with no quoting except that required by the > Haskell lexical syntax. You'll notice that rawSystem now takes the > command and list of arguments separately in 6.2. The > implementation of > rawSystem will attempt to compensate for the internal translation that > Windows does on the command-line; on Unix no translation is necessary. > So clients of rawSystem should be more portable, because they > don't have > to know about quoting that happens under the hood. > > Your example will probably work once it's reformulated for > 6.2's version > of rawSystem, and once we fix rawSystem in light of the \\\" hack I > discovered above. > > Cheers, > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

3 2

Re: Problem with ghc on Windows ME
by C.Reinke 30 Jan '04

30 Jan '04

> 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.

2 1

RE: Problem with ghc on Windows ME
by Simon Marlow 30 Jan '04

30 Jan '04

> So does that mean functionality has been lost in the move from > ghc-6.0.1? No, the behaviour is improved in 6.2 because we're now careful to escape quotes before passing the command-line to the operating system. I think confusion has arisen because Simon pointed out that there's no way, on Windows, to pass this sequence of characters as an argument to a command: \" This is not entirely true, I just discovered that the sequence \\\" will turn into \". But in general, the sequence \\ does not turn into \. Windows' command-line quoting rules are highly mysterious, to say the least. So the patch I posted is not complete. It looks like rawSystem should additionally translate \" as \\\". > Because that (on win98) happily accepts such useful > contraptions as > > System.Cmd.rawSystem "\"c:\\silly > space\\Vim\\vim62\\gvim.exe\" --servername GVIM --remote-send > \":echo \\\"hi \\\\\\\" there\\\"<cr>\"" >>= print The idea is that you should pass to rawSystem *exactly* the command and arguments you want to run, with no quoting except that required by the Haskell lexical syntax. You'll notice that rawSystem now takes the command and list of arguments separately in 6.2. The implementation of rawSystem will attempt to compensate for the internal translation that Windows does on the command-line; on Unix no translation is necessary. So clients of rawSystem should be more portable, because they don't have to know about quoting that happens under the hood. Your example will probably work once it's reformulated for 6.2's version of rawSystem, and once we fix rawSystem in light of the \\\" hack I discovered above. Cheers, Simon

3 2

RE: Network problem with ghc on WinXP
by Simon Marlow 30 Jan '04

30 Jan '04

Is there a reason not to export PortNumber abstractly? I can't think of one off-hand. Cheers, Simon > -----Original Message----- > From: glasgow-haskell-users-bounces(a)haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf > Of Sigbjorn Finne > Sent: 29 January 2004 06:37 > To: robin abraham > Cc: glasgow-haskell-users(a)haskell.org > Subject: Re: Network problem with ghc on WinXP > > Hi there, > > looks like a network byte-order vs host byte-order gotcha. > Never use the PortNum constructor, but declare 'portnum' > to have type PortNumber and simply drop the use of PortNum > in your code alltogether. Alternatively, use intToPortNumber > to translate between Int and PortNumber. > > hth > --sigbjorn > > ----- Original Message ----- > From: "robin abraham" <abraharo(a)cs.orst.edu> > To: <glasgow-haskell-users(a)haskell.org> > Sent: Wednesday, January 28, 2004 21:57 > Subject: Network problem with ghc on WinXP > > > > Hi, > > > > I have ghc-6.0.1 on WinXP and Solaris. I have a simple echo server > (server.hs > > given below) and client (client.hs given below) and I encounter the > following: > > 1) server.hs compiled and running on Solaris: > > a) client.hs (Solaris) can connect. > > b) client.hs (WinXP) cannot connect. > > c) telnet (WinXP) can connect. > > d) telnet (Solaris) can connect. > > e) Scan of port 3000 shows server is listening. > > > > 2) server.hs compiled and running on WinXP: > > a) client.hs (Solaris) cannot connect. > > b) client.hs (WinXP) can connect. > > c) telnet (WinXP) cannot connect. > > d) telnet (Solaris) cannot connect. > > e) Scan of ports does not show server. > > > > Basically, when the server is running on WinXP, only the > Haskell program > > client.hs (also running on the same WinXP machine) can > "converse" with it > > through the socket connection. To verify this, I wrote a > client in C# - > from the > > WinXP machine, it can connect to server running on my > Solaris machine but > not to > > server on the same WinXP machine. > > > > Why isn't the server program on WinXP not behaving itself? Any > help/guidance > > would be highly appreciated. > > > > Thank you. > > Robin. > > > > -- server.hs > > module Main where > > > > import SocketPrim > > import Concurrent > > import System (getArgs,exitFailure) > > import Exception(finally) > > import MVar > > import IO > > > > server_sock :: IO (Socket) > > server_sock = do > > s <- socket AF_INET Stream 6 > > setSocketOption s ReuseAddr 1 > > bindSocket s (SockAddrInet (PortNum portnum) iNADDR_ANY) > > listen s 2 > > return s > > > > echo_server :: Socket -> IO () > > echo_server s = do > > (s', clientAddr) <- accept s > > h <- socketToHandle s' ReadWriteMode > > proc <- read_data s' 0 > > putStrLn ("server processed "++(show proc)++" bytes") > > sClose s' > > where > > read_data sock totalbytes = do > > str <- recv sock 18 > > putStrLn ("Server recv: " ++ str) > > if ((length str) >= 18) > > then do > > putStrLn ("Server read: " ++ str) > > writ <- send sock str > > putStrLn ("Server wrote: " ++ str) > > read_data sock $! (totalbytes+(length $! str)) > > else do > > putStrLn ("server read: " ++ str) > > return totalbytes > > > > message = "Hello there sailor" > > portnum = 3000 > > > > main = withSocketsDo $ do { > > ~[n] <- getArgs; > > ssock <- server_sock; > > s <- myForkIO (echo_server ssock); > > join s; > > putStrLn "join s"; > > } > > > > myForkIO :: IO () -> IO (MVar ()) > > myForkIO io = do > > mvar <- newEmptyMVar > > forkIO (io `finally` putMVar mvar ()) > > return mvar > > > > join :: MVar () -> IO () > > join mvar = readMVar mvar > > > > -- end of server.hs > > > > -- *********************************************** > > > > -- client.hs > > > > module Main where > > > > import SocketPrim > > import Concurrent > > import System (getArgs,exitFailure) > > import Exception(finally) > > import MVar > > import IO > > > > local = "128.193.39.108" > > message = "Hello there sailor" > > portnum = 3000 > > > > client_sock = do > > s <- socket AF_INET Stream 6 > > ia <- inet_addr local > > connect s (SockAddrInet (PortNum portnum) ia) > > return s > > > > echo_client n = do > > s <- client_sock > > drop <- server_echo s n > > sClose s > > where > > server_echo sock n = if n > 0 > > then do > > send sock message > > putStrLn ("Client wrote: " ++ message) > > str <- recv sock 19 > > if (str /= message) > > then do > > putStrLn ("Client read error: " ++ str) > > exitFailure > > else do > > putStrLn ("Client read success") > > server_echo sock (n-1) > > else do > > putStrLn "Client read nil" > > return [] > > > > main = withSocketsDo $ do > > ~[n] <- getArgs > > c <- myForkIO (echo_client (read n::Int)) > > join c > > putStrLn "join c" > > > > myForkIO :: IO () -> IO (MVar ()) > > myForkIO io = do > > mvar <- newEmptyMVar > > forkIO (io `finally` putMVar mvar ()) > > return mvar > > > > join :: MVar () -> IO () > > join mvar = readMVar mvar > > > > -- end of client.hs > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

2 1

GHC-6.2 and Template Haskell on OS X
by Gregory Wright 30 Jan '04

30 Jan '04

Hi, I have a question about ghc-6.2 and template haskell on Mac OS X. I think it's a ghc configuration or build issue, so I'm posting here instead of the TH list. I have ghc-6.2 built under darwinports. This uses a 6.0.1 binary to bootstrap the 6.2 build. I haven't updated the binary bootstrap compiler because it seems to work under both Jaguar (10.2.x) and Panther (10.3.x). The portfile builds ghc-6.2 with the command 'make all'. The resulting ghc-6.2 has worked fine until I tried to build a program using TH. I tried to build the simplest example--the one in the User's guide-- and it failed with: > ghc --make -fth main.hs -o main Chasing modules from: main.hs Compiling Printf ( ./Printf.hs, ./Printf.o ) ./Printf.hs:23: Type constructor or class not in scope: `Expr' ./Printf.hs:26: Variable not in scope: `string' ./Printf.hs:30: Type constructor or class not in scope: `Expr' > This must be a simple problem. The other thing to note about the darwinports build is that it stages the installation into a temporary directory so it can do an inventory of the files that will be installed. If a path in the staging directory gets compiled in, instead of the final installation directory, all manner of unhappiness can result. Any one have any ideas? The answer is probably staring me in the face but I'm not able to see it. Best Wishes, Greg Gregory Wright Antiope Associates LLC 18 Clay Street Fair Haven, New Jersey 07704 gwright(a)antiope.com

1 0

RE: Problem with ghc on Windows ME
by Richard Black 30 Jan '04

30 Jan '04

If you want to know what it does just refer to the source; it is and always has been distributed with Visual C. See C:\Program Files\Microsoft Visual Studio .NET 2003\vc7\crt\src\stdargv.c Richard -----Original Message----- From: Simon Peyton-Jones Sent: 29 January 2004 15:18 To: Simon Marlow; 'Claus Reinke'; 'glasgow-haskell-users(a)haskell.org' Cc: Richard Black; Simon Peyton-Jones Subject: RE: Problem with ghc on Windows ME Well found! Still, I found I could not understand the rules. But I think the story this Convert \" to \\\" otherwise convert " to \" otherwise do no conversion I think it's probably easiest to express this directly: translate :: String -> String translate str = '"' : go str where go ('\\' : '"' : s) = '\\' : '\\' : '\\' : '"' : go s go ('"' : s) = '\\' : '"' : go s go (c:s) = c : go s go [] = ['"'] Simon | -----Original Message----- | From: Simon Marlow | Sent: 29 January 2004 14:53 | To: Claus Reinke; Simon Peyton-Jones; glasgow-haskell-users(a)haskell.org | Subject: RE: Problem with ghc on Windows ME | | After Googling around a bit, I found this description of exactly how Windows interprets command lines | in the C runtime: | | http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng /htm/progs_12.asp | | As you can see, the rules are indeed very strange, but they are invertible. I think this code should do | the trick: | | translate :: String -> String | translate str = '"' : snd (foldr escape (True,"\"") str) | where escape '"' (_, str) = (True, '\\' : '"' : str) | escape '\\' (True, str) = (True, '\\' : '\\' : str) | escape '\\' (False, str) = (False, '\\' : str) | escape c (_, str) = (False, c : str) | | Cheers, | Simon | | > -----Original Message----- | > From: glasgow-haskell-users-bounces(a)haskell.org | > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf | > Of Simon Marlow | > Sent: 29 January 2004 11:31 | > To: Claus Reinke; Simon Peyton-Jones; | > glasgow-haskell-users(a)haskell.org | > Subject: RE: Problem with ghc on Windows ME | > | > | > > So does that mean functionality has been lost in the move from | > > ghc-6.0.1? | > | > No, the behaviour is improved in 6.2 because we're now | > careful to escape | > quotes before passing the command-line to the operating system. | > | > I think confusion has arisen because Simon pointed out that there's no | > way, on Windows, to pass this sequence of characters as an | > argument to a | > command: | > | > \" | > | > This is not entirely true, I just discovered that the | > sequence \\\" will | > turn into \". But in general, the sequence \\ does not turn into \. | > Windows' command-line quoting rules are highly mysterious, to say the | > least. | > | > So the patch I posted is not complete. It looks like rawSystem should | > additionally translate \" as \\\". | > | > > Because that (on win98) happily accepts such useful | > > contraptions as | > > | > > System.Cmd.rawSystem "\"c:\\silly | > > space\\Vim\\vim62\\gvim.exe\" --servername GVIM --remote-send | > > \":echo \\\"hi \\\\\\\" there\\\"<cr>\"" >>= print | > | > The idea is that you should pass to rawSystem *exactly* the | > command and | > arguments you want to run, with no quoting except that required by the | > Haskell lexical syntax. You'll notice that rawSystem now takes the | > command and list of arguments separately in 6.2. The | > implementation of | > rawSystem will attempt to compensate for the internal translation that | > Windows does on the command-line; on Unix no translation is necessary. | > So clients of rawSystem should be more portable, because they | > don't have | > to know about quoting that happens under the hood. | > | > Your example will probably work once it's reformulated for | > 6.2's version | > of rawSystem, and once we fix rawSystem in light of the \\\" hack I | > discovered above. | > | > Cheers, | > Simon | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users(a)haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | >

1 0

RE: Problem with ghc on Windows ME
by Simon Peyton-Jones 30 Jan '04

30 Jan '04

Well found! Still, I found I could not understand the rules. But I think the story this Convert \" to \\\" otherwise convert " to \" otherwise do no conversion I think it's probably easiest to express this directly: translate :: String -> String translate str = '"' : go str where go ('\\' : '"' : s) = '\\' : '\\' : '\\' : '"' : go s go ('"' : s) = '\\' : '"' : go s go (c:s) = c : go s go [] = ['"'] Simon | -----Original Message----- | From: Simon Marlow | Sent: 29 January 2004 14:53 | To: Claus Reinke; Simon Peyton-Jones; glasgow-haskell-users(a)haskell.org | Subject: RE: Problem with ghc on Windows ME | | After Googling around a bit, I found this description of exactly how Windows interprets command lines | in the C runtime: | | http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng /htm/progs_12.asp | | As you can see, the rules are indeed very strange, but they are invertible. I think this code should do | the trick: | | translate :: String -> String | translate str = '"' : snd (foldr escape (True,"\"") str) | where escape '"' (_, str) = (True, '\\' : '"' : str) | escape '\\' (True, str) = (True, '\\' : '\\' : str) | escape '\\' (False, str) = (False, '\\' : str) | escape c (_, str) = (False, c : str) | | Cheers, | Simon | | > -----Original Message----- | > From: glasgow-haskell-users-bounces(a)haskell.org | > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf | > Of Simon Marlow | > Sent: 29 January 2004 11:31 | > To: Claus Reinke; Simon Peyton-Jones; | > glasgow-haskell-users(a)haskell.org | > Subject: RE: Problem with ghc on Windows ME | > | > | > > So does that mean functionality has been lost in the move from | > > ghc-6.0.1? | > | > No, the behaviour is improved in 6.2 because we're now | > careful to escape | > quotes before passing the command-line to the operating system. | > | > I think confusion has arisen because Simon pointed out that there's no | > way, on Windows, to pass this sequence of characters as an | > argument to a | > command: | > | > \" | > | > This is not entirely true, I just discovered that the | > sequence \\\" will | > turn into \". But in general, the sequence \\ does not turn into \. | > Windows' command-line quoting rules are highly mysterious, to say the | > least. | > | > So the patch I posted is not complete. It looks like rawSystem should | > additionally translate \" as \\\". | > | > > Because that (on win98) happily accepts such useful | > > contraptions as | > > | > > System.Cmd.rawSystem "\"c:\\silly | > > space\\Vim\\vim62\\gvim.exe\" --servername GVIM --remote-send | > > \":echo \\\"hi \\\\\\\" there\\\"<cr>\"" >>= print | > | > The idea is that you should pass to rawSystem *exactly* the | > command and | > arguments you want to run, with no quoting except that required by the | > Haskell lexical syntax. You'll notice that rawSystem now takes the | > command and list of arguments separately in 6.2. The | > implementation of | > rawSystem will attempt to compensate for the internal translation that | > Windows does on the command-line; on Unix no translation is necessary. | > So clients of rawSystem should be more portable, because they | > don't have | > to know about quoting that happens under the hood. | > | > Your example will probably work once it's reformulated for | > 6.2's version | > of rawSystem, and once we fix rawSystem in light of the \\\" hack I | > discovered above. | > | > Cheers, | > Simon | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users(a)haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | >

1 0

RE: Problem with ghc on Windows ME
by Simon Peyton-Jones 29 Jan '04

29 Jan '04

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. Plain 'system' invokes the shell, and therefore does file globbing. Anything about escaping in rawSystem is an internal implementation matter S | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Malcolm Wallace | Sent: 29 January 2004 13:48 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: Problem with ghc on Windows ME | | "Simon Marlow" <simonmar(a)microsoft.com> writes: | | > The implementation of | > rawSystem will attempt to compensate for the internal translation that | > Windows does on the command-line; on Unix no translation is necessary. | > So clients of rawSystem should be more portable, because they don't have | > to know about quoting that happens under the hood. | | This is probably a silly naming question, but aren't the names of | 'System.system' and 'rawSystem' the wrong way round? On the face | of things, it would seem sensible for System.system to have the more | portable behaviour, and rawSystem to be dependent on local conventions. | After all, System.system is defined in the official Libraries Report | making no mention of any portability problems, whereas the name 'raw' | suggests that no interpretation/quoting is going on, and hence it | may be highly dependent on the underlying system. | | Regards, | Malcolm | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0