That's a great resource, thanks.

 - Chris

On Thu, Jul 7, 2022 at 12:32 AM Jakob Reschke <jakres+squeak at gmail.com>
wrote:

> Hi,
>
> 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.
>
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_03
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02
>
> Kind regards,
> Jakob
>
> Chris Muller <ma.chris.m at gmail.com> schrieb am Do., 7. Juli 2022, 03:58:
>
>> Hi!
>>
>> > 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'
>> parameter
>> > over to the remote system through ssh, where the shell over there would
>> > expand the $* wild card on the remote system.
>>
>> Yes.
>>
>> > 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
>> passing
>> > 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
>> system,
>> > so you end up with file not found errors in the result (more on that
>> below,
>> > 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
>> there.
>> > 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
>> ssh,
>> > 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
>> lines
>> > 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
>> later.
>>
>> 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
>> all.
>>
>> 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.
>> It's
>> > fixed now in OSProcess-dtl.128, so if you update you will probably see
>> more
>> > 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...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220707/a2d9b140/attachment.html>