Thanks, Klaus.
I had tried wrapping my call in a .sh file (made outside of LC) but I then
launched it with a shell command and another "&" just to see if it was the
command itself that was somehow aborting with the backgrounding behavior.
But despite and & both inside and out, the shell command would still wait
for the whole process to complete before returning.
I hadn't tried it with "launch" though. That should give similar results to
launching an AppleScript, though maybe it won't bring a shell window to the
foreground? If so, that would be the method to use.
I'm a bit curious about the character replacement you're doing for the
returns. I can see replacing carriage returns (13) with linefeeds (10), but
replacing them with backspaces (8) seems VERY strange. I can't see how/why
that would work.
But I'll give that a try. If it doesn't knock LiveCode from the frontmost
application spot, that's better than using AppleScript, and being able to
generate it inside LC is a plus too. I'll go test that later. :)
~ Chris Innanen
~ Nonsanity
On Wed, Aug 24, 2011 at 5:48 AM, Klaus on-rev <kl...@major.on-rev.com>wrote:
> Hi Chris,
>
> Am 23.08.2011 um 22:32 schrieb Nonsanity:
>
> > Now that the earth has stopped shaking here, I can re-write this email. I
> > lost the first rendition by switching to the USGS web site for details on
> > the 5.9 earthquake we had nearby (geographically speaking). Anyway...
> >
> > I've been trying to do some shell() background jobs on the Mac, ones that
> > will take a long time to execute. Sometimes adding the & to the end of
> the
> > string I pass to shell() makes shell return immediately, and I can see
> the
> > task started in Process Monitor. Other times shell keeps control until
> the
> > task is done (or I kill it in frustration).
> >
> > I made a new stack with a button and a field and put this script in the
> > button:
> >
> > on mouseup
> > put "start" into fld 1
> > get shell( "sleep 5 &" )
> > put "end" into fld 1
> > end mouseup
> >
> > Now that SHOULD background the sleep so that shell returns immediately
> and
> > replaces the "start" with "end" in fld 1 so that you never really even
> see
> > the "start". But I get 5 seconds of "start" before "end" appears.
> >
> > In Terminal, the same "sleep 5 &" will return immediately, while leaving
> off
> > the "&" will make it delay 5 seconds before getting a new prompt.
> >
> > At the same time, I have a big, complex HandBrake command that DOES
> > background correctly. I can't figure out why that one works consistently.
> :(
> >
> > Has anyone else researched this and found some pertinent facts they can
> > share?
>
> yes, I have been "backgounding" shell calls in the past with a "*.sh" FILE!
> This is a script that starts some copy action in the background:
>
> command mkCopy tList
>
> ## tList contains a CR and TAB delimited list of files to be copied:
> ## item 1 of each line is the SOURCE file, item 2 the TARGET file
> set itemdel to TAB
>
> ## Prepare the BATCH file
> put the tempname & ".sh" into shell_file
> set the filetype to ""
> put "#!/bin/sh" & CR & CR into shell_liste
> repeat for each line i in kopierliste
> put "ditto" && q(item 1 of i) && q(item 2 of i) & CR after shell_liste
> end repeat
> delete char -1 of shell_liste
>
> ## NO "normal" CR in shell files! Found this hint somewhere on the net
> replace numtochar(13) with numtochar(8) in shell_liste
>
> ## Therefore BINFILE!
> put shell_liste into url("binfile:" & shell_file)
> if the result <> empty then
> answer "Problem:" && the result
> exit mkCopy
> end if
>
> ## Need to make the file executable
> get shell("chmod 777" && q(shell_file))
> if the result <> empty then
> answer "Problem:" && the result
> exit mkCopy
> end if
>
> ## The OS will know how to handle SH files!
> launch shell_file
> end mkCopy
>
> This will copy all files in the background, but haven't used it for a
> couple of years.
> You get the picture!
>
> At least worth a try :-)
>
> > ~ Chris Innanen
> > ~ Nonsanity
>
> Best
>
> Klaus
>
> --
> Klaus Major
> http://www.major-k.de
> kl...@major.on-rev.com
>
>
> _______________________________________________
> 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
