Quote:
Regarding the chmod examples in previous post, these all still function as described in that post.
I tested some other commands as well and everything so far seemed to function correctly, other than those impacted by the %f handing/etc (re chmod examples)
|
After reviewing all my of recent changes I discovered a mistake where a variable was passed by reference to a sub-routine and modified; when should of been passed by value so that the original value outside of the sub-routine was preserved.
This mistake resulted in only some of the selected items being evaluated when the %f token was used.
As you discovered using the /enqueue command within a command block results in all of the following commands within the block being enqueued as well, I'm fairly sure that this was not the intended behavior but the /enqueue command is somewhat mysterious. It was originally added so that the user could add operations to the queue via the raw command line and then review the result to verify the output is as expected.
From another post I found this example
Code:
/enqueue /ren "%p%f" "%p$replacerx("%f", "^([0-9]+[\s][-]) (.*)\.(.*)$","\2.\3")"
I found a race condition in the hash related commands (/checksfv, /crc32../sha512, etc) that perform threaded operations.
There was also a problem that caused loading commands from within groups to sometimes fail [\group\sub-group\command] depending on the order and layout of the command groups.
Here's the latest revision with all my current fixes
ffxp5.0.0.3805-r5.zip
I think the only issue remaining is that the command progress counter might be wrong under some conditions.
Threaded Mode