mark at livecode.com
Thu Jul 23 16:39:33 CEST 2015
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 at 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 <mark at livecode.com> wrote:
>> The shell function inherits its environment from LC so there's no issue
>> 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 at 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
>>> there any issues?
>>> I'd like to try writing to a process - as I think you can do the
>>> 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
>>>> On 23 July 2015 at 08:18, David Bovill <david at viral.academy> wrote:
>>>> I'm wandering if there is a neat trick to pass data to a shell command
>>>> 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 at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode