Details

    • Similar Issues:

      Description

      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?

        Attachments

          Issue Links

            Activity

            andresvia Andres V created issue -
            andresvia Andres V made changes -
            Field Original Value New Value
            Description 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}} step command, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. 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:
            {code:java}
            sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            or a new pipeline step to avoid overloading {{sh}} with different behaviour
            {code:java}
            command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            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.
            {code:java}
            ["/bin/echo", "foo", "bar"].execute(){code}
            Is not common to have Groovy's {{execute()}} allowed on Jenkins sandboxed environment, probably for very good reasons.

            Also even {{execute()}} is allowed on the Jenkins sandbox, {{sh}} semantics are way more convenient.

            For reference:
            {code:java}
            def proc = ['ls', '/meh'].execute()
            println proc.getText()
            println proc.exitValue() != 0{code}
            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}} step command, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. 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:
            {code:java}
            sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            or a new pipeline step to avoid overloading {{sh}} with different behaviour
            {code:java}
            command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            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.
            {code:java}
            ["/bin/echo", "foo", "bar"].execute(){code}
            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:
            {code:java}
            def proc = ['ls', '/meh'].execute()
            println proc.getText()
            println proc.exitValue() != 0{code}
            andresvia Andres V made changes -
            Description 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}} step command, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. 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:
            {code:java}
            sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            or a new pipeline step to avoid overloading {{sh}} with different behaviour
            {code:java}
            command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            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.
            {code:java}
            ["/bin/echo", "foo", "bar"].execute(){code}
            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:
            {code:java}
            def proc = ['ls', '/meh'].execute()
            println proc.getText()
            println proc.exitValue() != 0{code}
            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}} step command, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. 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:
            {code:java}
            sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            or a new pipeline step to avoid overloading {{sh}} with different behaviour
            {code:java}
            command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            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.
            {code:java}
            ["/bin/echo", "foo", "bar"].execute(){code}
            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:
            {code:java}
            def proc = ['ls', '/meh'].execute()
            println proc.getText()
            println proc.exitValue() != 0{code}
            Where is `stderr`?
            andresvia Andres V made changes -
            Description 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}} step command, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. 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:
            {code:java}
            sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            or a new pipeline step to avoid overloading {{sh}} with different behaviour
            {code:java}
            command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            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.
            {code:java}
            ["/bin/echo", "foo", "bar"].execute(){code}
            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:
            {code:java}
            def proc = ['ls', '/meh'].execute()
            println proc.getText()
            println proc.exitValue() != 0{code}
            Where is `stderr`?
            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}} step command, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. 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:
            {code:java}
            sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            or a new pipeline step to avoid overloading {{sh}} with different behaviour
            {code:java}
            command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            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.
            {code:java}
            ["/bin/echo", "foo", "bar"].execute(){code}
            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:
            {code:java}
            def proc = ['ls', '/meh'].execute()
            println proc.getText()
            println proc.exitValue() != 0{code}
            Where is {{stderr}}?
            andresvia Andres V made changes -
            Description 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}} step command, right now we have {{script:}}, {{returnStdout:}} and {{returnStatus:}} both useful to avoid messing with the {{FileSystem}}. 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:
            {code:java}
            sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            or a new pipeline step to avoid overloading {{sh}} with different behaviour
            {code:java}
            command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            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.
            {code:java}
            ["/bin/echo", "foo", "bar"].execute(){code}
            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:
            {code:java}
            def proc = ['ls', '/meh'].execute()
            println proc.getText()
            println proc.exitValue() != 0{code}
            Where is {{stderr}}?
            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 with the {{FileSystem}}. 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:
            {code:java}
            sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            or a new pipeline step to avoid overloading {{sh}} with different behaviour
            {code:java}
            command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            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.
            {code:java}
            ["/bin/echo", "foo", "bar"].execute(){code}
            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:
            {code:java}
            def proc = ['ls', '/meh'].execute()
            println proc.getText()
            println proc.exitValue() != 0{code}
            Where is {{stderr}}?
            andresvia Andres V made changes -
            Description 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 with the {{FileSystem}}. 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:
            {code:java}
            sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            or a new pipeline step to avoid overloading {{sh}} with different behaviour
            {code:java}
            command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            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.
            {code:java}
            ["/bin/echo", "foo", "bar"].execute(){code}
            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:
            {code:java}
            def proc = ['ls', '/meh'].execute()
            println proc.getText()
            println proc.exitValue() != 0{code}
            Where is {{stderr}}?
            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:
            {code:java}
            sh(script: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            or a new pipeline step to avoid overloading {{sh}} with different behaviour
            {code:java}
            command(name: "echo", args: ["hello", "world", env.MY_ENV, my_other_def]){code}
            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.
            {code:java}
            ["/bin/echo", "foo", "bar"].execute(){code}
            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:
            {code:java}
            def proc = ['ls', '/meh'].execute()
            println proc.getText()
            println proc.exitValue() != 0{code}
            Where is {{stderr}}?
            jglick Jesse Glick made changes -
            Component/s workflow-durable-task-step-plugin [ 21715 ]
            Component/s workflow-basic-steps-plugin [ 21712 ]
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-26169 [ JENKINS-26169 ]
            jglick Jesse Glick made changes -
            Link This issue is duplicated by JENKINS-44991 [ JENKINS-44991 ]

              People

              • Assignee:
                Unassigned
                Reporter:
                andresvia Andres V
              • Votes:
                13 Vote for this issue
                Watchers:
                17 Start watching this issue

                Dates

                • Created:
                  Updated: