Re: Challenge: who can background this shell command?

[Dar Scott Consulting via use-livecode]

And an especially nice thing (I'm dreaming) would be callbacks for process and 
device I/O, maybe even some sort of unification with sockets. That would remove 
the need for polling in a send loop.



> On Aug 2, 2019, at 8:40 AM, Bob Sneidar via use-livecode 
>  wrote:
> 
> This is a fascinating thread. When all this is sussed out, a nice thing to 
> have is a function that takes arguements for all the heretofore literals, and 
> does the deed. It can be added to the master library. 
> 
> Bob S
> 
> 
>> On Aug 2, 2019, at 07:13 , Dar Scott Consulting via use-livecode 
>>  wrote:
>> 
>> I'm assuming you can send the ^c down the process connection. That is, write 
>> to the opened process. Wait a bit after that or look at the response, and 
>> then shut down the polling send-loop and then close the connection if it is 
>> not already closed, 
>> 
>> It might be that simply closing the connection to the process will cause it 
>> to shutdown gracefully. However, it would be nice to see the graceful 
>> shutdown.
>> 
>> I'd collect the reads and put them in a field on a stack just for monitoring 
>> the output. You can make it development only or you can make it part of your 
>> thing. This will allow you to see what is going on. It also allows you to 
>> see why Dar's idea of sending ^c doesn't work.
> 
> 
> ___
> 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

Re: Challenge: who can background this shell command?

[Bob Sneidar via use-livecode]

This is a fascinating thread. When all this is sussed out, a nice thing to have 
is a function that takes arguements for all the heretofore literals, and does 
the deed. It can be added to the master library. 

Bob S


> On Aug 2, 2019, at 07:13 , Dar Scott Consulting via use-livecode 
>  wrote:
> 
> I'm assuming you can send the ^c down the process connection. That is, write 
> to the opened process. Wait a bit after that or look at the response, and 
> then shut down the polling send-loop and then close the connection if it is 
> not already closed, 
> 
> It might be that simply closing the connection to the process will cause it 
> to shutdown gracefully. However, it would be nice to see the graceful 
> shutdown.
> 
> I'd collect the reads and put them in a field on a stack just for monitoring 
> the output. You can make it development only or you can make it part of your 
> thing. This will allow you to see what is going on. It also allows you to see 
> why Dar's idea of sending ^c doesn't work.


___
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

Re: Challenge: who can background this shell command?

[Dar Scott Consulting via use-livecode]

I'm assuming you can send the ^c down the process connection. That is, write to 
the opened process. Wait a bit after that or look at the response, and then 
shut down the polling send-loop and then close the connection if it is not 
already closed, 

It might be that simply closing the connection to the process will cause it to 
shutdown gracefully. However, it would be nice to see the graceful shutdown.

I'd collect the reads and put them in a field on a stack just for monitoring 
the output. You can make it development only or you can make it part of your 
thing. This will allow you to see what is going on. It also allows you to see 
why Dar's idea of sending ^c doesn't work.

> On Aug 2, 2019, at 7:13 AM, David Bovill via use-livecode 
>  wrote:
> 
> Yes - ^c to shut down... but why for update?
> 
> On Thu, 1 Aug 2019 at 19:27, Dar Scott Consulting via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> I am not familiar with hugo. Do you type a ^c to shut down hugo server? In
>> that case you might want to consider open for update.
>> 
>>> On Aug 1, 2019, at 12:19 PM, David Bovill via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> OK - I managed to get it to work with:
>>> 
>>>  - open process "/usr/local/bin/hugo server" for read
>>> 
>>> which I did not think would work due to the two word shell command.
>>> 
>>> Timing was an issue - so I had to use the method found here (thanks
>> Mark) -
>>> 
>> https://github.com/livecode/livecode/blob/develop/builder/installer_utilities.livecodescript
>>> -
>>> which uses a send in 20 milliseconds when there is a timeout. basically
>> it
>>> is complex timing logic, but more direct and probably robust than using a
>>> bunch of shell commands we put into the background. Still we have tow
>>> methods that work - restores my faith in the flexibility of Livecode!
>>> 
>>> On Thu, 1 Aug 2019 at 17:15, dsc--- via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>> 
 I feel foolish. From the dictionary:
 
 
 Note: On OS X systems, you can use the open process command to start up
>> an
 application, but not a Unix process. To work with a Unix process, use
>> the
 shell func instead.
 
 When I saw this in the Dictionary, I thought, "Oh, when did this break?"
 
 I should have thought, "Oh, yeah?"
 
 
> On Aug 1, 2019, at 10:03 AM, Dar Scott Consulting via use-livecode <
 use-livecode@lists.runrev.com> wrote:
> 
> So, this is a documentation problem?
> 
>> On Aug 1, 2019, at 9:27 AM, Mark Waddingham via use-livecode <
 use-livecode@lists.runrev.com> wrote:
>> 
>> On 2019-08-01 17:12, David Bovill via use-livecode wrote:
>>> OK - so I have it working by writing to a temporary file.
>>> Trying to redirect the output to stdout - so that shell() return the
>>> information of the background process - but this freezes:
>> 
>> Okay so given you want to read/write to the process you launched it
 seems...
>> 
>> What's wrong with open process? The *only* difference between open
 process
>> on macOS compared to Linux (and Windows) is that if you try and open
 process
>> an app-bundle (i.e. something ending with '.app') it will do the same
>> as
>> launch (as .app bundles aren't executables).
>> 
>> The installer uses open (elevated) process to communicate with an
 instance
>> of itself with elevated permissions. You can see the code for that
>> here:
>> 
>> <
 
>> https://github.com/livecode/livecode/blob/develop/builder/installer_utilities.livecodescript
> 
>> 
>> The key routines are installerRun and installerMonitor (the latter is
 used
>> to poll every 20 milliseconds to check if the child process has
 anything to
>> say).
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
>> --
>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
>> 
>> ___
>> 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 

Re: Challenge: who can background this shell command?

[David Bovill via use-livecode]

Yes - ^c to shut down... but why for update?

On Thu, 1 Aug 2019 at 19:27, Dar Scott Consulting via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I am not familiar with hugo. Do you type a ^c to shut down hugo server? In
> that case you might want to consider open for update.
>
> > On Aug 1, 2019, at 12:19 PM, David Bovill via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > OK - I managed to get it to work with:
> >
> >   - open process "/usr/local/bin/hugo server" for read
> >
> > which I did not think would work due to the two word shell command.
> >
> > Timing was an issue - so I had to use the method found here (thanks
> Mark) -
> >
> https://github.com/livecode/livecode/blob/develop/builder/installer_utilities.livecodescript
> > -
> > which uses a send in 20 milliseconds when there is a timeout. basically
> it
> > is complex timing logic, but more direct and probably robust than using a
> > bunch of shell commands we put into the background. Still we have tow
> > methods that work - restores my faith in the flexibility of Livecode!
> >
> > On Thu, 1 Aug 2019 at 17:15, dsc--- via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> I feel foolish. From the dictionary:
> >>
> >>
> >> Note: On OS X systems, you can use the open process command to start up
> an
> >> application, but not a Unix process. To work with a Unix process, use
> the
> >> shell func instead.
> >>
> >> When I saw this in the Dictionary, I thought, "Oh, when did this break?"
> >>
> >> I should have thought, "Oh, yeah?"
> >>
> >>
> >>> On Aug 1, 2019, at 10:03 AM, Dar Scott Consulting via use-livecode <
> >> use-livecode@lists.runrev.com> wrote:
> >>>
> >>> So, this is a documentation problem?
> >>>
>  On Aug 1, 2019, at 9:27 AM, Mark Waddingham via use-livecode <
> >> use-livecode@lists.runrev.com> wrote:
> 
>  On 2019-08-01 17:12, David Bovill via use-livecode wrote:
> > OK - so I have it working by writing to a temporary file.
> > Trying to redirect the output to stdout - so that shell() return the
> > information of the background process - but this freezes:
> 
>  Okay so given you want to read/write to the process you launched it
> >> seems...
> 
>  What's wrong with open process? The *only* difference between open
> >> process
>  on macOS compared to Linux (and Windows) is that if you try and open
> >> process
>  an app-bundle (i.e. something ending with '.app') it will do the same
> as
>  launch (as .app bundles aren't executables).
> 
>  The installer uses open (elevated) process to communicate with an
> >> instance
>  of itself with elevated permissions. You can see the code for that
> here:
> 
>  <
> >>
> https://github.com/livecode/livecode/blob/develop/builder/installer_utilities.livecodescript
> >>>
> 
>  The key routines are installerRun and installerMonitor (the latter is
> >> used
>  to poll every 20 milliseconds to check if the child process has
> >> anything to
>  say).
> 
>  Warmest Regards,
> 
>  Mark.
> 
>  --
>  Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>  LiveCode: Everyone can create apps
> 
>  ___
>  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
>
>
> ___
> 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

Re: Challenge: who can background this shell command?

[Dar Scott Consulting via use-livecode]

I am not familiar with hugo. Do you type a ^c to shut down hugo server? In that 
case you might want to consider open for update. 

> On Aug 1, 2019, at 12:19 PM, David Bovill via use-livecode 
>  wrote:
> 
> OK - I managed to get it to work with:
> 
>   - open process "/usr/local/bin/hugo server" for read
> 
> which I did not think would work due to the two word shell command.
> 
> Timing was an issue - so I had to use the method found here (thanks Mark) -
> https://github.com/livecode/livecode/blob/develop/builder/installer_utilities.livecodescript
> -
> which uses a send in 20 milliseconds when there is a timeout. basically it
> is complex timing logic, but more direct and probably robust than using a
> bunch of shell commands we put into the background. Still we have tow
> methods that work - restores my faith in the flexibility of Livecode!
> 
> On Thu, 1 Aug 2019 at 17:15, dsc--- via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> I feel foolish. From the dictionary:
>> 
>> 
>> Note: On OS X systems, you can use the open process command to start up an
>> application, but not a Unix process. To work with a Unix process, use the
>> shell func instead.
>> 
>> When I saw this in the Dictionary, I thought, "Oh, when did this break?"
>> 
>> I should have thought, "Oh, yeah?"
>> 
>> 
>>> On Aug 1, 2019, at 10:03 AM, Dar Scott Consulting via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> So, this is a documentation problem?
>>> 
 On Aug 1, 2019, at 9:27 AM, Mark Waddingham via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
 
 On 2019-08-01 17:12, David Bovill via use-livecode wrote:
> OK - so I have it working by writing to a temporary file.
> Trying to redirect the output to stdout - so that shell() return the
> information of the background process - but this freezes:
 
 Okay so given you want to read/write to the process you launched it
>> seems...
 
 What's wrong with open process? The *only* difference between open
>> process
 on macOS compared to Linux (and Windows) is that if you try and open
>> process
 an app-bundle (i.e. something ending with '.app') it will do the same as
 launch (as .app bundles aren't executables).
 
 The installer uses open (elevated) process to communicate with an
>> instance
 of itself with elevated permissions. You can see the code for that here:
 
 <
>> https://github.com/livecode/livecode/blob/develop/builder/installer_utilities.livecodescript
>>> 
 
 The key routines are installerRun and installerMonitor (the latter is
>> used
 to poll every 20 milliseconds to check if the child process has
>> anything to
 say).
 
 Warmest Regards,
 
 Mark.
 
 --
 Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
 LiveCode: Everyone can create apps
 
 ___
 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


___
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

Re: Challenge: who can background this shell command?

[David Bovill via use-livecode]

OK - I managed to get it to work with:

   - open process "/usr/local/bin/hugo server" for read

which I did not think would work due to the two word shell command.

Timing was an issue - so I had to use the method found here (thanks Mark) -
https://github.com/livecode/livecode/blob/develop/builder/installer_utilities.livecodescript
-
which uses a send in 20 milliseconds when there is a timeout. basically it
is complex timing logic, but more direct and probably robust than using a
bunch of shell commands we put into the background. Still we have tow
methods that work - restores my faith in the flexibility of Livecode!

On Thu, 1 Aug 2019 at 17:15, dsc--- via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I feel foolish. From the dictionary:
>
>
> Note: On OS X systems, you can use the open process command to start up an
> application, but not a Unix process. To work with a Unix process, use the
> shell func instead.
>
> When I saw this in the Dictionary, I thought, "Oh, when did this break?"
>
> I should have thought, "Oh, yeah?"
>
>
> > On Aug 1, 2019, at 10:03 AM, Dar Scott Consulting via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > So, this is a documentation problem?
> >
> >> On Aug 1, 2019, at 9:27 AM, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> On 2019-08-01 17:12, David Bovill via use-livecode wrote:
> >>> OK - so I have it working by writing to a temporary file.
> >>> Trying to redirect the output to stdout - so that shell() return the
> >>> information of the background process - but this freezes:
> >>
> >> Okay so given you want to read/write to the process you launched it
> seems...
> >>
> >> What's wrong with open process? The *only* difference between open
> process
> >> on macOS compared to Linux (and Windows) is that if you try and open
> process
> >> an app-bundle (i.e. something ending with '.app') it will do the same as
> >> launch (as .app bundles aren't executables).
> >>
> >> The installer uses open (elevated) process to communicate with an
> instance
> >> of itself with elevated permissions. You can see the code for that here:
> >>
> >> <
> https://github.com/livecode/livecode/blob/develop/builder/installer_utilities.livecodescript
> >
> >>
> >> The key routines are installerRun and installerMonitor (the latter is
> used
> >> to poll every 20 milliseconds to check if the child process has
> anything to
> >> say).
> >>
> >> Warmest Regards,
> >>
> >> Mark.
> >>
> >> --
> >> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> >> LiveCode: Everyone can create apps
> >>
> >> ___
> >> 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

Re: Challenge: who can background this shell command?

[dsc--- via use-livecode]

I feel foolish. From the dictionary:


Note: On OS X systems, you can use the open process command to start up an 
application, but not a Unix process. To work with a Unix process, use the shell 
func instead.

When I saw this in the Dictionary, I thought, "Oh, when did this break?"

I should have thought, "Oh, yeah?"


> On Aug 1, 2019, at 10:03 AM, Dar Scott Consulting via use-livecode 
>  wrote:
> 
> So, this is a documentation problem?
> 
>> On Aug 1, 2019, at 9:27 AM, Mark Waddingham via use-livecode 
>>  wrote:
>> 
>> On 2019-08-01 17:12, David Bovill via use-livecode wrote:
>>> OK - so I have it working by writing to a temporary file.
>>> Trying to redirect the output to stdout - so that shell() return the
>>> information of the background process - but this freezes:
>> 
>> Okay so given you want to read/write to the process you launched it seems...
>> 
>> What's wrong with open process? The *only* difference between open process
>> on macOS compared to Linux (and Windows) is that if you try and open process
>> an app-bundle (i.e. something ending with '.app') it will do the same as
>> launch (as .app bundles aren't executables).
>> 
>> The installer uses open (elevated) process to communicate with an instance
>> of itself with elevated permissions. You can see the code for that here:
>> 
>> 
>> 
>> The key routines are installerRun and installerMonitor (the latter is used
>> to poll every 20 milliseconds to check if the child process has anything to
>> say).
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
>> -- 
>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
>> 
>> ___
>> 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

Re: Challenge: who can background this shell command?

[Dar Scott Consulting via use-livecode]

So, this is a documentation problem?

> On Aug 1, 2019, at 9:27 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2019-08-01 17:12, David Bovill via use-livecode wrote:
>> OK - so I have it working by writing to a temporary file.
>> Trying to redirect the output to stdout - so that shell() return the
>> information of the background process - but this freezes:
> 
> Okay so given you want to read/write to the process you launched it seems...
> 
> What's wrong with open process? The *only* difference between open process
> on macOS compared to Linux (and Windows) is that if you try and open process
> an app-bundle (i.e. something ending with '.app') it will do the same as
> launch (as .app bundles aren't executables).
> 
> The installer uses open (elevated) process to communicate with an instance
> of itself with elevated permissions. You can see the code for that here:
> 
> 
> 
> The key routines are installerRun and installerMonitor (the latter is used
> to poll every 20 milliseconds to check if the child process has anything to
> say).
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> ___
> 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

Re: Challenge: who can background this shell command?

[Dar Scott Consulting via use-livecode]

This is one approach I would explore. 

1. Create a window group of one custom window using Terminal. Set it up to run 
the process and have distinctive colors and title. And, most importantly, to 
run the process.

2. Use open process to launch, not Terminal, but the group. This is the part 
where I'm very unsure. Or maybe Terminal but somehow specify group. I do have a 
vague feeling that groups are apps, but I might be off in some parallel 
universe. If not then maybe "do ... as AppleScript".

The window would have the process output, logs and so on. Maybe.

I'm not sure what the best way to shut it down would be.

> On Aug 1, 2019, at 5:55 AM, David Bovill via use-livecode 
>  wrote:
> 
> The challenge is to figure out a technique we can use in Livecode to be
> able to call long running shell processes (typically something like an http
> server process) without blocking Livecode.
> 
> To test this without asking anyone to install some cli I thought we could
> try it with an existing long running process that everyone should have in
> their terminal - vi
> 
> So how do you:
> 
> *put* shell ("vi")
> 
> I've tested this and it does not crash here on latest OSX. You do have to
> type command-period a few times to unblock things - but it is more or less
> safe to try in the message box.
> 
> I've also tried:
> 
> *put* shell ("vi &")
> 
> The aim is to out the process in the background, or some other technique -
> like make a bash script that contains the line that launches vi (ie "vi") -
> or perhaps uses screen or tmux, or some trick in Livecode (open process
> does not work for this on OSX)...
> 
> Who can crack this tricky nut :)
> ___
> 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

Re: Challenge: who can background this shell command?

[David Bovill via use-livecode]

OK - will try. My first attempt launched the process, but the server did
not work and the openproccessids = 0

But will try to do this properly and report back - thanks Mark :)

On Thu, 1 Aug 2019 at 16:27, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2019-08-01 17:12, David Bovill via use-livecode wrote:
> > OK - so I have it working by writing to a temporary file.
> >
> > Trying to redirect the output to stdout - so that shell() return the
> > information of the background process - but this freezes:
>
> Okay so given you want to read/write to the process you launched it
> seems...
>
> What's wrong with open process? The *only* difference between open
> process
> on macOS compared to Linux (and Windows) is that if you try and open
> process
> an app-bundle (i.e. something ending with '.app') it will do the same as
> launch (as .app bundles aren't executables).
>
> The installer uses open (elevated) process to communicate with an
> instance
> of itself with elevated permissions. You can see the code for that here:
>
> <
> https://github.com/livecode/livecode/blob/develop/builder/installer_utilities.livecodescript
> >
>
> The key routines are installerRun and installerMonitor (the latter is
> used
> to poll every 20 milliseconds to check if the child process has anything
> to
> say).
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> ___
> 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

Re: Challenge: who can background this shell command?

[Mark Waddingham via use-livecode]

On 2019-08-01 17:12, David Bovill via use-livecode wrote:

OK - so I have it working by writing to a temporary file.

Trying to redirect the output to stdout - so that shell() return the
information of the background process - but this freezes:


Okay so given you want to read/write to the process you launched it 
seems...


What's wrong with open process? The *only* difference between open 
process
on macOS compared to Linux (and Windows) is that if you try and open 
process

an app-bundle (i.e. something ending with '.app') it will do the same as
launch (as .app bundles aren't executables).

The installer uses open (elevated) process to communicate with an 
instance

of itself with elevated permissions. You can see the code for that here:



The key routines are installerRun and installerMonitor (the latter is 
used
to poll every 20 milliseconds to check if the child process has anything 
to

say).

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: Challenge: who can background this shell command?

[David Bovill via use-livecode]

OK - so I have it working by writing to a temporary file.

Trying to redirect the output to stdout - so that shell() return the
information of the background process - but this freezes:


   - *put* shell ("hugo server 2>&1 &") into launchResult

Even though:


   - command 2>&1 &

redirects stderr to stdout?

This is a working solution which writes to a temporary file - then reads
from that file till the end of the message in order to get hold of the
result:

> *command* hugo_BackgroundServer projectName
> *put* env_GetFolder (projectName) into projectFolder
> *set* the defaultfolder to projectFolder
>
> *--**put* the tempname & ".txt" into someFile
> *put* "hugo server >" && someFile && "2>&1 &" into tShell
> *put* shell (tShell) into shellResult
>
> *-- can take some time to start up so let's read from file till the end*
>   _ReadFromFile someFile
> *put* the result into fileContents
> *return* fileContents
> *end* hugo_BackgroundServer
>


> *private* *command* _ReadFromFile someFile
> *open* file someFile for
> *read**read* from file someFile until "Press Ctrl+C to stop"
> *put* it into fileContents
> *close* file someFile
> *return* fileContents
> *end* _ReadFromFile


On Thu, 1 Aug 2019 at 14:55, Matthias Rebbe via use-livecode <
use-livecode@lists.runrev.com> wrote:

> put "/users/matthias/downloads/temp/MailHog >
> /users/matthias/downloads/temp/hubbabubba.txt 2>&1 &" into tShell
>
> -- above redirects into file and then don´t ask me.. ;)
> put shell(tShell)
> answer URL "file:/users/matthias/downloads/temp/hubbabubba.txt"
> -- answer dialog shows content of file, which contains in my case the
> address and port it was binded to.
>
>
> 2019/08/01 15:46:01 Using in-memory storage
> 2019/08/01 15:46:01 [SMTP] Binding to address: 0.0.0.0:1025
> [HTTP] Binding to address: 0.0.0.0:8025
> 2019/08/01 15:46:01 Serving under http://0.0.0.0:8025/ <
> http://0.0.0.0:8025/>
> Creating API v1 with WebPath:
> Creating API v2 with WebPath:
> [APIv2] GET /api/v2/messages
> [APIv2] GET /api/v2/jim
> [APIv2] GET /api/v2/websocket
> [APIv1] KEEPALIVE /api/v1/events
>
>
> Be aware, that the background process runs untill you kill it from the
> shell.
>
> Regards,
>
> Matthias
>
>
> Matthias Rebbe
>
> free tools for Livecoders:
> InstaMaker 
> WinSignMaker Mac 
>
> > Am 01.08.2019 um 15:20 schrieb David Bovill via use-livecode <
> use-livecode@lists.runrev.com >:
> >
> > That works in the message box - thanks Matthias.
> >
> > The only thing is I can't (yet) tell what port the server is running on
> - I
> > can see from the terminal (using pgrep) the process id of the started
> > server - but it does not appear to be serving correctly on the default
> > server port...
> >
> > Do you think there is a way to redirect the output to Livecode's result
> or
> > it variable - I seem to remember that there have been some changes to
> that
> > to make such a construction possible in Livecode - alternatively maybe
> the
> > output can be directed to a temporary file instead of " /dev/null"???
> >
> > Nearly there :)
> >
>
>
>
> Matthias Rebbe
>
> free tools for Livecoders:
> InstaMaker 
> WinSignMaker Mac 
> ___
> 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

Re: Challenge: who can background this shell command?

[Matthias Rebbe via use-livecode]

Aaah, it seems the server has absorbed the greater character.


command > filename  redirects the stdout to a file, so any output from the 
command will be redirected to the file
2 > &1  redirects stderr to stdout, which in my case is 
redirected to file hubbabubba.txt

the traling &   puts the command in the background


Please excuse my multiple postings.

> Am 01.08.2019 um 16:39 schrieb Matthias Rebbe via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> I just noticed that my last post was not easy to read
> 
> I´ve used the following shell command to redirect to a file instead of to 
> /dev/null
> 
> /users/matthias/downloads/temp/MailHog > 
> /users/matthias/downloads/temp/hubbabubba.txt 2>&1 &
> 
> 
> My script looked like this
> 
> put "/users/matthias/downloads/temp/MailHog > 
> /users/matthias/downloads/temp/hubbabubba.txt 2>&1 &" into tShell
> put shell(tShell)
> answer URL "file:/users/matthias/downloads/temp/hubbabubba.txt"
> 
> 
> The answer dialog showed up immediately after executing the shell and it 
> contained the redirected stdout data.
> 
> 
> 
> 
>> filename redirects the stdout to a file
> 2 > &1redirects stderr to stdout, which in my case is 
> redirected to file hubbabubba.txt
> 
> & puts the command in the background
> 
> 
> 
> 
> ___
> 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

Re: Challenge: who can background this shell command?

[Matthias Rebbe via use-livecode]

I just noticed that my last post was not easy to read

I´ve used the following shell command to redirect to a file instead of to 
/dev/null

/users/matthias/downloads/temp/MailHog > 
/users/matthias/downloads/temp/hubbabubba.txt 2>&1 &


My script looked like this

put "/users/matthias/downloads/temp/MailHog > 
/users/matthias/downloads/temp/hubbabubba.txt 2>&1 &" into tShell
put shell(tShell)
answer URL "file:/users/matthias/downloads/temp/hubbabubba.txt"


The answer dialog showed up immediately after executing the shell and it 
contained the redirected stdout data.




> filename  redirects the stdout to a file
2 > &1  redirects stderr to stdout, which in my case is 
redirected to file hubbabubba.txt

 &  puts the command in the background




___
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

Re: Challenge: who can background this shell command?

[Matthias Rebbe via use-livecode]

put "/users/matthias/downloads/temp/MailHog > 
/users/matthias/downloads/temp/hubbabubba.txt 2>&1 &" into tShell

-- above redirects into file and then don´t ask me.. ;)
put shell(tShell)
answer URL "file:/users/matthias/downloads/temp/hubbabubba.txt"
-- answer dialog shows content of file, which contains in my case the address 
and port it was binded to.


2019/08/01 15:46:01 Using in-memory storage
2019/08/01 15:46:01 [SMTP] Binding to address: 0.0.0.0:1025
[HTTP] Binding to address: 0.0.0.0:8025
2019/08/01 15:46:01 Serving under http://0.0.0.0:8025/ 
Creating API v1 with WebPath: 
Creating API v2 with WebPath: 
[APIv2] GET /api/v2/messages
[APIv2] GET /api/v2/jim
[APIv2] GET /api/v2/websocket
[APIv1] KEEPALIVE /api/v1/events


Be aware, that the background process runs untill you kill it from the shell.

Regards,

Matthias


Matthias Rebbe

free tools for Livecoders:
InstaMaker 
WinSignMaker Mac 

> Am 01.08.2019 um 15:20 schrieb David Bovill via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> That works in the message box - thanks Matthias.
> 
> The only thing is I can't (yet) tell what port the server is running on - I
> can see from the terminal (using pgrep) the process id of the started
> server - but it does not appear to be serving correctly on the default
> server port...
> 
> Do you think there is a way to redirect the output to Livecode's result or
> it variable - I seem to remember that there have been some changes to that
> to make such a construction possible in Livecode - alternatively maybe the
> output can be directed to a temporary file instead of " /dev/null"???
> 
> Nearly there :)
> 



Matthias Rebbe

free tools for Livecoders:
InstaMaker 
WinSignMaker Mac 
___
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

Re: Challenge: who can background this shell command?

[David Bovill via use-livecode]

That works in the message box - thanks Matthias.

The only thing is I can't (yet) tell what port the server is running on - I
can see from the terminal (using pgrep) the process id of the started
server - but it does not appear to be serving correctly on the default
server port...

Do you think there is a way to redirect the output to Livecode's result or
it variable - I seem to remember that there have been some changes to that
to make such a construction possible in Livecode - alternatively maybe the
output can be directed to a temporary file instead of " /dev/null"???

Nearly there :)



On Thu, 1 Aug 2019 at 13:39, Matthias Rebbe via use-livecode <
use-livecode@lists.runrev.com> wrote:

> This let me run it without blocking. It redirects the stdout and stderr if
> i recall it correct.
>
> "vi > /dev/null 2>&1 &"
>
>
>
> Matthias Rebbe
>
> free tools for Livecoders:
> InstaMaker 
> WinSignMaker Mac 
>
> > Am 01.08.2019 um 13:55 schrieb David Bovill via use-livecode <
> use-livecode@lists.runrev.com >:
> >
> > The challenge is to figure out a technique we can use in Livecode to be
> > able to call long running shell processes (typically something like an
> http
> > server process) without blocking Livecode.
> >
> > To test this without asking anyone to install some cli I thought we could
> > try it with an existing long running process that everyone should have in
> > their terminal - vi
> >
> > So how do you:
> >
> > *put* shell ("vi")
> >
> > I've tested this and it does not crash here on latest OSX. You do have to
> > type command-period a few times to unblock things - but it is more or
> less
> > safe to try in the message box.
> >
> > I've also tried:
> >
> > *put* shell ("vi &")
> >
> > The aim is to out the process in the background, or some other technique
> -
> > like make a bash script that contains the line that launches vi (ie
> "vi") -
> > or perhaps uses screen or tmux, or some trick in Livecode (open process
> > does not work for this on OSX)...
> >
> > Who can crack this tricky nut :)
> > ___
> > 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

Re: Challenge: who can background this shell command?

[Matthias Rebbe via use-livecode]

I´ve tried my suggestion now with a freshly installed version of Mailhog. Just 
to make sure that it works with a background process. Maihog normally has to be 
started from Shell and rund as long as the terminal window stays open.

When executing this script
put "/users/matthias/downloads/temp/MailHog > /dev/null 2>&1 &" into tShell

put shell(tShell)

answer 1


MailHog started and runs in background while the script continued and showed 
the answer dialog.

Regards,
Matthias


Matthias Rebbe

free tools for Livecoders:
InstaMaker 
WinSignMaker Mac 

> Am 01.08.2019 um 14:39 schrieb Matthias Rebbe via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> This let me run it without blocking. It redirects the stdout and stderr if i 
> recall it correct.
> 
> "vi > /dev/null 2>&1 &"
> 
> 
> 
> Matthias Rebbe
> 
> free tools for Livecoders:
> InstaMaker  >
> WinSignMaker Mac  >
> 
>> Am 01.08.2019 um 13:55 schrieb David Bovill via use-livecode 
>> mailto:use-livecode@lists.runrev.com> 
>> > >>:
>> 
>> The challenge is to figure out a technique we can use in Livecode to be
>> able to call long running shell processes (typically something like an http
>> server process) without blocking Livecode.
>> 
>> To test this without asking anyone to install some cli I thought we could
>> try it with an existing long running process that everyone should have in
>> their terminal - vi
>> 
>> So how do you:
>> 
>> *put* shell ("vi")
>> 
>> I've tested this and it does not crash here on latest OSX. You do have to
>> type command-period a few times to unblock things - but it is more or less
>> safe to try in the message box.
>> 
>> I've also tried:
>> 
>> *put* shell ("vi &")
>> 
>> The aim is to out the process in the background, or some other technique -
>> like make a bash script that contains the line that launches vi (ie "vi") -
>> or perhaps uses screen or tmux, or some trick in Livecode (open process
>> does not work for this on OSX)...
>> 
>> Who can crack this tricky nut :)
>> ___
>> 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

