[PD] Execute command from Pd

[Antoine Rousseau]

>
> 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.


As you need [ggee/shell], then why not using also [ggee/getdir] to know
where your patch is located ?


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


2017-05-29 13:28 GMT+02:00 Roman Haefeli <reduzent at gmail.com>:

> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170529/ca53755a/attachment.html>