Add !execwait Macro

[tajmone]

In some edge cases, when chaining up multiple !exec calls to external tools, an !exec call macro won't work unless the previous !exec task has finished (if accessing the same file, the previously called tool might still have a blocking handle on the file; if generating file contents/temporary files, the file might not be ready for consumption).

For this reason, it would be good to have an !exec variant that will not carry on parsing the document until the invoked task has exited — possible name: !execwait

If this new macro could also capture (cross platform) the exit code of the invoked command in !exitcode (read only built-in symbol) it would great.

Of course, all this could be achived via scripts, but when dealing with lots of small tasks it would be handier to have a built-in solution, and in some cases it might easen cross-platform macros.

[CDSoft]

This looks like a Windows' feature. Some I/O in Windows are delayed to be faster. The problem is that you don't know when they will actually be performed.

What should execwait wait for? pp does not know about the resources used by external scripts. pp just ensures that scripts are run in order. exec (as well as other macros) are blocking. Parsing will continue only after it has completed. The problem is that Windows does delay some operations after terminating the process.

On a Windows project (in a previous life I want to forget ;-) we had to wait for a directory to disappear after having deleted it. The only solution we found was to loop until the directory does not exist.

I'm afraid pp won't fix Windows bugs (Windows is the first bug logged in the Ubuntu's bug tracker, and they have announced it has been fixed ;-)

https://bugs.launchpad.net/ubuntu/+bug/1

[tajmone]

On a Windows project (in a previous life I want to forget ;-) we had to wait for a directory to disappear after having deleted it. The only solution we found was to loop until the directory does not exist.

... this is exactly the situation I'm facing (with files, not folders). And it's not the first time either that some project bumps into simlar disk delay problems (I remember that with big folders trees it's much worste).

The only solution that comes to my mind then, is to use some external script/tool capable of performing these loop checks to ensure the previous task was accomplished, and maybe to build a queu of the various !exec tasks to ensure they are carried out in the right order and at the right conditions.

Probably a tool like this already exists since this is both a common an old problem.

The problem is that Windows does delay some operations after terminating the process.

I have some vague rememberance that the WinAPI offers some options (like cache flushing, etc) to bypass the caching system (somehow, if not altogether) to avoid similar pitfalls. But maybe in this case it's left up to the CMD context to handle it once the command is invoked...

[CDSoft]

maybe to build a queu of the various !exec tasks to ensure they are carried out in the right order

They are already executed in the right order. pp is single threaded, IO actions are ordered and blocking in Haskell. You actually need something in between to check that Windows I/O are performed before continuing (e.g. when you create or delete a file, wait that the file is created or deleted before continuing). pp or external tools won't be aware of anything. Unless there is a way to flush Windows???

I thing we can close this issue for the moment.