[PD] popen vs shell bug

[Pedro Lopes]

Yes of course, there's a lot of "wheels" out there, no need to reinvent it.
Just combine a bit with the possibility of sending signals, STDIN, STDOUT,
status and STDERR and we get ourselves a new "car".

On Thu, Jul 8, 2010 at 6:03 PM, Hans-Christoph Steiner <hans at at.or.at>wrote:

>
> We have [ggee/shell], [motex/system], [flatspace/popen], and
> [moonlib/popen], so I see little reason to make "yet another" or a
> replacement.  Instead, the idea that is most interesting to me is to make an
> object that allows you to easily run externals processes as if they were pd
> objects.  That's why STDIN, STDOUT, and STDERR would be the focus.
>
> .hc
>
>
> On Jul 8, 2010, at 12:48 PM, IOhannes m zmoelnig wrote:
>
>  On 2010-07-08 18:24, Hans-Christoph Steiner wrote:
>>
>>>
>>> Your example seems backwards to me.  STDIN is definitely a hot action,
>>>
>>
>> STDIN is far from being a hot action "definitely".
>> it's entirely at the process's disposition, whether it will do something
>> with the stdin or not.
>>
>> anyhow, whether it's backward or not depends on your pov.
>> if you see [process] as an object that interacts with system-processes,
>> then i think my approach is straight-forward.
>> if you think of the object as being a representation of the process, and
>> thus the process being just another Pd-object, then my approach looks
>> backwards.
>>
>> it seems like I (IOhannes) see this object as an interface to the
>> external world (ihde's "external" tool), whereas you (Hans-Christoph)
>> see the ibject as a way to internalize functionality into Pd (ihde's
>> tool "as an extension")
>>
>> this basically means, that the question is not solveable :-)
>>
>>
>>  and most likely the inlet that is going to be used the most.
>>>
>>
>> or not.
>> i prefer to not make too many assumptions about what the users are going
>> to do, but rather try to make the interface consistent, regardless of
>> what they are actually doing.
>>
>> i guess, people are using [shell] to startup an small script. and
>> startup the script again. and again, not worrying to much about the
>> output (mainly due to the fact how stdout/stderr are handled with
>> [shell]).
>> if [process] is gooing to replace [shell], then people are probably
>> going to use the meta-inlets and -outlets most. so...
>>
>> anyhow, the proposed object is merely an extension to the current
>> [shell]. you could even write an abstraction with the current [shell]
>> and some small wrapper-script that is more or less doing the same as
>> proposed.
>>
>> it probably would be a good idea to keep compatibility.
>>
>>
>>  I imagine
>>> many users would never change the program that is being run.  STDOUT
>>> will most likely be the main outlet used, i.e the result, so that really
>>> should be the first outlet.  The process information is meta/info/status
>>> stuff like in [hid], [comport], etc. so it should be the right outlet
>>> like them.
>>>
>>
>> i'm thinking more in terms of extensibility.
>> it seems like we all agree on the meta-outlet being a [route]able-message.
>> i think of the stdout and stderr as being messages without a given
>> selector.
>> putting the stderr and stdout before the  meta, makes it hard to add new
>> backtalk channels (e.g. pipes).
>>
>> its similar to [route] where the reject-outlet moves to the right,
>> whenever you add new selectors. it's one of the behaviours that annoyed
>> me most.
>> (so that's an argument for both sides)
>>
>>
>>> I could see combining the signal and process inlets into one second meta
>>> inlet, but it seems to me that since there are just two messages (run
>>> and signal), why not just make each have their own inlet and spare the
>>> patcher from having to build up messages as much.
>>>
>>>
>> hmm, what's harder to do: create one of those fuzzy messages, or
>> fiddling with the tiny iolets?
>> personally i think the former is simpler to do.
>> in addition, i think that the former is simpler to read as well, as it
>> is an implicit documentation)
>>
>> anyhow, i'm still convinced that creating and deleting a process (the
>> guts of this object) is "hotter" than sending data to it, which it might
>> or might not ignore.
>>
>> fgmasdr
>> IOhannes
>>
>>
>>
>
>
>
> ----------------------------------------------------------------------------
>
> All information should be free.  - the hacker ethic
>
>
>
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>



-- 
Pedro Lopes
contacto: jazz at radiozero.pt
website: http://web.ist.utl.pt/Pedro.Lopes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100708/274f5d01/attachment.htm>