On the contrary, open process can be used in a non-blocking way - although you
do need to poll using read until empty (which returns all available data at
that point).
(The read from process command could do with a callback form really - like read
from socket has).
I've done this before - you have a controlling process which opens other
processes, then every polling interval (100ms say) it does read from empty on
all of them then processes any data which comes from them. When a process
returns eof from the read it means the process has finished.
Sent from my iPhone
> On 23 Jul 2015, at 13:57, David Bovill <david@viral.academy> wrote:
>
> Thanks Mark. I'm going to give "open process for update" a spin. Is this
> something that you would consider robust enough to be used in a long
> running server type context?
>
> So we can have a Livecode server communicating with these processes and
> serving out processed results over sockets to a web server for instance -
> or is this something we should only consider for short run - get the
> process up and running then shut it down interactions?
>
> I guess it is a blocking operation...
>
>> On 23 July 2015 at 13:33, Mark Waddingham <m...@livecode.com> wrote:
>>
>> The shell function inherits its environment from LC so there's no issue
>> here.
>>
>> You can also use open process for update, write to it then read from it.
>>
>> The elevated version of open process prompts for authentication and then
>> runs the process as administrator. It uses system support for UI based
>> prompting - it works well on windows and Mac (which have builtin support),
>> Linux support is a little more patchy as it requires gksu (iirc) to work.
>>
>> Sent from my iPhone
>>
>>> On 23 Jul 2015, at 08:28, David Bovill <david@viral.academy> wrote:
>>>
>>> Well I found one - though I'm not sure it is strictly legal:
>>>
>>> put "<some text" into $LIVECODEVAR
>>>> put shell ("echo $LIVECODEVAR | shellThing -q")
>>>
>>> which is great. I don't "think" this pollutes the environment, as AFAIK
>>> shell() is in it's own space (like opening a tab in the terminal) - but
>> are
>>> there any issues?
>>>
>>> I'd like to try writing to a process - as I think you can do the
>> equivalent
>>> of shell with a commandline tool. Does anyone have an example - and can
>>> explain "elevated" process - the docs are a bit sparse. Is elevated like
>>> sudo?
>>>
>>>
>>>> On 23 July 2015 at 08:18, David Bovill <david@viral.academy> wrote:
>>>>
>>>> I'm wandering if there is a neat trick to pass data to a shell command
>> via
>>>> STDIN. The only thing I know how to do is either:
>>>>
>>>> 1. Write a bash script that accepts an input param and call this
>>>> 2. put shell ("echo 'some text' | shellThing")
>>>>
>>>> Is there a neater way?
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
