Das "&" funktioniert schon, ABER...
Wenn du dem Shellskript als Zeilenende das & mitgibst, dann läuft ein Hintergrundprozess im Shellskript. Es ist "sh" und nicht AppleSkript, das einfach weitermacht und den Befehl im Hintergrund weiter ausführt. (Aufgemerkt!)
AppleScript selbst hat also eigentlich gar keine richtige Kontrolle über den Hintergrundprozess, diese "Job Control" muss die Unix-Shell selbst erledigen. Und das macht sie auch, aber die Sache hat einen kleinen Haken, und zwar im Detail, wie sie das eigentlich macht.
Jedes Programm das du in sh startest bekommt mehrere offene "Dateideskriptoren" mit auf seinen Weg, namely STDOUT, STDIN und STDERR. Auch die Shell sh selbst besitzt sowas, und über diese eigenen Kanäle STDOUT und STDERR gibt sie an das aufrufende AppleScript seine ganzen Textausgaben wieder zurück.
Wenn sh (oder eine andere Bourneshell) selbst irgendwelche Prozesse in den Hintergrund zwingt, dann
unterdrückt sie deren Ausgaben über diese Kanäle ("Pipes") nur, die Dateien sind dennoch offen weil diese Prozesse sonst nicht arbeiten könnten (mit Fehler abkacken).
Wenn der HG-Prozess nun beendet wird während sh immer noch aktiv ist (und ihre eigene Job Control funktionsfähig), dann schliesst sie die STDERR und STDOUT Deskriptoren dieses Prozesses wieder, aber eben erst bei dieser Beendigung, nicht früher.
Was du nun tun möchtest ist das Beenden der sh, noch bevor das darin "enthaltene" Kommando sich beendet. Wenn du zB im Terminal sowas machst, dann "erbt" der Prozess der übergeordneten Hierarchiestufe die Verantwortung für die noch herumschwirrenden HG-Prozesse von der sh. Im Terminal fällt die Verantwortung dabei an den "Oberaufseher launchd" zurück. Anstatt der sh-Instanz, die jetzt nicht mehr existiert, kümmert eben er sich nun darum, dass sämtliche offenen "Rohre" zu gegebener Zeit auch wieder "dicht" gemacht werden.
Bei "do shell script..." im AppleScript funktioniert das aber leicht anders, hier ist es das gesamte AppleScript-Subsystem selbst das diese Verantwortung übertragen bekommt. Und AppleScript hat die Angewohnheit sich selbst nicht beenden zu können solange da noch irgendwas offenes vorhanden ist. Du kannst es auch nicht dazu zwingen, es gibt hierfür keinen Weg.
Das AS
kann sich einfach nicht beenden, solange noch irgendein im Hintergrund existierender Unix-Prozess existiert der von dort initiiert wurde. Es KÖNNTE ja später noch dazu kommen, dass diese Prozesse ihre offenen Kanäle doch noch für irgendwas brauchen, von der ganzen Unix-Geschichte von Signalen, Traps usw hat AS gar keine richtige Ahnung und kann sich nur auf eine einzige Art und Weise um seine Aufgabe kümmern: ABWARTEN. Punkt.
Problem verstanden?
Gut, dann darfst du es jetzt lösen (und beim nächsten mal wieder daran denken).
Da AS zu "dumm" ist die noch offenen Dateien zu schliessen, musst du selbst schon beim Aufruf deiner Programme dafür sorgen dass diese gar nicht erst geöffnet werden, bzw bleiben. Der Trick dazu ist simpel:
Umleitung.
Und zwar Umleitung entweder in eine beliebige Datei (meist auf der HD, zB irgendwo ins "/tmp" Dateigrab), oder auch einfach ins Nirvana, wenn du den Output sowieso nicht brauchst. Bei den per Unix-Shell-Mechanismus umgeleiteten Kanälen ("> >> >| redirection") ist nämlich plötzlich dein "sqlhacker" selbst in der Lage, das wieder zu schliessen. Das Problem der Verantwortung eines anderen Prozesses tritt also nicht mehr auf.
How2make it work:
Code:
[size="-2"]on open theFiles
repeat with oneFile in theFiles
set theFile to (POSIX path of oneFile as text)
do shell script "/opt/local/bin/sqliteman " & quoted form of theFile[COLOR="blue"] & " &>/dev/null &"[/COLOR]
end repeat
end open[/size]
Das "&>" verbindet gleichzeitig sowohl STDOUT als auch STDERR deines Benutzerprozesses mit der imaginären Datei "/dev/null", die an AppleScript gar nicht mehr weitergemeldet werden muss. Bingo.
War mir ein Vergnügen.
