[squeak-dev] wildcard expansion with OSProcess outputOf: through ssh
asqueaker at gmail.com
Thu Jul 7 20:50:32 UTC 2022
That's a great resource, thanks.
On Thu, Jul 7, 2022 at 12:32 AM Jakob Reschke <jakres+squeak at gmail.com>
> Usually shells are not supposed to do wildcard expansion in double quotes
> either. They will do variable substitution between double quotes, but if
> OSProcess does not implement that, it is irrelevant for now.
> Kind regards,
> Chris Muller <ma.chris.m at gmail.com> schrieb am Do., 7. Juli 2022, 03:58:
>> > If you started with this command line:
>> > $ ssh dan.box.squeak.org cat /sys/class/net/*/address
>> > then your intent was probably to pass the '/sys/class/net/*/address'
>> > over to the remote system through ssh, where the shell over there would
>> > expand the $* wild card on the remote system.
>> > But what is actually happening
>> > is that the expansion is happening on your local box, which just happens
>> > to have similar looking things in its /sys/class/net/ directory, then
>> > the expanded results over to the remote system through ssh.
>> Oh, my!!
>> > The resulting
>> > path strings probably do not match what is actually on that remote
>> > so you end up with file not found errors in the result (more on that
>> > there was a bug in OSProcess that masked the error).
>> > The way to handle this in a unix shell is to escape the $* wild card so
>> > that it will be passed over to the remote system to be expanded over
>> > On a unix shell you can excape the wildcard character like this:
>> > $ ssh dan.box.squeak.org cat /sys/class/net/\*/address
>> > or by quoting the whole path string like this:
>> > $ ssh dan.box.squeak.org cat '/sys/class/net/*/address'
>> ... (from your 2nd reply)...
>> > Try evaluating this:
>> > OSProcess outputOf: 'ssh dan.box.squeak.org ''cat
>> /sys/class/net/*/address'' '.
>> > CommandShell will understand the single quote characters as escaping the
>> > string that they surround, similar to the behavior of bash. You have to
>> > escape the single quotes in your Smalltalk string, so they look like the
>> > above in the Smalltalk expression. This will let the path with wild card
>> > get passed as a single string parameter over to the remote system via
>> > where it will be properly expanded on the remote system.
>> This is immensely illuminating! Not just the fix, but a better
>> understanding of how things work. By literal quoting (with single
>> quotes) the entire remote command, it'll ensure to treat it as a
>> single literal argument to the local ssh command that, instead of, as
>> with my erroneous use of double quotes, processing it via my local
>> filesystem before even _beginning_ to execute the ssh command. Now
>> that you've pointed it out, it seems obvious.. I think. :/
>> Hmm, because I'm still fooled by the fact that double quotes works on
>> in my terminal -- passing it to the remote system like I want instead
>> of processing it via my local system first.. oh well. This fix to
>> pass the command as a literal string is safe and makes sense.
>> > The next issue is that we are trying to invoke one of these command
>> > using CommandShell, which is yet another layer of shell command line
>> > interpretation.
>> > CommandShell is a very simple unix-like shell, but it does
>> > not include things that you would expect from a bash shell such as shell
>> > variables and proper escaping of wild cards. I do not have a suggestion
>> > to addess this at the moment but I'll try to follow up with something
>> Oh, that's good to know. I just tried,
>> OSProcess outputOf: 'echo $HOME'
>> and it returned '$HOME'. Yikes!
>> Hmm.. this is an unexpected limitation.
>> I just tried to quickly research a way to pass a string of key=value's
>> syntax to the bash command itself, something like:
>> OSProcess outputOf: 'bash --environment ''key1=value1'' -c ''ssh
>> dan ''cat /sys/class/net/*/address'''
>> where my code would replace "key1=value1", above, with every entry in
>> the 'environment' Dictionary of UnixProcess, which appears to contain
>> the environment for the squeak vm process.
>> --environment, above, is bogus, just for illustration, I don't know
>> quite how to do it. I don't even know if this is a good approach at
>> You've already done a lot, and I'm grateful, but if you think of any
>> good solutions to accessing environment variables in #outputOf:
>> strings, please let me know! :)
>> > Finally, your example exposed a bug in OSProcess class>>outputOf: which
>> > was in this case failing to report the error output of your ssh command
>> > due to a timing issue related to reading from the error output pipe.
>> > fixed now in OSProcess-dtl.128, so if you update you will probably see
>> > meaningful error notifications with you run the ssh command.
>> An amazing and unexpected turnaround, Dave. OSProcess is Squeak's
>> most important external package.
>> - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev