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.