btw, sometimes specifying an /input with a value of "^/^/^^/" solves a few command line apps which start asking for returns when they generate an error... I had this problem with a version of ssh I was using a while ago.
I used CALL with /output on XP soon. It works fine. And my customers OS is Win7, and it works there too, after try a bit more.
I can check it at Wednesday at work, as it is holiday here tomorrow.
if I remember correctly, there was some issues about paths and quotes. Try using FileMonitor from Sysinternals and see the paths and command-line arguments for the called application.
the command which fails is "dir" ;-)
Even with VISTA, I have problems using CALL and relative paths. Changing paths and Woops! you are randomly teleported
did you put /SHELL ?
my application calls BCP.exe to import data to a SQL server database. in /output string I try to FIND "error" word, and if exists, I popup an alert.
your /output is to a pre-initialized string right?
and try /show as well.
funny, I was trying something else and just saw that /show was still a refinement and that works.
darn. I havn't used /show for years.
but I actually found a better solution.
using cheyenne's Call and add "Cmd /C" to the head of the command (without using /show)
you must simply remove the ^M chars , but at least there are no command prompts popping up.
^M chars from the piped output
That's a good solution.
rebol turns app dev times upside down. 2 hours to build an app 2 days to figure out how to launch a command line without crashing the app ;-)
The problem with /show, for me, is that it was added in such a way that it broke compatibility with the old version of CALL. Doc's stuff is a great replacement.
Max, the bug with /output in encap used to be that it would fail (i think it would actually crash) if you did not have the REBOL console open. Maybe something similar happens on the newer versions as well?
eg. try a print "something" before the call/output and see if that makes it work.