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/1d80e531/attachment-0001.html>