Hem
Forum
Donera
Webbutik

Översikt
Nya inlägg
Obesvarade trådar
Sök i forum

Mjukvara och tjänster
Programmering och utveckling

Kan skript exekvera annat skript utan att vänta på resultatet?

Tråden skapades 2009-02-16 och har fått 10 svar. Det senaste inlägget skrevs 2009-02-16.

2009-02-16 07:29

Baron
Medlem ●
2009-02-16 07:29

Jag har ett InDesignskript som bland annat sparar en kopia av det aktiva dokumentet på en filserver. Det tar ofta ganska lång tid att kopiera detta dokument, så jag undrra om det går att be tex Finder att utföra den koiperingen utanför InD-skriptet.
InD stannar upp under hela kopieringsprocessen trots att det är ett shellscript som kopierar (eftersom skriptet körs från InD, gissar jag).

Anmäl Ändra Gilla Svara

2009-02-16 10:19

frazze
Medlem ●
Sollentuna
2009-02-16 10:19

Du ska be att skriptet körs i bakgrunden (eller motsvarande begrepp i InD). Som jag förstår det nu så startar InD-processen en ny process med skriptet och sitter fint och väntar på att det avslutas. Titta i en traditionell *NIX-bok om hur man startar andra skript utan att vänta på att dom avslutas/terminerar. Överför denna teknik till InD.

Anmäl Ändra Gilla Svara

2009-02-16 14:24

Taz_1999
Medlem ●
Stockholm
2009-02-16 14:24

Inget program kan hantera filer som är öppna i ett annat program, så heller inte Applescript eller program för säkerhetskopiering mfl.

Så om filen är öppen i Indesign kan inte Applescript instruera Finder att kopiera den någonstans. Den måste stängas först.

Anmäl Ändra Gilla Svara

2009-02-16 17:44

Baron
Medlem ●
2009-02-16 17:44

mäh, det kan väl inte stämma? Man man ju be Finder att flytta eller kopiera en fil vart som helst trots att den är öppen i ett annat program.
Min kopiering görs med cp från en lokal volym till en nätverksvolym. Det är den kopieringen jag vill ska utföras i bakgrunden.

Anmäl Ändra Gilla Svara

2009-02-16 19:06

ntity
Medlem ●
Stockholm
2009-02-16 19:06

$ cp file file2 &

Detta spawnar cp i ett subshell och returnerar omedelbart till orginal shellet, dvs fortsätter med den exekvering som du håller på med.

Dock kommer du få problem om scriptet terminerar före kopieringen är klar, då "föräldern" försvinner så kommer även copy kommandot att dödas, detta löser du med.

$ nohup cp file file2 &

För att ignorera externa HUP signaler, KILL, TERM etc kommer dock gå igenom eftersom du inte fångar dem, men det vill du inte..

Om du inte är intresserad av eventuell logg om fel etc från cp så styr om std/err-out för att slippa skapandet av en nohup.out fil.

$ nohup cp file file2 >/dev/null 2>&1 &

Anmäl Ändra Gilla Svara

2009-02-16 19:32

Richard Rönnbäck
Medlem ●
Norrtälje
2009-02-16 19:32

Eller så gör man det på det rätta sättet

AppleScript bygger på att olika processer skickar AppleEvents mellan sig. Normalt sett väntar AS på att den mottagande processen ska returnera ett resultat, men det är något man enkelt kan ändra, genom att omge det kommandot man vill ska utföras utan att resultatet inväntas med

Ignoring application responses
-- koden som man inte vill vänta på svar från
-- i ditt fall fildupliceringen
end ignoring application responses

På snarlikt sätt kan man också ange hur lång tid svaret får ta, genom att ange

with timeout of 600 seconds --eller hur länge man nu vill
--koden som får ta så lång tid
end with timeout

Däremot finns det en risk i det här, och det är om användaren hinner spara ändringar i dokumentet innan kopieringen hunnit klart.

Jag har faktiskt ingen aning om vad som händer då, om Finder (eller cp) är smart nog att läsa in hela filen innan kopieringen påbörjas

Anmäl Ändra Gilla Svara

2009-02-16 21:11

Baron
Medlem ●
2009-02-16 21:11

Ursprungligen av Richard Rönnbäck:

Eller så gör man det på det rätta sättet

