It’s worth noting that, when the commands aren’t called with arguments, the shell syntax seen in the two print-* commands is fully supported; in fact, commands can be full scripts, including (in Bash terms) simple commands, pipelines, lists, compound commands, and function definitions (and I’ve also been able to make good use of this in T320140, so I’d like to keep it this way). In light of this, I feel like the model of print-shell-arguments-per-line would be more suitable than the one of print-appended-arguments-per-line, if we have a choice: make the arguments (if any) available as "$@", to be used anywhere in the command, instead of just appending them at the end. (But of course that breaks compatibility with trivial commands as they currently work. And if you really need to use "$@" in non-terminal position, you can always wrap your command like myfun() { some-command "$@" other-argumests; }; myfun, assuming function definitions continue to work.)

(Note: At the moment T320140 isn’t actually blocked on this, as I’m using Kubernetes directly. If I move to Toolforge Jobs, and the jobs are limited to the Procfile commands, then this would become more of an issue.)

In T356016#9539392, @LucasWerkmeister wrote:

(Note: At the moment T320140 isn’t actually blocked on this, as I’m using Kubernetes directly. If I move to Toolforge Jobs, and the jobs are limited to the Procfile commands, then this would become more of an issue.)

Thanks for the note, I'll try to prioritize looking into this, I do suspect though that there might be some limitation on how the launcher process parses arguments, have to read https://github.com/buildpacks/spec/blob/main/platform.md#launcher in detail.

I think that the issue comes from the procfile buildpack, it's generating a metadata.toml file with processes like:

[[processes]]
  type = "inline-param"
  command = "./test.sh inline-param"
  args = []
  direct = false
  buildpack-id = "heroku/procfile"

[[processes]]
  type = "no-params"
  command = "./test.sh"
  args = []
  direct = false
  buildpack-id = "heroku/procfile"

[[processes]]
  type = "shell-params"
  command = "./test.sh \"$@\""
  args = []
  direct = false
  buildpack-id = "heroku/procfile"

[[processes]]
  type = "split-shell-params"
  command = "./test.sh \"$1\" \"$2\""
  args = []
  direct = false
  buildpack-id = "heroku/procfile"

[[processes]]
  type = "web"
  command = "uwsgi uwsgi.ini"
  args = []
  direct = false
  buildpack-id = "heroku/procfile"

And I suspect that instead of having a command with everything, it should have moved the arguments to args, looking

It's actually quite tricky, and upstream might take a bit to fix it: https://github.com/heroku/procfile-cnb/issues/151

So, to clarify myself, current behavior is:

• If no parameters are passed to the binary created from the Procfile (/cnb/process/<procfile-entry>), it will wrap the command in a shell (bash -c) and pass to it the command as one parameter.
• If you pass any other parameters, it will not wrap the command in a shell, but instead, try to execute it as one binary (thus, not finding it if it it has any parameters defined), and will pass the extra args the user passed to the binary.

So, besides pushing that upstream task or re-implementing the buildpack ourselves, we can work around the issue by createing a wrapper script, like:

#!/bin/bash
## run-cron.sh

mycommand hardcoddedarg "$@"

And a Procfile entry like (note that we are not passing any arguments at all):

run-cron: ./run-cron.sh

This allows passing extra args (and other more advanced patterns if needed).

@LucasWerkmeister I have updated the docs here https://wikitech.wikimedia.org/wiki/Help:Toolforge/Build_Service#Example%3A_Python_web_service, with the script workaround, we can leave this task open until upstream fixes the issue, but might take a while, so I'd recommend using the workaround for now.