Naming Parameter name similar to a unix command (seen with 'unzip') fails Shell Script Block using the command

Community
1

Hello Community!

Faced a potential Bug where using a Named Parameter with name shared by a Unix command (I’ve faced it with unzip) fails the actual ‘unzip’ command with weird outputs. (Clueless to why the behavior is such).

Since i’m new here, im also unaware on the procedure to Submit a Bug, thus welcoming you to this topic.

This was rather easy to replicate, and occurs each time.
Example:
Expected error when zip file is not present

image
image846×65 2.01 KB

Here the file is present, and the error is that parameter value is being taken as filename (First argument to unzip is interchanged with UNZIP’s parameter value)

Script:

properties([
    parameters([
        string(defaultValue: 'thisisbreaking', 
                  description: 'Test Paramter', 
                  name: 'UNZIP', trim: true)
    ])
])    
node('agent_name') {
    dir('/tmp/folder') {
        sh 'unzip thisisazipfile.zip'
    }
}

Output:
[Pipeline] Start of Pipeline
[Pipeline] node
Running on Node in workspace path
[Pipeline] {
[Pipeline] dir
Running in /tmp/folder
[Pipeline] {
[Pipeline] sh
ls -la
total 348
drwxrwxrwx 2 user user 4096 Jan 16 16:27 .
drwxrwxrwt 23 root root 344064 Jan 16 16:30 …
-rw-rw-r-- 1 user user 172 Jan 16 16:10 thisisazipfile.zip
unzip thisisazipfile.zip
unzip: cannot find or open thisisbreaking, thisisbreaking.zip or thisisbreaking.ZIP.
[Pipeline] }
[Pipeline] // dir
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: script returned exit code 9
Finished: FAILURE

Any help or direction to raise this as a Bug would be welcome :slight_smile:

Temporary fix is to not use ‘UNZIP’ as a parameter name.

2

The Unix unzip command reads the environment variable UNZIP as command line arguments. See the output of man unzip on your computer for more details.

3

Thanks for the reply @MarkEWaite !

I also had a look at Pipeline Syntax and realized all parameters are exported as env variables.

I assume this behavior was introduced recently as we had the same script running in earlier version of Jenkins without this interaction.

To summarize, is it correct to say never name parameters same as any env var and unix keywords in general?

4

As far as I know, that has been the behavior for Jenkins job parameters since the very early days of Jenkins. It is the behavior for parameterized freestyle jobs and for parameterized matrix jobs and for parameterized Pipeline jobs. Without that behavior, it is very difficult to pass the values of parameters to shell steps, batch steps, and powershell steps.

It is good to not name a parameter the same as an existing environment variable. Naming a parameter the same as an existing environment variable (like PATH) is generally a bad idea because it will confuse users of the job when the value of the existing environment variable is replaced.

It is rarely a problem to name a parameter the same as an existing Unix command or even to name it as the upper case form of an existing Unix command. The unzip command is rather distinct in its technique of accepting command line arguments through an environment variable named UNZIP. There may be other Unix commands that use the same technique, but I’m not aware of any.

5

Got it! Thanks for the clarification!