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 -- View this message in context: http://forum.world.st/PipeableOSProcess-shell-interaction-tp4692906.html Sent from the Squeak - Beginners mailing list archive at Nabble.com.
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
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 -- View this message in context: http://forum.world.st/PipeableOSProcess-shell-interaction-tp4692906p4693623.... Sent from the Squeak - Beginners mailing list archive at Nabble.com.
On Wed, Jun 12, 2013 at 2:47 AM, David T. Lewis lewis@mail.msen.com 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?
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 lewis@mail.msen.com 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
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 lewis@mail.msen.com 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 lewis@mail.msen.com
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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
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 lewis@mail.msen.com 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 lewis@mail.msen.com
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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
-- Gary Dunn Open Slate Project http://openslate.org/
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
beginners@lists.squeakfoundation.org
-
David T. Lewis -
OpenSlate ChalkDust -
Sean P. DeNigris