Maybe I looked at this too long and missing something obvious (hopefully):
Windows, OE 11.1
I'm trying to initiate two batch-processes form within progress. The scripts work when run from command-line. When same command is executed via OS-COMMAND it works, too - as long as I don't use either NO-WIAT, NO-CONSOLE, nor SILENT.
with SILENT the process simply hangs.
with NO-CONSLE the process executes, but the output redirection doesn't redirect. All output is simply lost
with NO-WAIT the black box appears, and all output is displayed there and not redirected, thus being lost as well.
The command is something like
OS-COMMAND VALUE ("python c:\temp\xyz.py > c:\temp\xyz.log 2>&1").
Anybody any ideas how to get this to work?
BTW, eventually, this process is going to executed by an app server/webspeed agent. So there is definitely no UI possible.
Thank you for any ideas...
What happens if you put the command itself into a batch file and call that from OS-COMMAND?
I tried that, too... same issue...
Ok here's what I found:
If I do
OS-COMMAND NO-WAIT "x.bat >x.log 2>&1"
and test.bat does a
the python errors are displayed in the black-box, and lost. If I add a separate output recordation to the python call in the bat file, the behavior does not change.
If I change NO-WAIT to SILENT, the redirection within the bat file works, and captures the python errors.
Well, "it works with SILENT" is not quite true either... at least not always... with a simple test.bat, that only echos the input parameters it works.
Trying to first start OpenOffcie in a headless mode, then run a python script, it simply hangs. Haven't figured out why, since it runs with no modifier and with NO-WAIT...
Did I ever mention I hate windows? Well, I do!!!
I don't know why, but I had the same issue in the past.
I solved adding "call" before the command.
os-command value ("call python.....
You need to be careful when running batch files, especially if within the batch it starts another batch.
If you want to run a batch from within a batch but want further processing done in the initail batch, then you must CALL the second batch. The second batch becomes a child process of the first and will return focus back to the first when finished.
If you don't, then the process that started the inital batch (your OS-COMMAND) will finish at the point of starting the second batch and the second batch will run without a parent process.
Ah! Thank you Adriano... I'll try that!
Thank you Tony for reminding me about that! Yes, I remember now... :) Windows is different (and more complicated) than unix in this regard, too..
If you're still stuick on this. T=You may want to give up on os-command and try using .Net to do this.
Here's an example that attempts to run the windows shutdown command and captured standard output and error output. It may be enough to get you started.
DEF VAR PSI AS ProcessStartInfo.
DEF VAR oProcess AS Process.
PSI = NEW ProcessStartInfo().
PSI:CreateNoWindow = TRUE.
PSI:UseShellExecute = FALSE.
PSI:FileName = "shutdown".
PSI:RedirectStandardOutput = TRUE.
PSI:RedirectStandardError = TRUE.
/* Will show an error */
/*PSI:Arguments = "/a".*/
/* Standard output */
PSI:Arguments = "/?".
oProcess = Process:Start(PSI).
Thank you Tom.
But I definitely do not want to do anything with .NET. MS has a history of not being backwards compatible. The whole reason I am doing OpenOffice and Python is because a) it ties me to MS and I want to be able to run on UNIX and support any OS for my clients (thus WebSpeed - GUI is dead), and b) the excel interface is not reliable anyhow - meaning you never know when it will simply fail as they changed stuff around.
If I could help it, I would completely remove anything MS from my life. Unfortunately, there are still people around that drank the MS Cool-Aid and insist on having MS servers, despite all the problems. So I just have to bite the bullet... But, I definitely don't want to deal with .NET...
Still, I am glad you explained how to do it, so other folks - who might not be so .NET averse - might be able to work around the issues with the command-prompt execution...