Wasn't expecting that: made another release of FileSieve yesterday.

For no particular reason at all, a thought about the way FileSieve handles the Start automation command popped into my head while I was doing something completely unrelated.

I had a feeling of dread. I wasn't sure why, but it was there. Something was... wrong.

When my conscious mind caught up with the sub-conscious, it occurred to me: profile processing (which is what Start begins the process of but via the command-line) is threaded and consequently doesn't block the main thread. I didn't add any code to wait for that processing to exit; I just carry on with executing the remaining commands that were passed in via the command-line.

An enormous oversight as this means FileSieve is merrily executing commands while a profile is being processed, copying files and all sorts of stuff, while possibly nobbing things up left and right.

Loaded the code and then wondered how I was going to solve this. I forewent any semaphore or signalling as I wanted to get this update done and released ASAP. Instead, I made all automation commands asynchronous and then, in simple terms, busy-waited until it was complete.

I'm cheeky, me!

While I was in there, I decided to add support for allowing automation via an external file. FileSieve parses the file and then runs the encountered commands as though they were passed in via the command-line; lovely, lovely, code reuse.

As the file reading code is custom just for that task, I thought I'd allow line comments; any line that starts with a hash # character is ignored. Incidentally, all lines are trimmed of spaces.

Commands and their values can be spaced out however you want as, again, trimming is done before the fields are interpreted. As well as providing general flexibility in the syntax, it also avoids the commands/values looking all squashed together.

If the autofile is just feeding commands from the file into the command-line parser, does that mean... recursion? Yes, yes it does! If an Autofile command is encountered within an autofile, then that file is then parsed. Allowing this to continue unabated is obviously not a good idea as eventually a StackOverflowException is thrown - turns out at about 1,000 levels deep! No idea why I always thought stack overflows occurred at around 8 iterations. Maybe due to the contents of the stack / frame sizes.