- love
- Medlem ●
jag vet iofs inte hur man grejar den första delen av problemet men ett applescript drar du iaf igång via "osascript" så kika på man osascript
för att köra applescript via cron kan man göra såhär :osascript -e 'tell application "Program" to dotheshit'
inte så intressant i detta fall kanske
kanske bättre åt detta hållet
cron > shellscript >applescript
och det är bara själva shellscriptet som jag inte har nån smart lösning på
surfar runt lite och kollar!
Nu sitter jag inte framför min mac så jag är inte säker på parametrarna men på OpsnBSD skulle shell-scriptet se ut såhär:
top -d 1 -o cpu | grep --after-context=1 PID
lite skakigt att greppa på PID kanske... men du hajjar principen... typ...
Jag gjorde såhär
ps -xopid,%cpu | grep PID ?
verkar ge rätt output men hur göra med resten
om cpu < 50 osascript -e 'tell application "Program" to dotheshit' ??
Kanske man ska skippa cron och göra ett loopat script som frågar efter PID vid start
verkar mer flexibelt...
#!/bin/sh # "top -ocpu -l2 -s0 | grep -A5 PID" ger en output som ser ut så här: # # lincoln:~ wire$ top -ocpu -l2 -s0 | grep -A5 PID # PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE # 2214 grep 0.0% 0:00.00 1 11 15 56K 416K 344K 17.7M # 2213 top 0.0% 0:00.21 1 16 24 296K 444K 628K 27.1M # 2197 fix_prebin 0.0% 0:00.05 1 27 31 332K 856K 1.16M 27.4M # 2137 less 0.0% 0:00.02 1 11 17 108K 444K 408K 17.7M # 2136 col 0.0% 0:00.02 1 11 15 144K 356K 348K 17.6M # -- # PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE # 2213 top 71.2% 0:00.41 1 17 25 312K+ 448K+ 672K+ 27.1M+ # 799 Terminal 14.2% 1:34.92 5 67 158 2.55M 18.9M 22.9M+ 156M # 797 Acrobat 14.2% 8:36.65 4 81 273 28.3M 63.0M 61.9M 240M # 1064 mozilla-bi 7.1% 3:43.34 13 198 484 26.3M 39.1M 52.0M 374M # 2214 grep 0.0% 0:00.00 1 11 16 68K+ 416K 356K+ 17.9M+ # lincoln:~ wire$ # # Första "svepet" med "top -ocpu -l2 -s0" ger sortering på PID, trots att "-ocpu" är specad (märkligt). # Vi vill veta (fast vi redan egentligen vet att det är rad 1 och 8 som matchar regex /PID/ i awk, eftersom de är statiska... # ... - grep -A5) ... # ... vilka rader som vi ska börja söka efter processer som tar mer är 50%. Vi måste dock ignorera processerna... # ... top,grep,awk,sort och sed. Troligen är det bara top som kan gå över 50% CPU och returnera sig själv som "dryg". # Raden blir (kallar jag start_line): start_line=`top -ocpu -l2 -s0 | grep -A5 PID | awk '/PID/ {print NR}' | sort -r | sed '2d'` echo 'start_line='$start_line # Nu kollar vi vilken process som "toppar". Troligen "top" 9 av 10 ggr. # Raden efter "awk /PID/" är första högsta CPU-usage. process_line=$(($start_line + 1)) # Enkel addering echo 'process_line='$process_line # Och processen är (troligen top): what_process=`top -ocpu -l2 -s0 | grep -A5 PID | awk -v process_line=$process_line '{if(NR==process_line) print $2}'` echo 'what_process='$what_process # Är den "top" kollar vi näst högsta: # Vi jobbar INTE i en loop, vilket man kanske borde göra. Men vi vet med 99,9% säkerhet att processen efter "top", är den "vi söker". case "$what_process" in *top*) echo 'top is most %CPU (som vi trodde)...' echo ' Vi kollar nästa process...' process_line=$(($start_line + 2)) # Enkel addering (plus 2 den här gången) what_process=`top -ocpu -l2 -s0 | grep -A5 PID | awk -v process_line=$process_line '{if(NR==process_line) print $2,$3}'` echo 'what_process (start_line+2)='"$what_process" # Tar ut %-satsen som processen tar... cpu_usage=`echo $what_process | awk '{print $2}'` echo $cpu_usage # Och tar ut heltalet. Förutsätter att heltal har ett ".". Typ: 12.0. procenten=`echo $cpu_usage | cut -d. -f1` echo 'procenten='$procenten # Om CPU-usage för någon process (utom "top") är mer än 50(%) då utför ett AppleScript i filform, i detta exempel. if [ $procenten -gt 50 ] then echo 'ja' # osascript $HOME/the_big_script else echo 'nej' fi ;; *) echo 'Processen som är över 50% och inte är top.' esac
Här kommer det väldigt lätt moddade scriptet.
Mycket användbart när man väntar på att en process ska bli klar
koppla den till ett applescript som väljer en speciell låt i itunes !
eller ett som skickar ett mail..
#!/bin/sh # "top -ocpu -l2 -s0 | grep -A5 PID" ger en output som ser ut så här: # # lincoln:~ wire$ top -ocpu -l2 -s0 | grep -A5 PID # PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE # 2214 grep 0.0% 0:00.00 1 11 15 56K 416K 344K 17.7M # 2213 top 0.0% 0:00.21 1 16 24 296K 444K 628K 27.1M # 2197 fix_prebin 0.0% 0:00.05 1 27 31 332K 856K 1.16M 27.4M # 2137 less 0.0% 0:00.02 1 11 17 108K 444K 408K 17.7M # 2136 col 0.0% 0:00.02 1 11 15 144K 356K 348K 17.6M # -- # PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE # 2213 top 71.2% 0:00.41 1 17 25 312K+ 448K+ 672K+ 27.1M+ # 799 Terminal 14.2% 1:34.92 5 67 158 2.55M 18.9M 22.9M+ 156M # 797 Acrobat 14.2% 8:36.65 4 81 273 28.3M 63.0M 61.9M 240M # 1064 mozilla-bi 7.1% 3:43.34 13 198 484 26.3M 39.1M 52.0M 374M # 2214 grep 0.0% 0:00.00 1 11 16 68K+ 416K 356K+ 17.9M+ # lincoln:~ wire$ # # Första "svepet" med "top -ocpu -l2 -s0" ger sortering på PID, trots att "-ocpu" är specad (märkligt). # Vi vill veta (fast vi redan egentligen vet att det är rad 1 och 8 som matchar regex /PID/ i awk, eftersom de är statiska... # ... - grep -A5) ... # ... vilka rader som vi ska börja söka efter processer som tar mer är 50%. Vi måste dock ignorera processerna... # ... top,grep,awk,sort och sed. Troligen är det bara top som kan gå över 50% CPU och returnera sig själv som "dryg". # Raden blir (kallar jag start_line): start_line=`top -ocpu -l2 -s0 | grep -A5 PID | awk '/PID/ {print NR}' | sort -r | sed '2d'` echo 'start_line='$start_line # Nu kollar vi vilken process som "toppar". Troligen "top" 9 av 10 ggr. # Raden efter "awk /PID/" är första högsta CPU-usage. process_line=$(($start_line + 1)) # Enkel addering echo 'process_line='$process_line # Och processen är (troligen top): what_process=`top -ocpu -l2 -s0 | grep -A5 PID | awk -v process_line=$process_line '{if(NR==process_line) print $2}'` echo 'what_process='$what_process # Är den "top" kollar vi näst högsta: # Vi jobbar INTE i en loop, vilket man kanske borde göra. Men vi vet med 99,9% säkerhet att processen efter "top", är den "vi söker". case "$what_process" in *top*) echo 'top is most %CPU (som vi trodde)...' echo ' Vi kollar nästa process...' process_line=$(($start_line + 2)) # Enkel addering (plus 2 den här gången) what_process=`top -ocpu -l2 -s0 | grep -A5 PID | awk -v process_line=$process_line '{if(NR==process_line) print $2,$3}'` echo 'what_process (start_line+2)='"$what_process" # Tar ut %-satsen som processen tar... cpu_usage=`echo $what_process | awk '{print $2}'` echo $cpu_usage # Och tar ut heltalet. Förutsätter att heltal har ett ".". Typ: 12.0. procenten=`echo $cpu_usage | cut -d. -f1` echo $procenten echo 'procenten='$procenten # Om CPU-usage för någon process (utom "top") är mindre än 50(%) då utför ett AppleScript i filform, i detta exempel. if [ $procenten -gt 50 ] then echo 'Nej Vi gör inget' else echo 'vi kör scriptet' osascript $HOME/the_big_script # No way You get some here. fi ;; *) echo 'Skrivs den här raden ut som "standard out" är något riktigt fel. Eller rätt!! Gissa varför?' esac
Hmm... men scriptet kollar ju inte att processen är klar, bara att den inte tar mer än 50% cpu?
Låt säga att jag kör ett vanligt adobe program och gör någon tung beräkning som tar 40 min eller nått.
så länge programet jobbar så kommer den att dra massor med kraft, för att sedan när den är klar ligga och små dutta på några % , då måste ju detta vara en bra lösning för att få feedback på när operationen är klar !
någon med en bättre lösning ?
Nä, nu måste man plocka lite kharma...
Varför inte byta ut top mot ps? Då slipper man hålla på med grep, awk, sort etc mer än nödvändigt (förutom att hitta Photoshop):
ps -r -c -U <username> -o pcpu,command
där
-r sorterar på CPU-utnyttjande
-c visar bara programnamnet och inte hela kommandoraden
-U visar bara angiven användare
-o gör så att bara intressant info visas (%CPU + Command)
Man slipper också att hitta och sortera bort top.
PS. Buggen i originalscriptet med sorteringen hos top beror på att ni inte har läst manualsidan ordentligt. Där står det att det ska vara ett mellanslag mellan -o och <key>. Gör man så sorterar top.
PS. Buggen i originalscriptet med sorteringen hos top beror på att ni inte har läst manualsidan ordentligt. Där står det att det ska vara ett mellanslag mellan -o och <key>. Gör man så sorterar top.
Det stämmer inte. Mellanslag eller inte påverkar inte resultatet (X 10.3.2). Testa
top -o cpu -l2 -s0 | grep -A12 PID och sedan utan mellanslag top -ocpu -l2 -s0 | grep -A12 PID
. Ingen skillnad.
Här är nog en bätttre (tydligare) lösning än den jag skrev tidigare. Använder ps istället för top:
#!/bin/sh # Om vi med säkerhet vet att det är "jag" som kör den process som vi söker # blir scriptet lite enklare med ps (som frazze säger). # I detta exemplel använder vi Safari # Vi söker upp processen (och antar här att den bara körs av en användare). cpu_och_command=`ps -crU wire -o pcpu,command | awk '/Safari/ {print $0}'` # Hittades processen överhuvudtaget? if [ "$cpu_och_command" == '' ] then echo 'Processen körs inte i systemet.' else echo 'cpu_och_command='$cpu_och_command # Output blir typ: 0.0 Safari # Vi pipar till t.ex.awk för att få endast procenten. #Pipen till cut tar ut heltalet för procenten för enklare vidare beräkning. procenten=`echo $cpu_och_command | awk '{print $1}' | cut -d. -f1` echo 'procenten='$procenten # Nu kollar vi om procenten (processen) är under 50% if [ $procenten -lt 50 ] then echo '< 50: ja' # osascript $HOME/the_big_script else # Inget script körs. echo '< 50: nej' fi fi # Kontrollen körs bara en gång i detta script. # Vill man få det att upprepa kontrollen stoppar man in hela skiten mellan: #while true #do # ---Här placerar du kontrollen vi skrev ovan--- #sleep 5 # Kontrollen utför var femte sekund. #done
Det stämmer inte. Mellanslag eller inte påverkar inte resultatet (X 10.3.2). Testa
top -o cpu -l2 -s0 | grep -A12 PID och sedan utan mellanslag top -ocpu -l2 -s0 | grep -A12 PID
. Ingen skillnad.
Nej, det är ju märkligt - för jag lyckas heller inte återskapa fenomenet längre. Inte ens återskapa den inledande buggen med felaktig sortering. Så jag backar och tar tillbaka mitt påstående, men påpekar också att den inledande buggen inte längre verkar existera.