Proposal to update run:shell:arguments definition

[JBBianchi]

Hello, dear community,

I'd like to bring up a small concern regarding the definition of run:shell.

Currently, the arguments property is defined as a map:

arguments	map	no	A list of the arguments of the shell command to run

While this structure makes sense for run:script, where arguments represent a set of variables and their values, shell command arguments are typically an array, not a key-value map.

To align with common usage and improve clarity, I propose updating the documentation and schema for run:shell:arguments to use an array instead of a map. Additionally, the documentation for run:script:arguments should be adjusted, as it currently describes the property as:

"A list of the arguments, if any, of the script to run"

This should be corrected to:

"An arguments' map, if any, of the script to run"

I’d love to hear your thoughts on this! Would this be an acceptable improvement to better reflect expected behavior?

Looking forward to your feedback!

[cdavernas]

@JBBianchi You are perfectly right! While this was intended to simplify expressions for named arguments, this obviously does not work for un-named arguments and flags. Your proposal therefore makes asbolute sense.

I would, however, delay your proposal until we finally addressed the many problems inherent to the shell task, such as:

• How can we enforce consistency of shell commands accross platforms/runtimes (i.e. win vs linux)?
• Where are shell commands run when using a FaaS or container based runtime?
  ...

[hirenr]

I am currently doing it like so, and it seems more in line with run.script and run.container too.

Workflow Spec

shell:
        command: wget -q -O- $URL
        arguments:
          URL: 'http://ifconfig.io/'

and it outputs a multiline script like so in the runtime... which I then execute (I use a container as the default choice for my runtime)!!

#!/bin/sh
URL=http://ifconfig.io/
wget -q -O- $URL

this seems very intuitive to me!!

Alternatively, instead of having a separate arguments and command in the shell spec, we could just make command as a string array!

[ricardozanini]

@JBBianchi +1.

Also alignes with k8s API pretty nicely: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#define-a-command-and-arguments-when-you-create-a-pod

apiVersion: v1
kind: Pod
metadata:
  name: command-demo
  labels:
    purpose: demonstrate-command
spec:
  containers:
  - name: command-demo-container
    image: debian
    command: ["printenv"]
    args: ["HOSTNAME", "KUBERNETES_PORT"]
  restartPolicy: OnFailure

[geomagilles]

Hello, I just finished the implementation of run script and run shell for Lemline. IMHO having a list of String makes more sense as this is what I use eventually : "command arg1 arg2 arg3" As @hirenr pointed out, it could also be a single expression.

But the initial post says "this structure makes sense for run:script" - I do not understand why actually, as in my implementation arguments end up as a list of string as well. My understanding is that the documentation is a bit too vague to explicit if those arguments are actually... arguments to handle in the code (in that cases it should be a list) or variables in the code (in that case it should be a map, but the name may need to change)

[hirenr]

Hi, I just pushed a PR that addresses this among a larger rationalisation for run:* tasks.

#1129

• Introduced stdin for run:shell/script/container
• args now a string array (sent as argv to script)