When you run a command like ssh user@host COMMAND..., SSH doesn't do any particular escaping of COMMAND (https://unix.stackexchange.com/q/397400/226269). If you run echo foo \> bar, you will see the output foo > bar, but if you run ssh user@host echo foo \> bar, you'll end up writing foo to a file called bar on the remote.
This affects configurations which use the submit_host setting: if an argument contains a character with special meaning like >, e.g. in an LSF resource request like -Rselect[mem>4000], the argument will get mangled and the job won't be submitted properly.
As a workaround, you can .shellescape everything you use as a native argument in submit.yml.erb, but that means the app will no longer work properly in configurations that aren't using submit_host.
When you run a command like
ssh user@host COMMAND..., SSH doesn't do any particular escaping ofCOMMAND(https://unix.stackexchange.com/q/397400/226269). If you runecho foo \> bar, you will see the outputfoo > bar, but if you runssh user@host echo foo \> bar, you'll end up writingfooto a file calledbaron the remote.This affects configurations which use the
submit_hostsetting: if an argument contains a character with special meaning like>, e.g. in an LSF resource request like-Rselect[mem>4000], the argument will get mangled and the job won't be submitted properly.As a workaround, you can
.shellescapeeverything you use as anativeargument insubmit.yml.erb, but that means the app will no longer work properly in configurations that aren't usingsubmit_host.