Hi Claus,
What API would you suggest? Perhaps:
runProcessWin32
:: FilePath -- command
-> String -- argument string
-> ... -> IO ()
I'd be inclined to put this in System.Win32, or perhaps
System.Process.Win32, since we can't implement it in a sensible way on
Unix.
Cheers,
Simon
On 08 April 2005 17:37, Claus Reinke wrote:
>> It seems that command.com has non-standard command-line parsing, so
>> it won't work with rawSystem. In fact on Windows, runCommand is
>> really more "raw" than rawSystem, because it does no translation.
>
> runCommand doesn't do the waitForProcess, and it prefixes some command
> interpreter, by its own logic. what I'm looking for is the "more raw"
> effect of runCommand, but with the "no special effects" of
> rawSystem:-). In other
> words, *both* raw external process and raw, unprocessed parameters.
> Having translate exposed so that I can reuse the work you've put into
> figuring out the correct quoting for most windows apps is great, but
> it
> seems I need the option of not using it.
>
>> So I propose the following:
>>
>> - we document that rawSystem doesn't work well if you're
>> invoking command.com or cmd.exe on Windows: use runCommand
>> insteead.
>
> that doesn't quite work. runCommand has a different purpose. what is
> needed are versions of runProcess and rawSystem without translation.
>
> e.g., you might want to call command.com from Haskell on your xp box
> without setting COMSPEC - for debugging purposes, or to test backwards
> compatibility.
>
>> - we could provide a way to access runProcessWin32 directly,
>> which gives you a more "raw" interface to CreateProcess
>> on Windows (non-portable, of course).
>
> there used to be a Win32 lib. it is useful to get access to such
> low-level, system-specific functions, but I see no reason to have
> them in System,
> which is meant to hide such things.
>
> It isn't easy to come up with an alternative that respects the
> existing
> APIs as the translation is currently embedded at the lowest level,
> with
> some special casing and os-dependencies, but here's a suggestion
> (essentially move the translation into Process and make it optional):
>
> - move translate to System.Process (identity for non-windows os),
> export it there for convenience (note that the non-ghc branch
> already moves it even higher, to System.Cmd)
>
> - instead of the extra-parameter trick in runProcessXXXXX, implement
> all variants of runProcessXXXXX without translation (I assume here
> that things in Process.Internals are not meant to be called
> externally, so we need to provide the choice at a higher level)
>
> - provide runProcess', which is runProcess with a translation
> parameter, to be applied to cmd+args before passing them to
> runProcessXXXXX
>
> - implement runProcess as: runProcess' translate
>
> - implement runCommand approximately as: findShell; runProcess' id
>
> - implement system as before: runCommand; wait
>
> - implement rawSystem as before: runProcess; wait
>
> - provide rawSystem', which is rawSystem with a translation parameter:
> rawSystem' translate ~~ runProcess' translate; wait
> (so rawSystem could also be implemented as: rawSystem' translate)
>
> [I'd be tempted to export findShell as well, so that one may check
> which command-line interpreter Haskell choses; just as one can check
> os]
>
>> It'll break invoking programs other than command.com with rawSystem.
>
> In spite of my brute-force experiment, I wasn't suggesting to remove
> translate completely. many windows progs seem to do the corresponding
> untranslation, so it is very convenient to have translate, and default
> implementations of rawSystem/runProcess that use translate.
>
> the problem is that some progs don't follow those rules, and rawSystem
> as it stands doesn't cater for those, as it isn't modular enough (it
> bundles 2 functions: calling an external process without going via a
> shell, and quoting parameters to pretend "raw" parameter passing).
> one could
> try to switch of quoting depending on the cmd, extending the range of
> cmds for which rawSystem/runProcess just work magically, but leaving
> the option to the programmer seems to be less ambitious.
>
> hope this makes some sense,
> claus
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
