https://www.gnu.org/software/bash/manual/html_node/Word-Splitting.html#Word-Splitting

So not being able to run any scripts in the working directory of any project with a space in the name is not a defect? I understand why this error occurs, but this does not change the fact that there is no way anybody is expecting the first half of their project name to be the end of one argument and the other part the start of another. That makes no sense.

Imagine if you created a document on google docs called "Test document" and then google drive was unable to open the document because there's a space in the name and look, it expands like this according to this page in the bash manual. I don't think anybody would doubt that it's clearly a bug and it clearly needs to be escaped.

I understand why this error occurs

To be honest, it does not look like you understand what's happening here. Your own script takes the shortcut of not quoting a parameter expansion, which enables word splitting in the first place, and then you call well-defined and documented behavior in Bash a bug in Jenkins (when Jenkins just executes whatever you tell it to). You just need to quote the variable reference so it won't be split into separate arguments.

I'm fairly sure there's no way to set a value of WORKSPACE that contains a space and will not be split when unquoted. So there is actually no way for Jenkins to "fix" this other than setting a non-default IFS beforehand (bad idea) or parsing and rewriting the script you enter (even worse).

While originally it was the issue creator's mistake to not take care of parameter expansion, there are use cases where those spaces in working directory name may break things buried deep inside third-party projects.

Currently I have a problem with Yocto Project. The working directory is to be specified along with other directories in a space-separated list called BBLAYERS. There is no way to escape spaces inside that list. That is, bitbake will always fail on directories containing spaces: it will either only see the first part of the name or choke on any escaping. It's beyond my power (and will) to fix that in bitbake. I would prefer jenkins to behave more like Atlassian Bamboo, which names working directories after project key (which by definition contains only alpha-numeric caracters and dashes), not the project name. Since jenkins doesn't use 'keys', I would expect it to replace any unsafe characters with something like underscores or (safer) to generate some hash from the project name and use it as a working directory name.

Please reconsider.

Still not a defect in Jenkins.

a space-separated list called BBLAYERS. There is no way to escape spaces inside that list.

This is a design bug and needs to be fixed in that other software (or conscious limitation in which care you're just out of luck).

behave more like Atlassian Bamboo, which names working directories after project key (which by definition contains only alpha-numeric caracters and dashes), not the project name.

Nothing prevents you from limiting yourself to basic alphanumeric project names in Jenkins. That's why there's an Advanced Project Option called 'Display Name' which can be anything and shows neither in file paths nor URLs. Just think of the project name in Jenkins as a "project key", and the display name as "project name" and you already have your proposed solution.

There's even a global (opt-in) option to define a required project name pattern that project names must adhere to. Prohibit spaces there and even your clueless colleagues won't be able to mess this up for you.

Thank you for the hints. I was unaware of those possibilities and will use them from now on.