-
Type:
Story
-
Status: Open (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Component/s: workflow-durable-task-step-plugin
-
Similar Issues:
As a Jenkins user, I'll like to use sh semantics to execute commands with args.
I believe Jenkins needs an args: parameter for the sh pipeline step, right now we have script:, returnStdout: and returnStatus: both useful to avoid messing around with shell redirection. However, is clearly impossible or at least difficult to have clean (and secure) executions with sh if they involve string interpolations, maybe Jenkins should do this automatically, but I'm not sure if that kind of magic could be counter productive, I rather depend on args.
Like:
sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def])
or a new pipeline step to avoid overloading sh with different behaviour
command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def])
On both cases echo the program, not the shell built-in should be executed, Jenkins should look for the program on the system's $PATH / %PATH% but also an absolute path should be supported too, like a regular Groovy execute() on a List.
["/bin/echo", "foo", "bar"].execute()
Is not common to have Groovy's execute() allowed on Jenkins sandboxed environment, probably for very good reasons.
Also even if execute() is allowed on the Jenkins sandbox, sh semantics are way more convenient.
For reference:
def proc = ['ls', '/meh'].execute() println proc.getText() println proc.exitValue() != 0
Where is stderr?
- is duplicated by
-
JENKINS-44991 Add cross-platform command step
-
- Resolved
-
- relates to
-
JENKINS-26169 Workflow support for XShell plugin
-
- Open
-
Michael Slattery That isn't sufficient for all cases, alas.
It will work for pure ascii (I think). Depending on the locale, there are many other things that'll cause problems.
That's why I use withEnv(){ ... } as a work around until we can pass an array to {{sh.}}