Hi Eric,

Maybe it will help if I also give an example of Squeak interacting with
an external program through stdio pipes Here I will use /bin/bash as the
exteral program. You would want to substitute that with the full path
to whatever program you are actually trying to run.

You can experiment with the example below by copying it into a workspace:


    "Create an external OS process running the /bin/bash program. The
    program will be connected to Squeak through stdio pipes."
    bashProxy := PipeableOSProcess command: '/bin/bash'.
    
    "Send a command line to the bash program, followed by a line
    terminator, and flush the stream so the command is available to
    the bash program."
    bashProxy nextPutAll: 'who'; nextPut: Character lf; flush. 
    
    "Wait a short time to give the bash program time to run, and to send
    the result back to Squeak."
    (Delay forMilliseconds: 20) wait.
    
    "Read all available data from the stdout stream of the bash process.
    Note also methods #errorUpToEndOfFile, #upToEndOfFile."
    bashProxy upToEnd.
    
    "When you are done interacting with your bash program, close it and
    allow the external process to exit."
    bashProxy close

Dave

On Fri, Aug 26, 2022 at 11:19:04PM -0400, David T. Lewis wrote:
> Hi Eric and Tom,
> 
> On Fri, Aug 26, 2022 at 04:27:56PM -0400, Eric Gade wrote:
> > I believe what is happening is that the various #command: messages in
> > OSProcess classes are executing without searching my PATH. Even if I add a
> > copy of the current running process environment and set that as the
> > environment of a new PipeableOSProcess, for example, I can't even get a
> > result for `which node`. I can see that /usr/bin and /usr/sbin are on the
> > path from within Squeak.
> > 
> 
> Yes that is correct. On a unix system, the interpretation of PATH (and
> lots of other things) are done by the shell, which is typically an
> executable program such as /bin/bash. The actual programs and commands
> that you run on a unix system are subprocesses of that shell program.
> So the shell interprets the PATH and uses it to find the program that
> you want to run.
> 
> In Squeak with OSProcess, your Squeak virtual machine is the "shell"
> and you can directly run programs by creating subprocesses of the VM
> process. Of course, you can chose to run the executable program
> /bin/bash, in which case you have a real unix shell, and you can let
> that shell run other commands in the normal way.
> 
> You can also run any other executable directly (and I think this is
> what you have been doing). In that case there is no unix shell program
> involved, and you would need to specify the fully qualified path to
> the program, and you would need to do any necessary command parameter
> expansion that would otherwise have been done by the unix shell.
> 
> In OSProcess/CommandShell there is also a pure Smalltalk emulation
> of a simple unix shell. This is by no means a complete emulation of
> /bin/bash but it is sufficient to handle things like PATH expansion
> and command pipeline composition without requiring the actual
> /bin/bash shell.
> 
> So to tie the pieces together, if you want to run the command "which node"
> you can do this:
> 
>   OSProcess outputOf: 'which node'
> 
> This uses a CommandShell in Squeak to do the shell processing to
> locate and run the program /usr/bin/which (so no need for /bin/bash).
> It takes some patience but if you step through this it a debugger
> you will be able to see what is going on. The Smalltalk command
> shell emulation sets everything up so that OSProcess can run the
> /usr/bin/which program as a direct subprocess of the Squeak VM.
> 
> > Another example is that `PipeableOSProcess class >> #unixCommandPipeLine`
> > responds with an empty string when I inspect it.
> > 
> > Might this all be related to newer macOS settings somehow?
> > 
> 
> This method is just an example to show how to compose a command pipeline
> with some programs that would be found on a typical Unix/Linux system.
> I'm not sure what it does on Mac.  It uses the programs 'ps', 'grep',
> and 'cut', so if any of these is not found on your system, it probably
> will just give an empty string in the output (plus some error output
> that you can probably find if you dig through it in a debugger).
> 
> Dave
> 
>