At $OLDJOB we used to use nfs extensively, and a common desire was to run some command on the system where the files actually resided, after navigating there (with cd in a local terminal).
To that end, we developed a script called "yonder", which let you write "yonder any unix command with awful quoting needs". If the filesystem was local, it just executed the command; if it was remote, it took care of all quoting needs, then executing a command like "ssh hostname yonder - ENCODED_MESS".
(A variant, autoyonder, could be used in any shell script by ". autoyonder", so that any shell script could transparently run "over yonder")
I think that in the end we used the algorithm of:
- target directory is "argv[-1]"
- concatenate all arguments with a space separating
- single-quoting everything, who cares if it's needed
- replacing single quotes with the 4-byte sequence '\''
the quoting method we learned from git. Earlier versions took advantage of how we had an 8-bit clean commandline but only needed to send 7-bit strings: we just set the high bit on everything, then stripped it off. The NUL between argv values becomes 0x80, the space within an argument becomes 0xa0, etc., with no special shell interpretation. Gross but it fit the bill.
I don't have access to the scripts anymore, but it worked really nicely for the time.
I wish this existed except for binaries inside Docker. A fat binary for Windows, macOS and Linux that isn’t really a binary at all, but fetched the thing you want from docker and just runs it. With the local file system.
And i wish Microsoft would implement this for the "az vm run-command invoke --command-id RunPowerShellScript ..." command for Windows Virtual Machines.
Here you have JSON quoting along with PowerShell and optionally CMD quoting.
I have a script for this so that I can use modern Linux tools on macOS buy without having to go down dependency hell trying to get all the versions correct.
The script uses its name to look for a corresponding dockerfile/container (which it auto builds if needed) and then mounts the file system inside to allow you to run it on one or mode files locally.
By using $OLDJOB are you saying at every old job you ever held this was the case or just the last one? Because if it's just the last one you should have used:
const OLDJOB
Not sure why you used a variable in a comment, maybe because this is hackernews and you want to resonate with other programmers?
People used to use shell variables like this a lot in (to name one place) alt.sysadmin.recovery, such that the FAQ even mentions it: http://www.faqs.org/faqs/sysadmin-recovery/ (section 1.3)... meaning people have done this for decades.
To that end, we developed a script called "yonder", which let you write "yonder any unix command with awful quoting needs". If the filesystem was local, it just executed the command; if it was remote, it took care of all quoting needs, then executing a command like "ssh hostname yonder - ENCODED_MESS".
(A variant, autoyonder, could be used in any shell script by ". autoyonder", so that any shell script could transparently run "over yonder")
I think that in the end we used the algorithm of: - target directory is "argv[-1]" - concatenate all arguments with a space separating - single-quoting everything, who cares if it's needed - replacing single quotes with the 4-byte sequence '\'' the quoting method we learned from git. Earlier versions took advantage of how we had an 8-bit clean commandline but only needed to send 7-bit strings: we just set the high bit on everything, then stripped it off. The NUL between argv values becomes 0x80, the space within an argument becomes 0xa0, etc., with no special shell interpretation. Gross but it fit the bill.
I don't have access to the scripts anymore, but it worked really nicely for the time.