maybe the "shell" object

Patrick Pagano B.S, M.F.A

Assistant Professor in Residence

Digital Media & Design

Web & Interactive Technologies

University of Connecticut, Stamford

(352)-226-2016

From: Pd-list pd-list-bounces@lists.iem.at on behalf of cyrille henry ch@chnry.net Sent: Thursday, May 25, 2017 3:50:10 AM To: pd-list@lists.iem.at Subject: Re: [PD] Execute command from Pd

if the comand you execute is somthing like : ls | pdsend 5678 localhost udp

then you can get the result of the command in pd event if the object used have no feedback.

cheers c

Le 25/05/2017 à 09:38, Roman Haefeli a écrit :

Hey all

I'm looking for the best available solution to execute commands from Pd. Ideally, the object would launch the process independently from Pd in order to avoid any lock-ups. Then, it'd be nice if there would be interfaces to access stdout, stderr and the exit code (probably an outlet for each). Third, it should allow to send signals to the running process. I found [moolib/popen], [motex/system] and [ggee/shell] and none of them fits for what I intend to do. [popen] and [system] don't give any feedback at all and probably are meant to run one-shot commands only. [shell] comes closest, it has an outlet for stdout and one for the exit code. However, on macOS only the the second outlet works (and gives correct exit codes) while the left outlet never outputs anything. On Linux, the left outlet outputs stdout, while the right outlet always gives 0 regardless of actual exit code. Ideally, I need something that works on macOS and Linux the same way.

I'd like to be able to control a handful of jacktrip[1] instances from Pd. I need to be able to evaluate their stdout to get feedback about their connection status. Also, I need to be able to kill them individually.

I'm also happy to explore ideas that think outside the box as long as the solution can be built into a Deken package.

Thanks, Roman

[1] https://ccrma.stanford.edu/groups/soundwire/software/jacktrip/

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

for full duplex:

pdreceive 5678 | your_command | pdsend 6789 &

see attached patch (using ggee/shell, but would also works with e.g motex/system).

cheers

Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/

2017-05-28 20:06 GMT+02:00 oliver oliver@klingt.org:

cyrille henry wrote:

...

if the comand you execute is somthing like : ls | pdsend 5678 localhost udp

then you can get the result of the command in pd event if the object used have no feedback.

thanks ! but how would this work the other way round ?

best

oliver

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list

On 29/05/17 17:03, Max wrote:

What about your own moonlib/popen? How do ggee/shell, motex/system and moonlib/popen compare?

And does anybody know if any of them are blocking so that the timing of an external script is deterministic from within Pd's logical timeframe?

Cheers,

Chris.

On Mon, 2017-05-29 at 10:50 +0200, Antoine Rousseau wrote:

for full duplex:

pdreceive 5678 | your_command | pdsend 6789 &

see attached patch (using ggee/shell, but would also works with e.g motex/system).

Thansks. From what I understand this allows you to write to talk to the stdin of the launched command. That's a neat trick.

My main problem is still that I find it hard to kill a still running command, especially when I want to kill a specific one when many are running.

Roman

On Mon, 2017-05-29 at 13:03 +0200, Antoine Rousseau wrote:

...

And does anybody know if any of them are blocking so that the timing of an external script is deterministic from within Pd's logical timeframe?

afaik only [system] is blocking, while [shell] and [popen] use Pd polling system through Pd main loop.

...

I find it hard to kill a still running command, especially when I want to kill a specific one when many are running.

I would suggest writing your own script, that would call jacktrip, and which would take an additional (but ignored) ID parameter, which could then be used to identify each of the processes, to allow killing them individually with pkill.

For instance:

[my_script.sh ID1 ACTUAL_PARAMETERS &] | [shell or system or popen]

then:

[pkill -f my_script.sh ID1 &] | [shell or system or popen]

I am currently using the following script that outputs the command's PID (thanks to Jack for his help in this):

#!/bin/bash while read line do     echo "$line" done < <($@ 2>&1  & echo "PID $!")

Using a script has its own complications, though. Unfortunately, [shell] opens scripts relative to Pd's start location. So using a local script is not portable. When I distribute the script together with my Pd project, I'd rather want it relative to the patch, otherwise the script won't be found on other users' machines.

I am still not quite satisfied with the available options yet. Will experiment/think some more.

Anyway, thanks a lot for your thoughts.

Roman

Le 29/05/2017 à 11:40, Roman Haefeli a écrit :

My main problem is still that I find it hard to kill a still running command, especially when I want to kill a specific one when many are running.

The kill command should do the trick, it needs PID, and this should appear in stdout by doing 'command & echo $!'

On 2017-05-29 11:05, Jack wrote:

Something like this ? :

[netreceive -u 5678] | [print]

You can also add 2>&1 if you want to redirect error. This could give something like :

$ ls 2>&1 | pdsend 5678 localhost udp

or

or

$ (./test.sh | pdsend 7777 localhost udp) 2>&1 | pdsend 7778 localhost udp

this will give you the stdout on port 7777, and the stderr on 7778.

or

using the annotate-output program (on a Debian system you can get this from the devscripts package):

$ annotate-output + ./test.sh | pdsend 7777 localhost udp

this will prefix the output with "O:" (for stdout) and "E:" (for stderr), so you can simply use [route O: E:] to distinguish between the two streams. it also sends some informational (prefix "I:") data, from which you can get the exitcode of the program (once it finishes). in the above example, i suppressed all timestamping. omit the "+" if you want timestamps as well.

ghsdmr IOhannes