Shell and Background Jobs

Nonsanity form at nonsanity.com
Wed Aug 24 10:32:01 EDT 2011


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 <klaus at 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
> klaus at major.on-rev.com
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



More information about the use-livecode mailing list