Shellscript soll Terminal abschiessen

[ratti]

Hallo,

Ich habe ein Shellscript geschrieben, welches mir beim Systemstart diverse Server mountet. Ich habe es mit der Extension ".command" versehen in den Startprogrammen eingetragen.

Das Problem ist, dass nach jeder Ausführung ein "beendetes" Terminal offenbleibt. Ich könnte das in den Preferences einstellen, dass sich zumindest das Fenster nach Beendigung schliesst - das will ich aber nicht (Das Script soll noch auf einen Haufen anderer Kisten, und ausserdem sehe ich nicht ein, wegen eines Scriptes die Prefs zu verdrehen...).

Deswegen hatte ich die Idee, das Script nicht mit "exit" zu beenden, sondern einfach das Terminal zu kill'en. Aufgrund der speziellen Art der Ausführung (Autostart) kann da ja eigentlich nichts anderes in einem anderen Fenster laufen.

Wie kommt man an die PID des Elternprozesses? $$ und $PPID habe ich gefunden - die sind es nicht. grep'en will ich nicht, das ist mir zu unsicher.

...oder falls jemand einen "beende mein Terminal"-Befehl kennt - her damit.

Gruß,
Ratti

 

[maceis]

...
Ich habe ein Shellscript geschrieben, welches mir beim Systemstart diverse Server mountet. Ich habe es mit der Extension ".command" versehen in den Startprogrammen eingetragen.

Damit wird aber, wenn ich Dich richtig verstanden habe, das Mounten erst bei der Anmeldung des Benutzers erledigt.
Für das Mounten beim Systemstart halte ich ein StartupItem (pre-Tiger) oder einen LaunchDaemon Job (ab Tiger) für besser geeignet.
Da stellt sich Dein Problem erst gar nicht.

Frage aus Interesse: Mit welchen Rechten läuft Dein Script?

...
...oder falls jemand einen "beende mein Terminal"-Befehl kennt - her damit.

killall Terminal

 

[ratti]

Damit wird aber, wenn ich Dich richtig verstanden habe, das Mounten erst bei der Anmeldung des Benutzers erledigt.

Das ist prinzipiell auch OK, da unterschiedliche User unterschiedliche Volumes mounten (mit unterschiedlichen Rechten).

Für das Mounten beim Systemstart halte ich ein StartupItem (pre-Tiger) oder einen LaunchDaemon Job (ab Tiger) für besser geeignet.
Da stellt sich Dein Problem erst gar nicht.

Tiger und Panther gemischt.

Aus [/System]/Library/Startup hatte das Script leider keine Wirkung. Als Startobjekt geht es. LaunchDaemon ist mir neu. Was das?

Frage aus Interesse: Mit welchen Rechten läuft Dein Script?

"Normal". Keine Tricks, normales Startobjekt - also sollte es unter dem Account des Users laufen.

Anbei die ungeschliffene Rohform:


export user="name"
export pass="passwort"

for I in fonts web projekte software ; do (
mkdir "/Volumes/$I" >/dev/null 2>&1 ;
mount_afp "afp://$user:$pass@xbox/$I" "/Volumes/$I" ;
) ; done

killall Terminal

Rumms. Ja, das kann man machen, ich hätte allerdings gern etwas weniger Schrotflinte. Sowas wie "kill $PARENTPID".

Kann man eigetnlich irgendwie zwischen "Autostart" und "Manuell gestartet" unterscheiden? Das würde mir das Testen doch sehr erleichtern (Rumms, Terminal wech... )

Gruß,
Ratti

Nachtrag: diese blöden kindischen grafischen Smileys machen mich WAHNSINNIG. In "Schrotflinte" kommt "rotfl" vor, und zack hab ich wieder so'ne Gackerfresse in meinem Text...

 

[maceis]

...
Aus [/System]/Library/Startup hatte das Script leider keine Wirkung.

Sollte wohl "[/System]/Library/StartupItem" heissen.
Da brauchts ja auch noch ne StartupParameters.plist Datei dazu.
Das Skript muss auch bestimmten Kriterien genügen.
Bei Interesse einfach mal die DeveloperDoku checken.

...
LaunchDaemon ist mir neu. Was das?
...

Ist eine neue Technologie, die seit Tiger eingesetzt wird.
Kurz gesagt ist das der Ersatz für StartupItems, xinetd und inetd, cron Startobjekte, teilweise für die rc-Dateien etc..
Das Ganze geht aber über die bisherige Funktionalität hinaus und überwacht z. B. auch Daemons, Dateien und Ordner.
launchd unterscheidet eine System und eine Nutzerebene sowie zwischen LaunchAgents und LaunchDaemons.
Meiner Ansicht nach eine sehr positive Entwicklung.
Einer der offensichtlichen positiven Effekte ist, dass das System deutlich schneller startet.

...
ich hätte allerdings gern etwas weniger Schrotflinte. Sowas wie "kill $PARENTPID".
...

