Allow (command line) arguments to be passed to ToolDef scripts

I often want to run the same ToolDef script, but with subtle changes, for instance a number in the range [1..10]. Then I have multiple options:

• Create 10 ToolDef scripts that vary only slightly, leading to a lot of duplication.
• Create one general ToolDef script with a tool definition, and 10 ToolDef scripts that import that first script and invoke the defined tool with different arguments. While the duplication is then avoid, the 10 scripts essentially do nothing but invoke a tool from the other ToolDef script with different arguments. Allowing to pass arguments to the ToolDef script itself, would remove the need to create the 10 scripts. In practice, I yesterday had 2000+ such scripts. While I generated them, I still needed to upload all of them via FTP to a cluster, to run them. Not very ideal. Note that we could still use the old approach, as we just add new functionality.

It would require:

• Changes to the defined options:
  • The tooldef tool already allows passing multiple arguments, as do Linux shells and Windows command prompt.
  • Multiple arguments can thus already be provided. However, besides option arguments to configure the ToolDef execution itself, only a single non-option argument is currently allowed by the defined options (due to the use of InputFileOption).
  • I think we can just allow multiple non-option arguments. The first is then the ToolDef script, the remaining ones are the arguments.
  • We'll need an alternative to InputFileOption. FilesOption is technically suitable, but its option description is not very suited. I think we need a specialized ToolDefArgumentsOption for this. It would also provide a suitable GUI for the option to be easily configured.
  • It will be tricky (impossible?) to send arguments to the ToolDef script that start with - or -- as these will be interpreted as options for the ToolDef interpreter. Potential solutions include:
    • Some form of escaping?
    • A -- option that stops following arguments from being interpreted as ToolDef interpreter arguments and just makes them script arguments.
• Changes to the ToolDef interpreter (ToolDefInterpreter.execute) to allow passing the arguments. Similarly to the scriptpath, it could set the arguments in properties. Then they are also logged in crash reports.
• A way to read the arguments in ToolDef scripts:
  • I propose to add a new built-in tool named scriptargs, with signature list string scriptargs(). It returns the script arguments as a list of strings, one string per argument.
  • The list of arguments can be used as any list of strings, using size(scriptargs()) to get the number of arguments, scriptargs()[0] to get the first argument, etc.
  • The tool can be implemented by just querying the properties set by ToolDefInterpreter.execute and returning these in a ToolDefList of Strings.
  • This will be a backwards-incompatible change for all scripts that already use scriptargs as an identifier. Those scripts would have to change the identifier, or prefix it with $. I propose scriptargs rather than just args to reduce the likelihood of such backwards-incompatibility to occur.