Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-53479

sh[ell] task silently drops critical quoting

    Details

    • Similar Issues:

      Attachments

        Activity

        Hide
        rudolfwg Rudolf-Walter Kiss-Szakacs added a comment - - edited

        @Andrew Pennebaker: Works as expected.
        The quotes are not dropped by anything in Jenkins. They are interpreted by your shell. Try running some of those commands in bash manually, and you'll see the same behaviour. That is, 

        echo a
        

        and

        echo "a"
        

        will both output the single character a. When you see the shell command being run in the log (the lines that begin with a +), it is not Jenkins showing it to you before sending it to the shell; rather, it is the shell itself echoing it back, as started with the -x (aka -o xtrace) flag.

        The backslashes on the other hand are being processed by both Jenkins and the shell. That is, when you write \\\\\\\" as you show in your gist, Jenkins eats one set of escapes, and sends \\\" to the shell; then the shell does one more round, sending a literal \" to echo.

        Note, however, that you almost never want this, most executables do not expect literal quotes in their parameters – those are for the shell.

        You can easily test that things are working as intended with a shell script that lists its parameters line-by-line:

        #!/bin/bash
        echo "Got $# args:"
        while [ $# -gt 0 ]; do
            echo "$1"
            shift
        done
        echo
        

        Save this as something like printargs.sh and then replace every echo in your example with it.

        Oh, and replace $BUILD_NUMBER with some variable that has spaces in its value, eg:

        node {
            withEnv(['FOO=a b c']) {
                sh 'printargs.sh $FOO'
                sh 'printargs.sh "$FOO"'
            }
        }
        
        Show
        rudolfwg Rudolf-Walter Kiss-Szakacs added a comment - - edited @ Andrew Pennebaker : Works as expected. The quotes are not dropped by anything in Jenkins. They are interpreted by your shell. Try running some of those commands in bash manually, and you'll see the same behaviour. That is,  echo a and echo  "a" will both output the single character a . When you see the shell command being run in the log (the lines that begin with a + ), it is not Jenkins showing it to you before sending it to the shell; rather, it is the shell itself echoing it back, as started with the -x (aka -o xtrace ) flag. The backslashes on the other hand are being processed by both Jenkins and the shell. That is, when you write \\\\\\\" as you show in your gist, Jenkins eats one set of escapes, and sends \\\" to the shell; then the shell does one more round, sending a literal \" to echo. Note, however, that you almost never want this, most executables do not expect literal quotes in their parameters – those are for the shell. You can easily test that things are working as intended with a shell script that lists its parameters line-by-line: #!/bin/bash echo "Got $# args:" while [ $# -gt 0 ]; do echo "$1" shift done echo Save this as something like printargs.sh and then replace every echo in your example with it. Oh, and replace $BUILD_NUMBER with some variable that has spaces in its value, eg: node { withEnv([ 'FOO=a b c' ]) { sh 'printargs.sh $FOO' sh 'printargs.sh "$FOO" ' } }

          People

          • Assignee:
            rudolfwg Rudolf-Walter Kiss-Szakacs
            Reporter:
            mcandre Andrew Pennebaker
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: