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 ?



2017-05-29 13:28 GMT+02:00 Roman Haefeli <reduzent@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