[JENKINS-28996] Environment variable name created from File Parameter → File Location contains the "directory name portion" though stated differently in its inline help

[timja]

The title says it. Since I don't like to repeat myself please have a look at my answer to "How to trigger downstream jenkins job with File parameter as parameter?" at StackOverflow.

Suggested actions:

• Don't add the path name portion, according to what's stated in the inline help
• Revise the inline help:
  • Don't state a file with an extension (abc.zip at the time of this writing) as an example
  • Add a note that strongly recommends to only use characters in File Location's file name that are officially supported for environment variable names by the OS Jenkins or its slaves are currently running on

---

Originally reported by geri, imported from: Environment variable name created from File Parameter → File Location contains the "directory name portion" though stated differently in its inline help

• status: Open
• priority: Major
• resolution: Unresolved
• imported: 2022/01/10

[timja]

danielbeck:

Don't add the path name portion, according to what's stated in the inline help

Breaking change. so I'd rather just fix the docs. Having the full path as specified in the parameter should be more useful anyway.

[timja]

geri:

@danielbeck

Having the full path as specified in the parameter should be more useful anyway.

Did you follow the link to the answer I gave on SO? Have you seen the link to IEEE Std 1003.1, 2013 Edition there?

Environment variable names used by the utilities in the Shell and Utilities volume of POSIX.1-2008 consist solely of uppercase letters, digits, and the ( '_' ) [...]

I agree that a path in the File Location parameter is useful (to store the uploaed file there rather than in the workspace).

I disagree in having '.' or '/' (or ':' or '\', I didn't test this with Windows) in the resulting variable name since this is against the standard implemented in OSs largely spread worldwide.

[timja]

danielbeck:

We should find out whether the current implementation can be used by anyone while using sub directories. Not everything is POSIX, and not everything is a shell either, and only then these restrictions seem to apply. As a cross-platform tool, Jenkins should aim for the lowest common denominator only where necessary IMO.

Right now, it just means there's an unusable environment variable, and only if the job is configured by the user in a specific a way. Looks to me like minor loss of functionality with easy workaround present.