Smalltalk › Squeak › Squeak - Beginners

PipeableOSProcess shell interaction

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Sean P. DeNigris

PipeableOSProcess shell interaction

Administrator

When using PipeableOSProcess as a shell, how can I get feedback on the status of the individual commands?

For example, with waitForCommand:, I can do:
p := PipeableOSProcess waitForCommand: 'curl -L largeFile'.
p succeeded ifFalse: [ ^ self error: 'Could not dowload...' ].

but a the shell like:
shell := PipeableOSProcess bash.
shell exec: ('cd ', folderName).
shell exec: 'curl -L largeFile...'.
what's the equivalent of #succeeded? If there's no clear external sign that the command is finished, how do I check? Also, I don't seem to get anything back on the error stream e.g. if I change curl to cul, which doesn't exist, I still get an empty string from #errorUpToEnd.

Thanks!

Cheers,
Sean

David T. Lewis

Re: PipeableOSProcess shell interaction

On Tue, Jun 11, 2013 at 10:34:47PM -0700, Sean P. DeNigris wrote:

> When using PipeableOSProcess as a shell, how can I get feedback on the status
> of the individual commands?
>
> For example, with waitForCommand:, I can do:
> p := PipeableOSProcess waitForCommand: 'curl -L largeFile'.
> p succeeded ifFalse: [ ^ self error: 'Could not dowload...' ].
>
> but a the shell like:
> shell := PipeableOSProcess bash.
> shell exec: ('cd ', folderName).
> shell exec: 'curl -L largeFile...'.
> what's the equivalent of #succeeded? If there's no clear external sign that
> the command is finished, how do I check? Also, I don't seem to get anything
> back on the error stream e.g. if I change curl to cul, which doesn't exist,
> I still get an empty string from #errorUpToEnd.
>

When you run a Unix shell (bash) in a pipeable proxy, you can talk to the
shell by reading and writing to the proxy. A Unix shell keeps track of the
exit status of the last program that it ran in a shell variable ($?), so
you can ask the shell for that exit status.

This should give you a few ideas:

shell := PipeableOSProcess bash. "Run a bash shell in a pipeable proxy"
shell pipeFromOutput reader setNonBlocking. "Do not block the VM on reads"
shell exec: 'cd ..'. "Write a command to shell input with a line terminator"
shell exec: 'ls'. "Write another command to bash"
(Delay forMilliseconds: 200) wait. "Wait for output to arrive"
shell upToEnd inspect. "Read from bash shell output"
shell exec: 'echo $?'. "Ask bash shell for exit status of the last command".
(Delay forMilliseconds: 100) wait.
shell upToEnd inspect.
shell close. "Do not leave open file handles from pipes"

PipeableOSProcess is designed to be part of CommandShell, so when you use it
directly (rather than using a CommandShell), you need to take care of a few
details. The important things are to set the output pipe for nonblocking reads
(otherwise you will hang up your VM on a read), and to close pipes when you
are done using them (otherwise you will "leak" file handles over time).

Dave

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Sean P. DeNigris

Re: PipeableOSProcess shell interaction

Administrator

David T. Lewis wrote

This should give you a few ideas:

As always, many thanks. I will play with that example...

David T. Lewis wrote

The important things are to set the output pipe for nonblocking reads
(otherwise you will hang up your VM on a read)
, and to close pipes when you
are done using them (otherwise you will "leak" file handles over time)

Yes, been both of those places before, lol. The first is particularly not fun :/

Cheers,
Sean

openslateproj

Re: PipeableOSProcess shell interaction

In reply to this post by David T. Lewis

On Wed, Jun 12, 2013 at 2:47 AM, David T. Lewis <[hidden email]> wrote:

On Tue, Jun 11, 2013 at 10:34:47PM -0700, Sean P. DeNigris wrote:
> When using PipeableOSProcess as a shell, how can I get feedback on the status
> of the individual commands?
[snip]
PipeableOSProcess is designed to be part of CommandShell, so when you use it
directly (rather than using a CommandShell), you need to take care of a few
details. The important things are to set the output pipe for nonblocking reads
(otherwise you will hang up your VM on a read), and to close pipes when you
are done using them (otherwise you will "leak" file handles over time).

Dave

Could the example you gave be implemented using CommandShell? In what situations would I want to use PipeableOSProcess instead of CommandShell?
--
Gary Dunn
Open Slate Project
http://openslate.org/

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

David T. Lewis

Re: PipeableOSProcess shell interaction

On Mon, Jun 17, 2013 at 10:16:05AM -1000, OpenSlate ChalkDust wrote:

> On Wed, Jun 12, 2013 at 2:47 AM, David T. Lewis <[hidden email]> wrote:
>
> > On Tue, Jun 11, 2013 at 10:34:47PM -0700, Sean P. DeNigris wrote:
> > > When using PipeableOSProcess as a shell, how can I get feedback on the
> > status
> > > of the individual commands?
> > [snip]
> > PipeableOSProcess is designed to be part of CommandShell, so when you use
> > it
> > directly (rather than using a CommandShell), you need to take care of a few
> > details. The important things are to set the output pipe for nonblocking
> > reads
> > (otherwise you will hang up your VM on a read), and to close pipes when you
> > are done using them (otherwise you will "leak" file handles over time).
> >
> > Dave
> >
> >
> Could the example you gave be implemented using CommandShell? In what
> situations would I want to use PipeableOSProcess instead of CommandShell?

Good question. CommandShell works at a higher level, and it manages the
annoying details of closing pipe handles and making sure that you do
not block the VM. In most cases, it is easier to use CommandShell rather
than operating directly on the lower level PipeableOSProcess.

For example (to build on the earlier example), if you want to run the
Unix 'ls' command, and check its exit status to determine if a file was
not found, it is not necessary to use the lower level PipeableOSProcess.
You can do this instead:

