Custom command improvement/discussion

[bigstar]

Thank you for your feedback.

I attempted to reply to you several times today but each time I tried to write an example and show you some references I ran into some unexpected issues.

There are some problems with the order in which the scripts are being executed.

Ironically most of these problems seem to originate back to a single problem I tried to resolve awhile back where the order of the files in %f was reversed, it would appear that my fix and then additional fixes and changes have opened a huge can of worms.

I use a multi-stage partially recursive parsing and processing engine and it appears that somewhere along the lines I've overly complicated things because nothing works as expected.

I've spent most of the day trying to work things out but every time I fix one issue it introduces a new problem or changes the behavior in a way that may cause existing scripts to malfunction, though at this point I'm not entirely sure whats working correctly and what's not. I am pretty sure that I'll be rolling back all of my changes from today and starting fresh tomorrow.

To quickly answer some of your questions, yes when you use tokens such as %f in a command that command becomes a FOR-EACH LOOP or if the command is within a command block the entire command block becomes a FOR-EACH LOOP.

Chaining another command via [\sub\func] containing a command block can create its own FOR-EACH LOOP that is parsed within the sub context of the main loop but the the commands aren't actually executed until after the main FOR-EACH LOOP has been parsed. (If that makes any sense)

I have the following example that I was going to use to show you how things worked but at the moment it doesn't actually work as expected.

[WARNING - CODE DOESN'T WORK]

main function

/echo start
{
/cd %p%f
/selectall -f
[\sub\func1]
}
/clear cache %p
/cd %p
/echo end

sub function named "\sub\func1"

{
/move "%p%f" "../%f"
}
RMD %p

Below is a simplified output of the way the script should appear when run

[CMD] start
[CMD] /cd /base/sub1/
[CMD] /selectall -f
[CMD] \sub\func1
[CMD] /move "/base/sub1/sub1-file1.bin" "../sub1-file1.bin"
[CMD] /move "/base/sub1/sub1-file2.bin" "../sub1-file2.bin"
RMD /base/sub1/
[CMD] /cd /base/sub2
[CMD] /selectall -f
[CMD] \sub\func1
[CMD] /move "/base/sub1/sub2-file1.bin" "../sub2-file1.bin"
[CMD] /move "/base/sub1/sub2-file2.bin" "../sub2-file2.bin"
RMD /base/sub2/
[CMD] /clear cache /base/
[CMD] /cd /base/
[CMD] end

[DayCuts]

Testing with 3805-r3

1. Repeating Example 3 from previous posts... everything within the initial CMD seems to be performed in the correct order now, however tasks from sub command CMD2 still do not function in the expected order. Sub command raws and echos (not sure if other commands are affected or not) are still misplaced.

#CMD
/echo -- Enqueue A
/enqueue A
A
{
/cd %p%f
[CMD2]
}
/uncd

#CMD2
/echo -- Enqueue B
/enqueue B
B

#LOG
[18:15:53] [L] [CMD] -- Enqueue A
#A is correctly enqueued
[18:15:53] [L] A
[18:15:54] [L] 500 'A': Command not understood.
[18:15:54] [L] [CMD] /cd /tools/bin/TESTING
[18:15:54] [L] CWD /tools/bin/TESTING
[18:15:54] [L] 250 CWD command successful.
[18:15:54] [L] PWD
[18:15:54] [L] 257 "/tools/bin/TESTING" is current directory.
[18:15:54] [L] STAT -l
[18:15:55] [L] List Complete: 549 bytes in 0.86 seconds (0.5 KB/s)
[18:15:55] [L] [CMD] CMD2
#B is correctly enqueued
[18:15:55] [L] [CMD] /cd /tools/bin/TESTING2
[18:15:55] [L] CWD /tools/bin/TESTING2
[18:15:56] [L] 250 CWD command successful.
[18:15:56] [L] PWD
[18:15:56] [L] 257 "/tools/bin/TESTING2" is current directory.
[18:15:56] [L] STAT -l
[18:15:57] [L] List Complete: 201 bytes in 0.86 seconds (0.2 KB/s)
[18:15:57] [L] [CMD] CMD2
#B is correctly enqueued again
[18:15:57] [L] [CMD] /uncd
[18:15:57] [L] CWD /tools/bin
[18:15:57] [L] 250 CWD command successful.
[18:15:57] [L] PWD
[18:15:58] [L] 257 "/tools/bin" is current directory.
[18:15:58] [L] STAT -l
[18:15:58] [L] List Complete: 7,618 bytes in 0.87 seconds (7.4 KB/s)
#Misplaced echos and raw commands
[18:15:58] [L] [CMD] -- Enqueue B
[18:15:58] [L] B
[18:15:59] [L] 500 'B': Command not understood.
[18:15:59] [L] [CMD] -- Enqueue B
[18:15:59] [L] B
[18:15:59] [L] 500 'B': Command not understood.

Expected behavior...

/echo -- Enqueue A
/enqueue A
A
/cd /tools/bin/TESTING
/echo -- Enqueue B
/enqueue B
B
/cd /tools/bin/TESTING2
/echo -- Enqueue B
/enqueue B
B
/uncd

Previous build evaluated to...

/echo -- Enqueue A
/enqueue A
/cd /tools/bin/TESTING
/enqueue B
/cd /tools/bin/TESTING2
/enqueue B
/uncd
A
/echo -- Enqueue B
B
/echo -- Enqueue B
B

This build evaluated to...

/echo -- Enqueue A
/enqueue A
A
/cd /tools/bin/TESTING
/enqueue B
/cd /tools/bin/TESTING2
/enqueue B
/uncd
/echo -- Enqueue B
B
/echo -- Enqueue B
B

2. /delay does not function, seems to ignore the numeric parameter completely. It always starts a countdown of ~4294968 seconds (almost 50 days).

3. While doing a few tests I have noticed that command progress status bar updates are bugged somehow. In the above 'Example 3' the X value in X of Y is probably mostly incorrect due to the ordering issue with CMD2 (so it just appears odd). However the limited testing i was able to do shows that initial count for Y is also wrong in some cases. Take the following example... Y is evaluated to 5, /cd is shown as 1 of 5 and /uncd is shown as 4 of 5. I believe X is correct but the initial 5 value for Y is not. Perhaps counting the close group }?

{
/cd %p%f
/select -d rx: (?-i).*\.min
/queue selected
}
/uncd

4. When an enqueued command (eg /ren) encounters a problem (eg 550 on RNTO) is it intentional that the enqueued command queue entry still be removed rather than marked as failed?

I was unable to find any old commands that did not continue to perform as expected with this build. This includes the command i wrote that started all this discussion which continues to function correctly (since the sub command only contains one /enqueue line). Since sub command support is relatively new I think it is safe to assume very minimal if any custom commands created by people are likely to malfunction as a result of fixes here - also since the tasks most affected are those that people are unlikely to mistakenly put in the wrong place / rely on being in the wrong place.