>If you look closely, you'll see that translate isn't applied to the
>argument to runCommand. There's no double-translation going on, we just
>pass the command line directly to cmd.exe/command.com.
ah, sorry, I missed that extra-parameter backdoor, thanks!-)
>rawSystem needs to convert the [String] parameters into a single string
>for passing to CreateProcess. I'm pretty sure that translate is doing
>the right thing here, at least if the target process is using the
>standard command-line parser from Microsoft's C runtime.
there doesn't appear to be a single standard. translate works most of
the time because there is a common untranslation of command-lines,
but the problem is that the current interface doesn't allow me to switch
off translation for rawSystem or runProcess, in those cases where it
doesn't work. and if command.com is one of those cases, that is an
important exception.
>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.
>The translation could be made to avoid using quotes in cases where
>quotes aren't necessary. But you can't avoid quoting in general, so
>this wouldn't be a proper fix.
it wouldn't be a complete fix, but it would fix some bugs in the current
approach, where unnecessary quotes cause some progs to choke. Most
of the time, I'd rather do the quoting myself, knowing what intermediate
levels come into play, than have the api make a guess and get it wrong.
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
