|
Post by David Martin on Oct 13, 2019 22:53:07 GMT 1
Is there a way to run an external EXE from a FoxProX program and pass it command line arguments?
For example: When running under 32 bit windows we can do something like RUN MYUTIL.EXE > OUTPUT.TXT that would run the MYUTIL.EXE and send all output to the OUTPUT.TXT file. We then read the contents of that file into the FoxPro program.
This doesn't work when running on Windows 10 64 bit and using VDOS 5/1/2019 ... what happens is the MYUTIL.EXE is run but the command line arguments are ignored and the OUTPUT.TXT file is not created...or is created empty.
We also need to be able to run other utilities that are EXE files that get filenames as command line arguments ... so: OTHERUTIL.EXE INPUT.TXT
These external EXEs are 32 bit Windows programs and do work as expected when run from the command prompt in 64 bit.
Thanks in advance.
David
|
|
|
Post by ejgtuc on Oct 14, 2019 0:57:02 GMT 1
David, no sera que el archivo de salida no tiene permisos en la carpeta donde se graba? Sdos Eduardo
|
|
|
Post by Jos on Oct 14, 2019 7:41:00 GMT 1
FoxPro calls upon the command shell to execute external ‘stuff’. With NTVDM this was CMD, a Windows program using the window of NTVDM. In vDos this is however the DOS-like internal command shell. If that encounters the trailing “> OUTPUT.TXT” it will redirect its standard output and eventual to start DOS program to OUTPUT.TXT. MYUTIL.EXE is however a Windows program that can’t run in the vDos window, and its standard output isn’t redirected. You need to use CMD (like NTVDM did), and make sure the redirection isn’t ‘eaten’ by the vDos command shell. For that you have to enclose the command line in some quotes:
RUN CMD '"/c MYUTIL.EXE > OUTPUT.TXT"
The current vDos version is in the habit to remove pairs of quotes, so the extra single leading one. CMD also needs a separate window, so you might want to hide that popping up:
RUN CMD HIDE'"/c MYUTIL.EXE > OUTPUT.TXT"
And keep in mind, Windows programs deal with the Windows file system, they are unaware of that of vDos.
Jos
|
|
|
Post by David Martin on Oct 14, 2019 11:37:25 GMT 1
Thanks Jos,
I knew it had something to do with running CMD outside of the vDOS shell but couldn't figure out the way to do it.
Using the second option does exactly what I was looking for.
David
|
|
|
Post by David Martin on Oct 14, 2019 13:33:22 GMT 1
Ok, so the output file is always created but FoxPro/vDOS doesn't always see it ... is there someway to "FLUSH"/reread disk after a command is sent?
|
|
|
Post by Jos on Oct 14, 2019 14:02:27 GMT 1
No such thing as a ‘reread disk’ since vDos doesn’t cache, the file just isn’t made yet. CMD returns immediately w/o waiting for MYUTIL.EXE to finish, its return code will also only reflect whether MYUTIL.EXE could be started. Even adding WAIT (so WAITHIDE) doesn’t prevent CMD to return immediately after it starts an external command or program. But MYUTIL.EXE is also a CLI program, you could try. Else your program just has to wait for the file being created.
Jos
|
|
|
Post by David Martin on Oct 14, 2019 14:13:59 GMT 1
Yes, I realize FoxPro doesn't wait for CMD to finish but returns immediately.
There is a loop in the code that waits for up to 10 seconds or when it sees the file and then continues ... when running under vDOS it goes right through this loop ... when in Windows 32 bit it usually takes a couple of loops before it goes by.
So either the file is created, which I can see it on disk in Windows Explorer, or the FoxPro WAIT command is not being honored and the loop is just blasting through 10 times before the file is created.
pLoop = 1 DO WHILE pLoop < 10 AND NOT FILE("OUTFILE.TXT") pLoop = pLoop + 1 WAIT "" NOWAIT TIMEOUT 1 && Pause for 1 second ENDDO
|
|
|
Post by David Martin on Oct 14, 2019 14:25:26 GMT 1
It has to do with the FoxPro WAIT command and how vDOS is handling it.
This doesn't work: WAIT "" NOWAIT TIMEOUT 1
but this does: WAIT " " NOWAIT TIMEOUT 1
Note the space that is being sent ... evidently vDOS needs the screen to be updated to perform the 1 second "pause".....
|
|
|
Post by Jos on Oct 14, 2019 14:29:49 GMT 1
It’s not as much that FoxPro doesn’t wait. After starting MYUTIL.EXE, CMD immediately returns control back to vDos, that then resumes executing FoxPro.
The "" versus " " thing must be something of FoxPro. vDos of course has no knowledge of what you’re attemting to accomplish.
Jos
|
|
|
Post by David Martin on Oct 14, 2019 14:40:59 GMT 1
Nope the WAIT "" NOWAIT TIMEOUT 1 definitely works under regular NTVDM ... it causes a 1 second pause with no screen update.
Even in the FoxPro command window you can see that the TIMEOUT parameter is not honored when running under vDOS unless something is included between the quotes ... and thereby updating the screen.
From within the FoxPro command window:
WAIT "" NOWAIT TIMEOUT 5 returns immediately when in vDOS but pauses for 5 seconds when under NTVDM
WAIT " " NOWAIT TIMEOUT 5 pauses for 5 seconds under both but a space character is written to the screen.
Not a huge problem but figured I would put it up here for documentation purposes if anyone else runs into a similar situation.
|
|
|
Post by Jos on Oct 14, 2019 17:36:25 GMT 1
Strange, I tried both with NTVDM (Windows 7-32), and got the same results as in vDos (no waiting with "").
Jos
|
|
|
Post by David Martin on Oct 15, 2019 11:35:30 GMT 1
That is strange ... I will take a closer look sometime ...
|
|