Ignoring application responses
-- koden som man inte vill vänta på svar från
-- i ditt fall fildupliceringen
end ignoring application responses

På snarlikt sätt kan man också ange hur lång tid svaret får ta, genom att ange

with timeout of 600 seconds --eller hur länge man nu vill
--koden som får ta så lång tid
end with timeout

Däremot finns det en risk i det här, och det är om användaren hinner spara ändringar i dokumentet innan kopieringen hunnit klart.

Jag har faktiskt ingen aning om vad som händer då, om Finder (eller cp) är smart nog att läsa in hela filen innan kopieringen påbörjas

Gå till inlägget

Det verkar som att man måste skriva

Ignoring application responses
-- koden som man inte vill vänta på svar från
end ignoring

Anmäl Ändra Gilla Svara

2009-02-16 22:46

ntity
Medlem ●
Stockholm
2009-02-16 22:46

Ursprungligen av Richard Rönnbäck:

Eller så gör man det på det rätta sättet

Ignoring application responses
-- koden som man inte vill vänta på svar från
-- i ditt fall fildupliceringen
end ignoring application responses

På snarlikt sätt kan man också ange hur lång tid svaret får ta, genom att ange

with timeout of 600 seconds --eller hur länge man nu vill
--koden som får ta så lång tid
end with timeout

Däremot finns det en risk i det här, och det är om användaren hinner spara ändringar i dokumentet innan kopieringen hunnit klart.

Jag har faktiskt ingen aning om vad som händer då, om Finder (eller cp) är smart nog att läsa in hela filen innan kopieringen påbörjas

Gå till inlägget

Jag skriver aldrig Applescript, endast shellscript snabbare och mycker mer portabelt, men det beror ju på användningsområdet så.

Skulle väll iofs påstå att det är kraftfullare med eftersom man kan använda Applescripts styrka med inbyggt i de shellscript som man gör, men som sagt, det beror på hur man använder det.

Anmäl Ändra Gilla Svara

2009-02-16 19:54

Taz_1999
Medlem ●
Stockholm
2009-02-16 19:54

Jag har försökt mycket och länge med att kopiera filer med Applescript som kan vara öppna av användare. Filerna ligger på en Mac OS X Server och Applescriptet jag körde låg på en annan dator än servern. Fick massa besynnerliga fel (filer både existerade och inte existerade, samtidigt mm).

Det slutade med att jag dels kollade att ändringsdatum var minst en timme sedan och sedan skrev jag om både kollen av ändringsdatum och kopiering så att Applescriptet istället för att använda Finders kommandon för sådana saker, använde unixkommandon. Det fungerade. Scriptet kördes sedan en gång per timme med Script Timer.

Jag var ganska säker på problemen med mitt ursprungliga script (baserat på Finder) hade att göra med att öppna filer inte får hanteras av andra program, men ok då, vill man tro att det är ok, så tro det då!

Kan nämna som ett exempel att många backup-programvaror säger sig göra backup av de databas-filer som är öppna i FileMaker Server (man får inga felmeddelanden), men de gör det alltså inte. De backupfilerna går inte att läsa. Det är därför FileMaker Server tex har en egen inbyggd backup-rutin, just för att operativsystemet inte tillåter flera program att läsa samma fil.

Baron: Att du kan flytta runt en fil i Finder betyder dock inte att allt är bra med filen, prova att öppna samma fil i tex Word och Textredigeraren, ändra i båda, flytta filen, spara och se vad som händer.

Anmäl Ändra Gilla Svara

2009-02-16 20:58

#10

Baron
Medlem ●
2009-02-16 20:58

Taz, det är InDesignanvändare som sparar undan backupkopior på en filserver, så risken att det blir konflikt har hittills inte varit ett problem. Skriptet har körts ungefär 25.000 gånger i månaden i två år...

Annars kanske man skulle skriva in en liten försiktighetsåtgärd:

property myStartTime : 0
set myFullDate to (current date)
set myCurrentTime to time of myFullDate
if myCurrentTime < (myStartTime + 10) then
	display alert "För att kopieringen ska bli säkrare kan du inte spara oftare än var tionde sekund." & return & return & "(Sparar du oftare bör du överväga att uppsöka företagshälsovården.)"
else
	set myStartTime to time of myFullDate
	-- kopiera fil
end if