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