CommandShell new
if: 'cd .. ; ls aFile'
then: ['the ls command succeeded']
else: ['the file was not found'] ==> 'the file was not found'

Having said that, CommandShell is a simple simulation of a Unix shell,
and it is not a complete replacement for something like bash. There
are cases when you may need to use the features of a real Unix shell,
so working directly with a PipeableOSProcess connected to /usr/bin/bash
may be necessary in some cases.

Dave

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

openslateproj

Re: PipeableOSProcess shell interaction

I tried to use your code but I don't have either class in my 4.3 or 4.4 images. Do they require adding something?

On Mon, Jun 17, 2013 at 1:38 PM, David T. Lewis <[hidden email]> wrote:

On Mon, Jun 17, 2013 at 10:16:05AM -1000, OpenSlate ChalkDust wrote:
> On Wed, Jun 12, 2013 at 2:47 AM, David T. Lewis <[hidden email]> wrote:
>
> > On Tue, Jun 11, 2013 at 10:34:47PM -0700, Sean P. DeNigris wrote:
> > > When using PipeableOSProcess as a shell, how can I get feedback on the
> > status
> > > of the individual commands?
> > [snip]
> > PipeableOSProcess is designed to be part of CommandShell, so when you use
> > it
> > directly (rather than using a CommandShell), you need to take care of a few
> > details. The important things are to set the output pipe for nonblocking
> > reads
> > (otherwise you will hang up your VM on a read), and to close pipes when you
> > are done using them (otherwise you will "leak" file handles over time).
> >
> > Dave
> >
> >
> Could the example you gave be implemented using CommandShell? In what
> situations would I want to use PipeableOSProcess instead of CommandShell?

Good question. CommandShell works at a higher level, and it manages the
annoying details of closing pipe handles and making sure that you do
not block the VM. In most cases, it is easier to use CommandShell rather
than operating directly on the lower level PipeableOSProcess.

For example (to build on the earlier example), if you want to run the
Unix 'ls' command, and check its exit status to determine if a file was
not found, it is not necessary to use the lower level PipeableOSProcess.
You can do this instead:

CommandShell new
if: 'cd .. ; ls aFile'
then: ['the ls command succeeded']
else: ['the file was not found'] ==> 'the file was not found'

Having said that, CommandShell is a simple simulation of a Unix shell,
and it is not a complete replacement for something like bash. There
are cases when you may need to use the features of a real Unix shell,
so working directly with a PipeableOSProcess connected to /usr/bin/bash
may be necessary in some cases.

Dave

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

--
Gary Dunn
Open Slate Project
http://openslate.org/

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

David T. Lewis

Re: PipeableOSProcess shell interaction

On Mon, Jun 17, 2013 at 04:49:57PM -1000, OpenSlate ChalkDust wrote:
> I tried to use your code but I don't have either class in my 4.3 or 4.4
> images. Do they require adding something?
>

OSProcess and CommandShell are not part of Squeak, they are externally
maintained packages. You can load them into your standard Squeak image
by opening a SqueakMap browser:

world -> open... -> SqueakMap Catalogue

This will open a SqueakMap Package Loader. You can use this to load the
OSProcess package, then load the CommandShell package.

The PipeableOSProcess and CommandShell classes are both part of the
CommandShell package that you can load from SqueakMap.

Dave

>
> On Mon, Jun 17, 2013 at 1:38 PM, David T. Lewis <[hidden email]> wrote:
>
> > On Mon, Jun 17, 2013 at 10:16:05AM -1000, OpenSlate ChalkDust wrote:
> > > On Wed, Jun 12, 2013 at 2:47 AM, David T. Lewis <[hidden email]>
> > wrote:
> > >
> > > > On Tue, Jun 11, 2013 at 10:34:47PM -0700, Sean P. DeNigris wrote:
> > > > > When using PipeableOSProcess as a shell, how can I get feedback on
> > the
> > > > status
> > > > > of the individual commands?
> > > > [snip]
> > > > PipeableOSProcess is designed to be part of CommandShell, so when you
> > use
> > > > it
> > > > directly (rather than using a CommandShell), you need to take care of
> > a few
> > > > details. The important things are to set the output pipe for
> > nonblocking
> > > > reads
> > > > (otherwise you will hang up your VM on a read), and to close pipes
> > when you
> > > > are done using them (otherwise you will "leak" file handles over time).
> > > >
> > > > Dave
> > > >
> > > >
> > > Could the example you gave be implemented using CommandShell? In what
> > > situations would I want to use PipeableOSProcess instead of CommandShell?
> >
> > Good question. CommandShell works at a higher level, and it manages the
> > annoying details of closing pipe handles and making sure that you do
> > not block the VM. In most cases, it is easier to use CommandShell rather
> > than operating directly on the lower level PipeableOSProcess.
> >
> > For example (to build on the earlier example), if you want to run the
> > Unix 'ls' command, and check its exit status to determine if a file was
> > not found, it is not necessary to use the lower level PipeableOSProcess.
> > You can do this instead:
> >
> > CommandShell new
> > if: 'cd .. ; ls aFile'
> > then: ['the ls command succeeded']
> > else: ['the file was not found'] ==> 'the file was not found'
> >
> > Having said that, CommandShell is a simple simulation of a Unix shell,
> > and it is not a complete replacement for something like bash. There
> > are cases when you may need to use the features of a real Unix shell,
> > so working directly with a PipeableOSProcess connected to /usr/bin/bash
> > may be necessary in some cases.
> >
> > Dave
> >
> > _______________________________________________
> > Beginners mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/mailman/listinfo/beginners
> >
>
>
>
> --
> Gary Dunn
> Open Slate Project
> http://openslate.org/

> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners