Seems like timing issue

[oldsk3wl]

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?

Thanks for any advice.

[Jos]

What if you do:
RUN CMD WAIT /C "DIR \SOMEPATH\*.CSV /B > DOSDIR.TXT"

Jos

[oldsk3wl]

I tried adding the WAIT but it had no effect. I researched CMD for a wait option but found nothing documented.

I found an option on the RUN command in Foxpro that says it does a memory swap and flush. It had no effect.

I added a 0.1 second pause after the CMD and that works great. 1/10 sec is forever in CPU but not noticeable to users, so that works for me.

I do lots of CMD calls. When I run into this issue, I will add the pause. Great solution.

Thank as always, Jos, for the support.

[Jos]

You’re sure it doesn’t work?

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.

Jos

[oldsk3wl]

So sorry, Jos. I must have used lower case. It does work.

I did not realize WAIT was a vDos option. I also added the HIDE option, which makes it much cleaner. Thank you!

I am surprised that

RUN CMD WAIT HIDE /C "some command"

does not blow up in Foxpro. Foxpro would still be running the MS Comspec, right?  It must be ignoring the invalid options. Nice that I don't have to code two versions.

On to the next issue, whatever that might be

[Jos]

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.

Jos

[oldsk3wl]

When I am running Foxpro in NTVDM, ComSpec is set to C:\Windows\System32\cmd.exe dated 4/14/2008.

So when I do a "RUN CMD" in Foxpro, I would think it was running the original DOS cmd.exe

I just tried "CMD WAIT RUN /K DIR" on a machine that does not have vDos installed and it executed the directory and showed no errors. All good.

PS. Do you ever sleep?

[Jos]

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.

I sleep a lot, we will have a time difference.

Jos

[oldsk3wl]

I have encountered a couple places where I need different code for vDos and NTVDM.

At the very top of the program I set a logical VDOS based on environment variables, then in these places I just code

IF VDOS

  RUN CMD vDos way

ELSE

  RUN CMD NTVDM way

ENDIF

Thought I would need to do that here, but CMD WAIT HIDE works in both systems. Thanks!