Was ist den der Parentprozess eines Startobjekts?
Wenn es loginwindow ist, hätte Deine Methode fatale Folgen.
Ansonsten sehe ich jetzt Dein Problem nicht.
"killall" und "kill" sind weitgehend identisch.
Standarmäßig wird ein TERM-Signal gesendet, was den betroffenen Prozess zum geregelten Herunterfahren auffordert.

 

[ratti]

Sollte wohl "[/System]/Library/StartupItem" heissen.
Da brauchts ja auch noch ne StartupParameters.plist Datei dazu.
Das Skript muss auch bestimmten Kriterien genügen.
Bei Interesse einfach mal die DeveloperDoku checken.

Jepp, das sollte es heissen - sass grad nicht am Mac.

Ich werd mir das mal anschauen. Brauchbar ist es wohl nicht, denn das ganze soll Userbezogen laufen, je nach Login.



(Killen des Parentprozesses)

Was ist den der Parentprozess eines Startobjekts?
Wenn es loginwindow ist, hätte Deine Methode fatale Folgen.
Ansonsten sehe ich jetzt Dein Problem nicht.
"killall" und "kill" sind weitgehend identisch.
Standarmäßig wird ein TERM-Signal gesendet, was den betroffenen Prozess zum geregelten Herunterfahren auffordert.

Der Parentprozess eines Startobjekt-Scripts ist grundsätzlich das Terminal. Deswegen ist das abschiessen des Parents eigentlich erstmal ungefährlich.

Eigentlich. Denn es kann ja sein, dass derzeit mehrere Scripte im Terminal ablaufen. Es kann also sein, dass mein Script ein anderes abschiesst, welches den gleichen Parent hat (nämlich Terminal).


Eigentlich ist das alles Murks.
Korrekterweise müsste das Script eigentlich ohne Terminal ablaufen. Das scheint ja irgendwie nicht möglich zu sein. Packe ich "script.sh" in die Startobjekte, öffnet sich Textedit. Desgleichen mit Perl. Es muss doch irgendwie möglich sein, ein Script, welches ja nicht mal Ausgaben macht, im Userkontext beim Start auszuführen, ohne Terminal.app zu nutzen...

Gruß,
Ratti

 

[lengsel]

Eigentlich ist das alles Murks.
Korrekterweise müsste das Script eigentlich ohne Terminal ablaufen. Das scheint ja irgendwie nicht möglich zu sein. Packe ich "script.sh" in die Startobjekte, öffnet sich Textedit. Desgleichen mit Perl. Es muss doch irgendwie möglich sein, ein Script, welches ja nicht mal Ausgaben macht, im Userkontext beim Start auszuführen, ohne Terminal.app zu nutzen...

Mal ein Gedankenspiel:

In meiner crontab sind Skripte die zu einem bestimmten Zeitpunkt laufen sollen (klar, dafür ist cron ja da). Diese Skripte laufen aber auch ohne offenen Terminal(.app). Es müsste ja also schon möglich sein dem System ein Skript zur Ausführung zu übergeben, nach dem Userlogin. Möglicherweise bearbeitet cron (das vermutlich schon vor dem Login eines Users gestartet wird) die jeweilige User-crontab erst nach dessen Login (was ja logisch wäre). Würde es nicht also reichen einen entsprechenden Eintrag in der crontab des jeweiligen Users zu machen?

Grüße,
Flo

 

[ratti]

Diese Skripte laufen aber auch ohne offenen Terminal(.app).

Genau - Scripte brauchen ja auch nicht unbedingt ein Terminal. Es scheint eher so zu sein, dass das Programm, welches die Startobjekte managed, auf ein solches besteht...

Möglicherweise bearbeitet cron (das vermutlich schon vor dem Login eines Users gestartet wird) die jeweilige User-crontab erst nach dessen Login (was ja logisch wäre). Würde es nicht also reichen einen entsprechenden Eintrag in der crontab des jeweiligen Users zu machen?

cron läuft immer und führt Scripte unabhängig davon aus, ob der Besitzer eingeloggt ist oder nicht. Der Eigentümer muss nicht mal eine Shell haben.

Die ganze Unix-Technologie kommt ja u.a. auf Geräte zum Einsatz, die über keinerlei Ausgabegeräte verfügen. So gesehen - unproblematisch. Schwierigkeiten habe ich halt nur mit dem Start beim Login, ohne dass das Terminal benutzt werden soll.

Um mal in "Linuxismen" zu sprechen - ich möchter sowas wie "start.sh", die Startobjekte zwingen mich aber zu sowas wie "xterm start.sh".

Aber das muss ja irgendwie gehen.

Gruß, Ratti

 

[Magicq99]

Ist das ganze denn vielleicht über ein AppleScript möglich? Man kann doch auch per AppleScript ein Unix Commando ausführen, vielleicht öffnet sich das Terminal da nicht.

