Launcher doesn't run batch commands when given an oddly-structured set of CLI arguments

[mvousden]

@heliosfa ran: ./orchestrate.sh /b="/home/gmb/Orchestrator/call_file_plate.poets on the softswitch_addresses branch last week. The Orchestrator started, but no commands were run (an empty CLI dump was written to stdout).

The first thing to try is probably compiling the launcher in debug mode, setting a breakpoint in rootmain, and seeing what happens.

@heliosfa, for posterity, can you upload a plate script that causes this behaviour to occur?

[mvousden]

I missed this at first, but you (the user) has got to have a space around your = character, i.e. ./orchestrate.sh /b = "/home/gmb/Orchestrator/call_file_plate.poets" (to stop the CLI class use from falling over).

Happy to resolve and relabel this?

[heliosfa]

How easy would it be to throw a warning if it is presented with an = without space? I'm assuming by falling over, you mean it returns with an error code?

Given that you and I missed this, it is not going to be very user-friendly without some sort of feedback...

[mvousden]

After a bit more thought, one way of resolving this is through the Bash layer:

--- a/Build/gcc/Resources/orchestrate_template.sh
+++ b/Build/gcc/Resources/orchestrate_template.sh
@@ -60,11 +60,16 @@ while [ $# -gt 0 ]; do
     case "$1" in
         /*) # Windows
             THIS_ARG_MODE="Windows"  # i.e. not GNU.
-            SWITCH="$1"
-            if [ "$2" == "=" ]; then  # e.g. "/f = FILE"
+            if [[ "$1" =~ /[a-z]=* ]]; then  # e.g. "/f=FILE"
+                SWITCH="${1:0:2}"
+                VALUE="${1:3}"
+                shift;
+            elif [ "$2" == "=" ]; then  # e.g. "/f = FILE"
+                SWITCH="$1"
                 VALUE="$3"
                 shift; shift; shift
             else  # e.g. "/d"
+                SWITCH="$1"
                 shift;
             fi
             ;;

This addresses the most common route into the Orchestrator that people would use. Modifying CLI to do this (or even to introduce a warning) is a fair amount of trouble. This addresses the case you've posted in the issue, as well as the case where the path is unquoted. Are you happy with this?

[heliosfa]

It makes sense to do it in the sh honestly as that is where the argument is first passed in - may as well fail/warn fast.