I see various ways to run something, none of which are quite what I want. The objective is to run openssl in a particular directory. I have no need to make this portable (unless you mean running on all of Ubuntu, Debian, Slackware, etc. <g>), so #forkAndExec:...workingDirectory: would almost be ok, **but**, I need to wait around for the result. In truth, there are a few things that have to happen in sequence; perhaps I could simply write multiple lines to the command string. Still, in the interest of idealism, it would be nice to run the commands on other than the Pharo main thread (no sense diving into something that might not return[*]), and to know when the work is done, and to get the different steps to happen in sequence. There was mention of tests for OSProcess (which might provide clues), but I have not been able to find them. Any hints? Bill [*] insert Windows joke here :)
On Fri, Sep 25, 2009 at 11:48:22PM -0400, Schwab,Wilhelm K wrote:
I see various ways to run something, none of which are quite what I want. The objective is to run openssl in a particular directory. I have no need to make this portable (unless you mean running on all of Ubuntu, Debian, Slackware, etc. <g>), so #forkAndExec:...workingDirectory: would almost be ok, **but**, I need to wait around for the result. In truth, there are a few things that have to happen in sequence; perhaps I could simply write multiple lines to the command string.
You should install CommandShell, which is a companion to OSProcess. Look at the class side methods in CommandShell and PipeableOSProcess for examples, also look at the unit tests. CommandShell has an MVC user interface as well as Morphic, so you will have to proceed through the errors when loading on Pharo.
Still, in the interest of idealism, it would be nice to run the commands on other than the Pharo main thread (no sense diving into something that might not return[*]), and to know when the work is done, and to get the different steps to happen in sequence.
PipeableOSProcess uses non-blocking I/O and event driven input. There should be no problem with blocking if you use this. If you use the lower-level classes in OSProcess, you need to handle issues like this yourself (also beware of "pipe handle leaks" from failing to close file descriptors if you are handling this yourself).
There was mention of tests for OSProcess (which might provide clues), but I have not been able to find them. Any hints?
Tests for OSProcess and CommandShell are in the SqueakSource projects. The package names are Tests-OSProcess and Tests-CommandShell. Dave
Dave, I just tried command shell; are you _sure_ it is possible to proceed past the errors? It looks badly broken from here. I can't say I'm happy with the way Pharo brings things to a halt over deprecated methods; yes, it gets attention before things go away in future release, but there are times when I would like to gag it and just get some work done. I still do not see the tests. Are you saying that they should have been installed with OSProess itself? If there are separate packages on ss, I don't see them either. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Saturday, September 26, 2009 9:23 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] OSProcess question On Fri, Sep 25, 2009 at 11:48:22PM -0400, Schwab,Wilhelm K wrote:
I see various ways to run something, none of which are quite what I want. The objective is to run openssl in a particular directory. I have no need to make this portable (unless you mean running on all of Ubuntu, Debian, Slackware, etc. <g>), so #forkAndExec:...workingDirectory: would almost be ok, **but**, I need to wait around for the result. In truth, there are a few things that have to happen in sequence; perhaps I could simply write multiple lines to the command string.
You should install CommandShell, which is a companion to OSProcess. Look at the class side methods in CommandShell and PipeableOSProcess for examples, also look at the unit tests. CommandShell has an MVC user interface as well as Morphic, so you will have to proceed through the errors when loading on Pharo.
Still, in the interest of idealism, it would be nice to run the commands on other than the Pharo main thread (no sense diving into something that might not return[*]), and to know when the work is done, and to get the different steps to happen in sequence.
PipeableOSProcess uses non-blocking I/O and event driven input. There should be no problem with blocking if you use this. If you use the lower-level classes in OSProcess, you need to handle issues like this yourself (also beware of "pipe handle leaks" from failing to close file descriptors if you are handling this yourself).
There was mention of tests for OSProcess (which might provide clues), but I have not been able to find them. Any hints?
Tests for OSProcess and CommandShell are in the SqueakSource projects. The package names are Tests-OSProcess and Tests-CommandShell. Dave _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, Sep 26, 2009 at 11:04:37AM -0400, Schwab,Wilhelm K wrote:
Dave,
I just tried command shell; are you _sure_ it is possible to proceed past the errors?
No, I had not checked on the most recent Pharo. So I just downloaded a Pharo image to try it. You can proceed through the warnings about missing MVC stuff. And when you get to the end of the install, the CommandShell class>>initialize will put you into a debugger. Comment out the last line where it is trying to open a CommandShell window, then proceed. This should get you through the installation.
It looks badly broken from here.
It looks pretty bad from here also. The Morphic UI no longer works (it was working the last time I looked at Pharo, but not now). Some AioEventHandlerTestCase tests are now failing due to something different in Socket. Some of the CommandShellTestCase tests get hung up when doing very complex command pipelines (i.e. lots of Process coordination). But if you limit yourself to running simple commands and do not use the CommandShell user interface, it should still do what you need.
I can't say I'm happy with the way Pharo brings things to a halt over deprecated methods; yes, it gets attention before things go away in future release, but there are times when I would like to gag it and just get some work done.
Mea culpa, I just fixed the deprecated method issue in CommandShell, so if you load the latest version now this problem should be gone.
I still do not see the tests. Are you saying that they should have been installed with OSProess itself? If there are separate packages on ss, I don't see them either.
Open this MC repository: MCHttpRepository location: 'http://www.squeaksource.com/OSProcess' user: '' password: '' Then load the latest versions of both of these packags: OSProcess Tests-OSProcess Open this MC repository: MCHttpRepository location: 'http://www.squeaksource.com/CommandShell' user: '' password: '' And load the latest versions of both these packages: CommandShell Tests-CommandShell HTH, Dave
check the preferences you can also ignore them or get atrace in the transcript On Sep 26, 2009, at 5:04 PM, Schwab,Wilhelm K wrote:
Dave,
I just tried command shell; are you _sure_ it is possible to proceed past the errors? It looks badly broken from here. I can't say I'm happy with the way Pharo brings things to a halt over deprecated methods; yes, it gets attention before things go away in future release, but there are times when I would like to gag it and just get some work done.
I still do not see the tests. Are you saying that they should have been installed with OSProess itself? If there are separate packages on ss, I don't see them either.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of David T. Lewis Sent: Saturday, September 26, 2009 9:23 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] OSProcess question
On Fri, Sep 25, 2009 at 11:48:22PM -0400, Schwab,Wilhelm K wrote:
I see various ways to run something, none of which are quite what I want. The objective is to run openssl in a particular directory. I have no need to make this portable (unless you mean running on all of Ubuntu, Debian, Slackware, etc. <g>), so #forkAndExec:...workingDirectory: would almost be ok, **but**, I need to wait around for the result. In truth, there are a few things that have to happen in sequence; perhaps I could simply write multiple lines to the command string.
You should install CommandShell, which is a companion to OSProcess. Look at the class side methods in CommandShell and PipeableOSProcess for examples, also look at the unit tests.
CommandShell has an MVC user interface as well as Morphic, so you will have to proceed through the errors when loading on Pharo.
Still, in the interest of idealism, it would be nice to run the commands on other than the Pharo main thread (no sense diving into something that might not return[*]), and to know when the work is done, and to get the different steps to happen in sequence.
PipeableOSProcess uses non-blocking I/O and event driven input. There should be no problem with blocking if you use this. If you use the lower-level classes in OSProcess, you need to handle issues like this yourself (also beware of "pipe handle leaks" from failing to close file descriptors if you are handling this yourself).
There was mention of tests for OSProcess (which might provide clues), but I have not been able to find them. Any hints?
Tests for OSProcess and CommandShell are in the SqueakSource projects. The package names are Tests-OSProcess and Tests- CommandShell.
Dave
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I get a walkback from this: Socket newTCP connectTo: (NetNameResolver addressFromString: '127.0.0.1') port: 8086. Is this a known bug? The reason I am asking is that it causes test failures in the OSProcess test suite. Thanks, Dave
participants (3)
-
David T. Lewis -
Schwab,Wilhelm K -
Stéphane Ducasse