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