Re: Challenge: who can background this shell command?

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

Re: Challenge: who can background this shell command?

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: >

Re: Challenge: who can background this shell command?

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

Re: Challenge: who can background this shell command?

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

Re: Challenge: who can background this shell command?

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"

Re: Challenge: who can background this shell command?

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) -

Re: Challenge: who can background this shell command?

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

Re: Challenge: who can background this shell command?

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()

Re: Challenge: who can background this shell command?

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

Re: Challenge: who can background this shell command?

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

Re: Challenge: who can background this shell command?

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

Re: Challenge: who can background this shell command?

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

Re: Challenge: who can background this shell command?

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

Re: Challenge: who can background this shell command?

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

Re: Challenge: who can background this shell command?

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

Re: Challenge: who can background this shell command?

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

Re: Challenge: who can background this shell command?

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

Re: Challenge: who can background this shell command?

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

Challenge: who can background this shell command?

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