I issue a command to send the directory to a text file.
RUN CMD /C "DIR \SOMEPATH\*.CSV /B > DOSDIR.TXT"
which I know works great.
A few lines later I read the text file in to process it.
APPEND FROM DOSDIR.TXT DELIMITED
The program opens a dialog to tell me the file is not found.
I change nothing, but if I tell it to try again (forced pause) and it works fine.
It seems like I am trying to read it before the command processor has completely flushed its buffer or something.
Also - If I issue a CMD to run a bat to rename several files, then a CMD to read the directory of renamed files. The last file is not renamed. but it really is renamed in Windows. So I was able to read the directory before it was completely re-written.
I added a 1 second pause after each CMD invocation and it runs fine. What will happen on a new, faster CPU?
Is there something I am missing, don't know about command processor?
Is there some way to get vDos to wait until the CMD is truly complete?
I just now changed RUN CMD WAIT /C "DIR \SOMEPATH\*.CSV /B > DOSDIR.TXT" To RUN CMD WAIT /C "DIR d:\*.TXT /S /B > DOSDIR.TXT" Added the /S to get an actual delay with CMD (3,827 lines generated).
WAIT (and HIDE) are vDos, not CMD options, see Readme.pdf and FAQs.pdf. From FAQs.pdf: The optional WAIT and HIDE have to be in capitals. Mind, WAIT in combination with the Windows command processor has a major limitation: If that executes a command or program, it will exit immediately. While for instance the external program could still be running. The exit code will then merely indicate if the program could be started.
A trick to make CMD actually only quit as the command or program ended is to redirect its output. So that’s why your CMD WAIT /C "…> DOSDIR.TXT" should work. This goes equally well when redirecting to NUL, for instance CMD WAIT /C “batch.cmd>NUL”.
I already had a note to eventually automate that if CMD or START is used: Drop starting a second DOS command.com (like FoxPro’s RUN does), starting CMD. Drop capturing redirections, and pass that on to CMD. Add >NUL redirection if /C is used w/o explicit redirection. Perhaps more, though it should be all consistent and leave the possibility to do odd things.
If COMSPEC is set to C:\COMMAND.COM, a copy vDos’s command line processor will be started. The footprint in DOS memory is real small, a copy of the environment variables table, a PSP segment and 16 bytes of fake code. But it’s useless to create those since CMD run entirely outside the vDos box.
I expected RUN CMD WAIT /C "DIR d:\*.TXT /S /B > DOSDIR.TXT" would give an error if run in NTVDM. But it just does the job. If not, and you want the program to run under NTVDM and vDos, I would have suggested you use a batch file instead, or something like RUN CMD %VDOSWAIT% /C... Where VDOSWAIT would be defined under vDos (autoexec.txt), not under NTVDM.