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@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@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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On Thu, Jan 29, 2004 at 02:53:21PM -0000, Simon Marlow wrote:
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,
Very strange indeed.
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)
Neat. If I understand the specs correctly, the following should also work. translate str = '"' : foldr escape ('"':[]) str where escape '"' t = '\\':'"':t escape '\\' t = '\\':'\\':'"':'"':t escape c t = c:t Who is going to write the unit test for that? And assuming both of our solutions satisfy the specs, which one will work for more versions of Windows? :-) Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page.
Simon Marlow wrote:
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...
Note that this is how the startup code of programs compiled with a Microsoft C/C++ compiler interprets the command line. On Windows, it's the responsibility of the programs to parse the command line; there is no real standard way of interpreting it (and I can imagine that programs compiled by compilers from other companies, or even other Microsoft compilers, will interpret things differently). Here are some pages that give informations on Windows-related limitations and deviations from Unix conventions: http://support.microsoft.com/default.aspx?scid=kb;en-us;830473 Command lines and environment variables effectively limited to 8191 characters on Win XP, 2047 on NT/2000 (probably even less on Win 9x): http://www.microsoft.com/windowsxp/home/using/productdoc/en/default.asp?url=... Command-line substitution under Windows XP. IIRC these facilities (or at least a large subset of them) are available on Win NT and 2000. Some might be available on Win 9x. http://www.microsoft.com/windowsxp/home/using/productdoc/en/default.asp?url=... How CMD.EXE processes command lines. My personal summary is that it's generally unwise to try to utilize any Microsoft command shell. Their behaviours depend on too many external influences, most prominently the exact Windows version, but (to a lesser extent) registry settings; command-line processing is riddled with kludges that work for 99% of practical cases but will fail in a spectacular and miraculous manner for the remaining 1%. Call programs directly. Using that, you know exactly what's going on, and don't have to worry about the MS kludges of tomorrow. Port bash to the MinGW environment if you really, really want or need a full-featured shell (I wouldn't recommend that either, the Unix shells are too feature-laden to easily determine how to make a specific call faultproof - besides, they are incompatible with each other, too). Oh, there is *one* scenario where I could imagine that calling the shell is a good idea: when the user provides a command line (maybe as user input, maybe as configuration option), and the Haskell program is supposed to run that command line unchanged (or after some substitutions in it). For this case, the libraries *should not substitute anything*. Trying to mimic Unix behaviour is probably a generally bad idea (*what* Unix behaviour? bash? csh? ksh? zsh? ...) Regards, Jo -- Currently looking for a new job.
participants (3)
-
Carsten Schultz -
Joachim Durchholz -
Simon Marlow