Oder es wird alles über ein AppleScript gemacht, ohne Terminal Befehle. Das geht bestimmt auch irgendwie.

Das ist aber nur so eine Idee, ich kenne mich damit nicht gut genug aus.

 

[lengsel]

...die Startobjekte zwingen mich aber zu sowas wie "xterm start.sh"

Schade dass das mit cron nicht klappt...
Noch ne Idee: das Skript nicht im Terminal(.app) starten, sondern z.B. in iTerm.app (eigene PID, hat nichts mit Terminal.app zu tun)
Kein anderer Prozess läuft dort nach Beendigung des Skripts, ergo kann iTerm.app bedenkenlos per "Schrotflinte" abgeschossen werden. Sicher keine besonders elegante Lösung, aber es könnte funktionieren.

Grüße,
Flo

 

[maceis]

...
Deswegen hatte ich die Idee, das Script nicht mit "exit" zu beenden, sondern einfach das Terminal zu kill'en. Aufgrund der speziellen Art der Ausführung (Autostart) kann da ja eigentlich nichts anderes in einem anderen Fenster laufen.
...

...Eigentlich. Denn es kann ja sein, dass derzeit mehrere Scripte im Terminal ablaufen. Es kann also sein, dass mein Script ein anderes abschiesst, welches den gleichen Parent hat (nämlich Terminal).
...

Was jetzt?

Das aktuelle Problem wird dadurch verursacht, dass Du die Ausführung des Skriptes mit Hilfe der Endung *.command auslösen möchtest.
Die Endung *.command ist aber mit dem Programm Terminal verknüpft.
Also ist dieser Ansatz wohl falsch.

Ein alternativer Ansatz, der schon genannt wurde, ist der Einsatz von Applescript. Beide Möglichkeiten, die Magicq99 nannte, sollten funktionieren.
Syntax für ein mögliches Applescript:
mount Volume "afp://benutzerasswort@server/freigabe"

Eine andere Möglichkeit besteht ab 10.4 im Einsatz von userbezogenen LaunchAgents.
Hier könnte man mit ganz einfachen Shellskripten arbeiten, die aber eben kein Terminal benötigen.

HTH

[edit]sch.. smilies[/edit]

 

[Turm]

wie wärs mit einem osascript -e 'tell application "Terminal" to quit' am Schluss?

 

[ratti]

wie wärs mit einem osascript -e 'tell application "Terminal" to quit' am Schluss?

Das wäre umständliche Version von "killall Terminal" - bringt mich also nicht weiter.

Gruß,
Ratti

 

[ratti]

Das aktuelle Problem wird dadurch verursacht, dass Du die Ausführung des Skriptes mit Hilfe der Endung *.command auslösen möchtest.
Die Endung *.command ist aber mit dem Programm Terminal verknüpft.
Also ist dieser Ansatz wohl falsch.

.command ist das einzige, was ich finden konnte, was überhaupt ausgeführt wird.
.sh öffnet sich beispielsweise mit TextEdit!

Ein alternativer Ansatz, der schon genannt wurde, ist der Einsatz von Applescript. Beide Möglichkeiten, die Magicq99 nannte, sollten funktionieren.
Syntax für ein mögliches Applescript:
mount Volume "afp://benutzerasswort@server/freigabe"

AppleScript wird gerade abgeschafft - genau so wie von dir beschrieben haben wir das mounten unter 10.3 gemacht. Unter Tiger ist das buggy. Erstens dauert es relativ lange (Ich habe über 10 Volumes zu mounten), und ab 5 oder sechs verschluckt sich Applescript (Nur unter Tiger!). Im syslog kann man sehen, dass das Applescipt-mount aus irgendwelchen Gründen ein mount-unmount-remount auslöst. Zwischen dem dritten und sechsten Volume verhaspelt es sich dann und behauptet, Volumes würden nicht existieren - tauscht man die Reihenfolge im Script aus, sind es dann jeweils andere. Über Pausen geht es dann doch - aber 10 Volumes mit je 3 Sekunden Pause sind eine halbe Minute...

Egal.

Selbst wenn Applescript ging, wäre es nicht mehr das Tool meiner Wahl. Das ganze wird etwas größer, wird automatische Softwareupdates anschieben und dergleichen - ich brauch bash oder perl.

Es muss doch irgendwie möglich sein, ein Shellscript
- beim Start (aber nach dem Login)
- im Userkontext
- ohne Terminal
auszuführen?

Eine andere Möglichkeit besteht ab 10.4 im Einsatz von userbezogenen LaunchAgents.
Hier könnte man mit ganz einfachen Shellskripten arbeiten, die aber eben kein Terminal benötigen.

Da muss ich noch mal nachhaken, bin heute nicht dazu gekommen. Ganztägige Webservermigration und noch immer nicht fertig... ...

Gruß,
Ratti