Re: Challenge: who can background this shell command?

[Matthias Rebbe via use-livecode]

This let me run it without blocking. It redirects the stdout and stderr if i 
recall it correct.

"vi > /dev/null 2>&1 &"



Matthias Rebbe

free tools for Livecoders:
InstaMaker 
WinSignMaker Mac 

> Am 01.08.2019 um 13:55 schrieb David Bovill via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> The challenge is to figure out a technique we can use in Livecode to be
> able to call long running shell processes (typically something like an http
> server process) without blocking Livecode.
> 
> To test this without asking anyone to install some cli I thought we could
> try it with an existing long running process that everyone should have in
> their terminal - vi
> 
> So how do you:
> 
> *put* shell ("vi")
> 
> I've tested this and it does not crash here on latest OSX. You do have to
> type command-period a few times to unblock things - but it is more or less
> safe to try in the message box.
> 
> I've also tried:
> 
> *put* shell ("vi &")
> 
> The aim is to out the process in the background, or some other technique -
> like make a bash script that contains the line that launches vi (ie "vi") -
> or perhaps uses screen or tmux, or some trick in Livecode (open process
> does not work for this on OSX)...
> 
> Who can crack this tricky nut :)
> ___
> 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

Challenge: who can background this shell command?

[David Bovill via use-livecode]

The challenge is to figure out a technique we can use in Livecode to be
able to call long running shell processes (typically something like an http
server process) without blocking Livecode.

To test this without asking anyone to install some cli I thought we could
try it with an existing long running process that everyone should have in
their terminal - vi

So how do you:

*put* shell ("vi")

I've tested this and it does not crash here on latest OSX. You do have to
type command-period a few times to unblock things - but it is more or less
safe to try in the message box.

I've also tried:

*put* shell ("vi &")

The aim is to out the process in the background, or some other technique -
like make a bash script that contains the line that launches vi (ie "vi") -
or perhaps uses screen or tmux, or some trick in Livecode (open process
does not work for this on OSX)...

Who can crack this tricky nut :)
___
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