hello,
if have recently working on replacing the [shell] object (ggee) from my patches as it is leaving zombies all over the place - i believe this is a know issue? (2002) http://markmail.org/message/wrlpbaal75viugft
(it would be really nice to have an object for communicating with the shell that is not buggy.)
so here is my workaround:
in a shell start up pdreceive and pipe the output into shell:
pdreceive 3003 udp| sh
send my messages from [netsend 1]
problem: pd sticks a ; onto the end of all messages
solution: pipe the message through sed on its way to pdreceive
pdreceive 3003 udp |sed 's/;//'|sh
ok now so now this is fine for things that do there job and then finish such as ls cat etc. but what about things that need to stay running? for example when i want to open emacs then run another command the second command wont be run until emacs is closed.
i thought adding a & at the end would work but it doesnt
pdreceive 3003 udp |sed 's/;/&/'|sh
can someone tell me what i am doing wrong?
also this method is fine for sending stuff to the shell but what about getting results back from the shell? like a bang when the process is finsihed or the result of a pwd command? i thought about pipeing | the output of the shell into a pdsend on another port but that seems messy?
anyone got solutions to these issues? or anyone with the skills agree that [shell] should be fixed or rewritten and included in another lib?
many thanks
rob canning
Hallo, Rob Canning hat gesagt: // Rob Canning wrote:
anyone got solutions to these issues? or anyone with the skills agree that [shell] should be fixed or rewritten and included in another lib?
I'd recommend to use pdlua instead of shell. You get a nicer language and can use it for many other tasks, too.
To simply start a program use e.g.
os.execute("gvim")
or use io.popen(prog) for running more advanced commands that you need to get feeback from. (io.popen may not work on Windows, AFAIK)
Frank
Hello,
Le 28/01/09 20:07, Frank Barknecht a écrit :
Hallo, Rob Canning hat gesagt: // Rob Canning wrote:
anyone got solutions to these issues? or anyone with the skills agree that [shell] should be fixed or rewritten and included in another lib?
I'd recommend to use pdlua instead of shell. You get a nicer language and can use it for many other tasks, too.
But if you don't want to compile lua, you can also use the [popen] object that comes with pd extended (at least on osx).
n
another solution is with pyext. in pdmtl abstractions it's under linux.process.pd (but i think it should work on windows and mac (not tested)).
import sys, os, time, signal, subprocess try: import pyext except: print "ERROR: This script must be loaded by the PD pyext external" sys.exit()
class sub(pyext._class): """A simple script to start and stop process"""
# number of inlets and outlets
_inlets=1
_outlets=1
def __init__(self,*args):
pass
def start_1(self,a):
global process
process = subprocess.Popen(str(a))
self._outlet(1, 'opening '+str(a))
def stop_1(self,*a):
os.kill(process.pid, signal.SIGTERM)
self._outlet(1, 'stopping process '+str(process.pid))
Both Lua and Python are great suggestions. But avoid the issue of fixing [shell]. It has been problematic for a long time and this is another opportunity to discover how to fix it, or deprecate/remove it altogether.
I think there's something to be said for all Pd distros _not_ including [shell] for obvious reasons. If users want to open that door it should be an informed decision. That would happen if they could only use PyExt and PdLua. [shell] is very buggy, has it's day finally come to be fixed or dropped?
On Wed, 28 Jan 2009 14:50:32 -0500 patrick puredata@11h11.com wrote:
another solution is with pyext. in pdmtl abstractions it's under linux.process.pd (but i think it should work on windows and mac (not tested)).
import sys, os, time, signal, subprocess try: import pyext except: print "ERROR: This script must be loaded by the PD pyext external" sys.exit()
class sub(pyext._class): """A simple script to start and stop process"""
# number of inlets and outlets _inlets=1 _outlets=1 def __init__(self,*args): pass def start_1(self,a): global process process = subprocess.Popen(str(a)) self._outlet(1, 'opening '+str(a)) def stop_1(self,*a): os.kill(process.pid, signal.SIGTERM) self._outlet(1, 'stopping process '+str(process.pid))
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I just want to say that i am very happy tu use [shell] in my patch.
It is very useful to execute a PHP script for exemple.
++
Jack
Le 28 janv. 09 à 21:49, Andy Farnell a écrit :
Both Lua and Python are great suggestions. But avoid the issue of fixing [shell]. It has been problematic for a long time and this is another opportunity to discover how to fix it, or deprecate/remove it altogether.
I think there's something to be said for all Pd distros _not_ including [shell] for obvious reasons. If users want to open that door it should be an informed decision. That would happen if they could only use PyExt and PdLua. [shell] is very buggy, has it's day finally come to be fixed or dropped?
On Wed, 28 Jan 2009 14:50:32 -0500 patrick puredata@11h11.com wrote:
another solution is with pyext. in pdmtl abstractions it's under linux.process.pd (but i think it
should work on windows and mac (not tested)).import sys, os, time, signal, subprocess try: import pyext except: print "ERROR: This script must be loaded by the PD pyext
external" sys.exit()class sub(pyext._class): """A simple script to start and stop process"""
# number of inlets and outlets _inlets=1 _outlets=1 def __init__(self,*args): pass def start_1(self,a): global process process = subprocess.Popen(str(a)) self._outlet(1, 'opening '+str(a)) def stop_1(self,*a): os.kill(process.pid, signal.SIGTERM) self._outlet(1, 'stopping process '+str(process.pid))
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- Use the source
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Yep, actually that was a prescriptive and arrogant thing of me to suggest dropping it. I have lots of patches that use it too.
So, poor [shell], very useful, but quite broken (if you use it in any serious way). How can it be fixed?
On Thu, 29 Jan 2009 00:12:14 +0100 Jack jack@rybn.org wrote:
I just want to say that i am very happy tu use [shell] in my patch.
It is very useful to execute a PHP script for exemple. ++Jack
Le 28 janv. 09 à 21:49, Andy Farnell a écrit :
Both Lua and Python are great suggestions. But avoid the issue of fixing [shell]. It has been problematic for a long time and this is another opportunity to discover how to fix it, or deprecate/remove it altogether.
I think there's something to be said for all Pd distros _not_ including [shell] for obvious reasons. If users want to open that door it should be an informed decision. That would happen if they could only use PyExt and PdLua. [shell] is very buggy, has it's day finally come to be fixed or dropped?
On Wed, 28 Jan 2009 14:50:32 -0500 patrick puredata@11h11.com wrote:
another solution is with pyext. in pdmtl abstractions it's under linux.process.pd (but i think it
should work on windows and mac (not tested)).import sys, os, time, signal, subprocess try: import pyext except: print "ERROR: This script must be loaded by the PD pyext
external" sys.exit()class sub(pyext._class): """A simple script to start and stop process"""
# number of inlets and outlets _inlets=1 _outlets=1 def __init__(self,*args): pass def start_1(self,a): global process process = subprocess.Popen(str(a)) self._outlet(1, 'opening '+str(a)) def stop_1(self,*a): os.kill(process.pid, signal.SIGTERM) self._outlet(1, 'stopping process '+str(process.pid))
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- Use the source
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If someone writes the code and submits it to the patch tracker, it
will be included! That's all it takes to fix it. ;) Or pay someone
to fix it, or submit really clear, simple bug reports, i.e. a simple
patch that will reproduce the problem everytime.
.hc
On Jan 28, 2009, at 6:49 PM, Andy Farnell wrote:
Yep, actually that was a prescriptive and arrogant thing of me to suggest dropping it. I have lots of patches that use it too.
So, poor [shell], very useful, but quite broken (if you use it in any serious way). How can it be fixed?
On Thu, 29 Jan 2009 00:12:14 +0100 Jack jack@rybn.org wrote:
I just want to say that i am very happy tu use [shell] in my patch. It is very useful to execute a PHP script for exemple. ++
Jack
Le 28 janv. 09 à 21:49, Andy Farnell a écrit :
Both Lua and Python are great suggestions. But avoid the issue of fixing [shell]. It has been problematic for a long time and this is another opportunity to discover how to fix it, or deprecate/remove it altogether.
I think there's something to be said for all Pd distros _not_ including [shell] for obvious reasons. If users want to open that door it should be an informed decision. That would happen if they could only use PyExt and PdLua. [shell] is very buggy, has it's day finally come to be fixed or dropped?
On Wed, 28 Jan 2009 14:50:32 -0500 patrick puredata@11h11.com wrote:
another solution is with pyext. in pdmtl abstractions it's under linux.process.pd (but i think it should work on windows and mac (not tested)).
import sys, os, time, signal, subprocess try: import pyext except: print "ERROR: This script must be loaded by the PD pyext external" sys.exit()
class sub(pyext._class): """A simple script to start and stop process"""
# number of inlets and outlets _inlets=1 _outlets=1
def __init__(self,*args): pass
def start_1(self,a): global process process = subprocess.Popen(str(a)) self._outlet(1, 'opening '+str(a))
def stop_1(self,*a): os.kill(process.pid, signal.SIGTERM) self._outlet(1, 'stopping process '+str(process.pid))
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- Use the source
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- Use the source
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
On Wed, Jan 28, 2009 at 02:26:13PM +0000, Rob Canning wrote:
(it would be really nice to have an object for communicating with the shell that is not buggy.)
[snip]
also this method is fine for sending stuff to the shell but what about getting results back from the shell? like a bang when the process is finsihed or the result of a pwd command? i thought about pipeing | the output of the shell into a pdsend on another port but that seems messy?
anyone got solutions to these issues? or anyone with the skills agree that [shell] should be fixed or rewritten and included in another lib?
As a fan of vanilla Pd, I was delighted when Claude posted this:
http://lists.puredata.info/pipermail/pd-list/2008-03/060702.html
Attached is a concrete example of this for your specific use case. It allows you to run arbitrary commands on your shell and get the results back into Pd. I know you said that this seems messy to you, but I feel that Claude's way is actually quite elegant.
Untar the attached, and then do:
pd -open runme.pd &; sleep 5; ./listener
Have fun!
Best,
Chris.
Chris McCormick wrote:
Attached is a concrete example of this for your specific use case. It allows you to run arbitrary commands on your shell and get the results back into Pd. I know you said that this seems messy to you, but I feel that Claude's way is actually quite elegant.
Untar the attached, and then do:
pd -open runme.pd &; sleep 5; ./listener
thanks, that's very useful... i changed it to udp version using netcat - useful when using a remote machine without pd or for saving some tcp overhead on local use. unfortunately it doesn't support disconnects (port number of pd changes on reconnect). Using netcat with tcp should be possible as well, using Chris's version and netcat instead of pdreceive / pdsend.
Martin