I get that, but what happens when Ketarin can't access the relevant triggers (e.g. hash data, etc.) because it can't resolve a directory or URL due to "old" data?
The first time I encountered this execution order problem was because of the "download location" field.
Every application profile I have is built off a template that shares the same basic download location:
For Microsoft OneDrive, it resolves to:
This generic download location is software depot for an IT department and some installers have a deployment script wrapped around it. When this occurs, it requires the downloaded file to live in a nested folder. In order for Ketarin to place the download in the correct folder, a normally blank variable is assigned a value of "Files\" to adjust the location.
So another piece of software, like SONY Catalyst Browse is resolved to:
Who the heck wants to manually keep track of a variable that determines it's download location from a template on hundreds of application profiles? I don't, so I wrote a script to detect the "Files\" folder and dynamically adjust the download path before it's executed.
This is where the problem lies. Ketarin's timing of "Execute the following command before downloading" occurs after its already resolved the download location it's going to use, despite those value changing "before downloading".
While this is not the scenario that led me to start this post, I think it's enough of an example to get the point across.