Skript für Ziplaufwerk

Dr. Glastonbury · 1 Dez. 2004

Hallo,
wollte ein kleines Script schreiben, dass mir, wenn ich es aufrufe das Laufwerk moutet, dann den Konqueror bei /media/zip öffnet und, wenn ich ihn wieder schließe das Laufwerk auswirft.
soweit bin ich schon:

Code:

#!/bin/sh

mount /media/zip
kfmclient openURL /media/zip

while [Fenster-Offen]
do
	sleep 100
done

eject /media/zip

mein Problem ist die Stelle bei [Fenster-Offen]: Prinzipiell müsste man ja nur die PID des Konqerors verfolgen und wenn sie nicht mehr vorhanden ist weiter zu eject gehen - diesen Befehl weiß ich aber leider nicht, kann mir da wer helfen?

regexer · 3 Dez. 2004

Normalerweise ist der korrekte Befehl für das Warten auf einen Child-Process "wait [Process-ID]". Nur bin ich mir nicht sicher, ob dein Fenster als extra process läuft...

Ich werde heute abend einmal ein bisschen probieren und gegebenenfalls berichten.

Dr. Glastonbury · 3 Dez. 2004

Wow, ne Antwort

!
Vielen Dank für deine Mühe! werde mir mal die Man-Page für wait anschauen...
denn schon mal Danke!

Dr. Glastonbury · 4 Dez. 2004

So, habe nochmal n bisserl Man-Pages durblättert und konnte entnehmen, dass man mit wait auch auf einen Job warten kann.

Unter job steht dann folgendes:

Code:

jobs -x command [ args ... ]
              If the -x option is  supplied,  jobs  replaces  any
              jobspec  found  in  command or args with the corre-
              sponding process group  ID,  and  executes  command
              passing it args, returning its exit status.

Kann mir wer erklähren was es damit aufsich hat, sprich wie ich da die ID bekomm? Sonst könnte ich nämlich einfach mit wait [jobID] die Abfrage machen.

Ich habe auch schon mal das da versucht:

Code:

moritz@Lamer:~> jobs -x kfmclient openURL /home && echo $?
0
moritz@Lamer:~> Launched ok, pid = 8688

wobei als ich nur

Code:

moritz@Lamer:~> jobs -x kfmclient openURL /home

eingegeben hatte wurde mir nicht dieses Launched angezeigt. Wie bekomme ich nun also die blöde ID? Und warum zeigt der mir das ganze nur mit $? an, da er doch da eigentlich bei dem Befehl nur die "0" hinschreibt (also halt den Rückgabewert des letzten Kommandos, aber das hat ja eigentlich nix mit dem jobs zu tun).

N Haufen Fragen, ja..... :roll:

dann schon mal wieder thx!!!

regexer · 6 Dez. 2004

Wie bekomme ich nun also die blöde ID?

Leider kann ich wieder keine Komplettlösung bieten. Ich bastle zur seit an einem ähnlichen Problem.

Grundsätzlich bekommt man eine jobid mit dem Befehl "pidof". Nur ist an diesem unschön, dass er mehrere jobids zurückgeben kann. Beispiel:

Code:

user@host->sleep 20 &
[1] 28218
user@host->sleep 20 &
[2] 28219
user@host->pidof sleep
28219 28218
user@host->

Ich habe es bisher nicht geschafft, die eigentlichen Rückmeldungen aus der Shell (z.B. "[1] 28218") auszulesen. Das wäre nämlich der saubere weg.

Aber um auf dein Problem zurückzukommen: Ich glaube in deinem Fall sieht eine Lösung komplett anders aus. Denn wenn ich das am Wochenende richtig gesehen habe, erzeugt "kfmclient openURL" keinen eigenen Prozess. Ich glaube, dass man besser in eine andere Richtung suchen müsste. Zum Beispiel könnte ich mir vorstellen, dass kfmclient durch einen entsprechenden Parameter alle geöffneten Fenster zurückliefert... Vielleicht ist es besser, an dieser Stelle weiterzusuchen.

Übrigens: Dein Phänomen mit dem "jobs -x" kann ich auf SLES 7 nicht nachvollziehen...

Dr. Glastonbury · 6 Dez. 2004

Übrigens: Dein Phänomen mit dem "jobs -x" kann ich auf SLES 7 nicht nachvollziehen...

hihi...ich inzwischen auch nicht mehr - das muss irgendwie einmalig gewesen sein, weil ich das seitdem nicht mehr bekomme...naja, egal.

Und sonst werde ich mir mal die Optionen von kfmclient zu gemüte führen, auch wenn ich unter kfmclient --help-all noch nichts gefunden habe....werde aber noch weitersuchen, interessant is ja z.B. der Befehl um den Namen des Fensters zu setzen, evtl. kann ich ja damit was anfangen....

dann schon mal wieder einen recht herzlichen Dank!

regexer · 7 Dez. 2004

Und sonst werde ich mir mal die Optionen von kfmclient zu gemüte führen

Wenn du etwas interessantes findest: Nichts wie raus damit!

Dr. Glastonbury · 7 Dez. 2004

Also:
der kfmclient dient, so wie ich das jetzt gesehn habe nur, um Konqueror-Fenster mit verschiedenen Optionen zu öffnen. Sprich den werden wir kaum zum verfolgen des Prozesses gebrauchen können.

So, ich hab aber noch ne schöne Nachricht: wenn man kfmclient exec file:/home & eingibt wird einem die PID und die jobs Nummer zurückgegeben, also kann man dann mit wait 1 auf den child-prozess warten. Das klitze kleine Problem ist, dass der kfmclient kein childprozess der Konsole ist (zumindest behauptet das "wait", aber evtl. kannst du da ja auch nochmal schaun, ob ich da n Syntax-fehler gemacht hab.

hier mein Testscript:

Code:

#!/bin/sh

#kfmclient exec file:/home &

SETI &

while wait 1
do
	sleep 1
done

kfmclient exec file:/home/moritz

wenn alles nach Plan laufen würde, dann sollte er mir den Konqeror starten wenn ich SETI über STRG + C beendet habe - leider macht er das nicht, könnte aber daran liegen, dass SETI n eigenes Script is - werde es gleich nochmal mit nem anderen Programm testen.

bis denn!

regexer · 8 Dez. 2004

Dr. Glastonbury schrieb:
wenn man kfmclient exec file:/home & eingibt wird einem die PID und die jobs Nummer zurückgegeben, also kann man dann mit wait 1 auf den child-prozess warten.

Sorry, aber mit wait 1 wartest du nicht auf die Job-Nr. 1 sondern auf die PID 1. Und diese wird normalerweise durch den kernel belegt. Das macht keinen Sinn.

Zur Erklärung: Wenn du etwas mit "&" in den Hintergrund schickst, wird eine Zeile in der Form [Job-Nr.] PID
ausgegeben. Wait wartet auf die PID. Aber selbst, wenn du die PID verwendest, wird dir das nicht weiterhelfen. Denn der Process lebt nur für den Bruchteil einer Sekunde - nämlich so lange, bis das Fenster fertig am Bildschirm erscheint. Danach ist das Fenster offen, aber der Process schon beendet.

Also: Leider immer noch keine Lösung in Sicht...

Dr. Glastonbury · 9 Dez. 2004

Das heißt also, dass das Fenster von einem Dieser KDEinit, oder was da noch so alles unter KDE läuft, verwaltet wird und garnicht in den Prozessen auftritt?
Ohje, da hab ich mir ja mal wieder was vorgenommen....

Noch zu wait, das hab ich dann wohl falsch verstanden - ich dachte nämlich wait wartet auf die JobNr, is aber wohl idT nicht so...

Vielen Dank für diese Erleuterungen! Aber siehst du überhaupt irgendeine Möglichkeit das zu verfolgen?

oc2pus · 9 Dez. 2004

probiert mal das:
startproc -p meine-pid-datei <programm mit parameter>

So werden die daemons in den runleveln gestartet und beendet.

man startproc:

-p pid_file
Use an alternate pid file instead of the default (/var/run/<basename>.pid). The pid read from this file is being matched against the pid of running processes that have an executable with specified path. of the program. In order to avoid confusion with stale pid files, a not up-to-date pid will be ignored.

mit killproc -p meine-pid-datei <programm> wird dann der entsprechende Prozess gekillt.

@Dr Glastonbury:
in der Datei meine-pid-datei steht dann die pid des kfmclient-Prozesses drin.

Dr. Glastonbury · 9 Dez. 2004

Hallo,
(ich hab mich fast schon gewundert, wo du bleibst...lol)

leider findet er das 'startproc' nicht:

Code:

moritz@Lamer:~> startproc -p /home/moritz/pidat.txt kfmclient exec file:/home/moritz
bash: startproc: command not found
moritz@Lamer:~>

muss ich das erst noch installieren - oder besser, wo finde ich das?
Sonst schon mal vielen Dank! :lol:

oc2pus · 9 Dez. 2004

startproc, killproc ist im Paket sysvinit drin.
Sollte eigentlich installiert sein.

Es kann aber sein das du als user dieses Programm mit /sbin/startproc aufrufen musst, weil /sbin nicht im Pfad enthalten ist bei normalen user'n

Dr. Glastonbury · 9 Dez. 2004

THX!!!
Also das läuft jetzt schon soweit! Jetzt noch ein paar Fragen:
Hab ich das richtig verstanden, dass ich dem in der Datei jede beliebige PID, die noch nicht vergeben ist geben kann?
Und wie kann ich dann auf diese PID warten?

Ich hab in die pidat.txt mal ne 50000 eingetragen (und er öffnet das ganze auch damit), aber wenn ich dann wait 50000 versuche, dann sagt er mir wieder nur dass das kein Child-Prozess is (dasselbe wenn ich mit top -p 50000 versuche, da wird mir auch wieder nix angezeigt)...

bin ich nur zu blöd das mit dem wait zu verstehn (ich glaube "JA!"), oder wie kann ich jetzt abfragen, ob der Prozess noch läuft?

oc2pus · 9 Dez. 2004

nein,
der startproc startet den Prozess und schreibt dann die PID in die angegebene Datei rein.

wenn du genau diese PID killen willst, kannst du das tun mit
cat pid-datei | kill -9
oder
killproc -p pid-datei progname

btw. mit checkproc kannst du testen ob der Prozess noch läuft.

also in deinem Ausgangsproblem:
while [ checkproc -p pid-datei <progname> ] ....

Dr. Glastonbury · 9 Dez. 2004

Sorry! und nochmal Sorry!
ich glaube ich poste nochmal mein Script:

Code:

#!/bin/sh

#mount /media/zip

/sbin/startproc -p /home/moritz/pidat.txt /opt/kde3/bin/kfmclient exec file:/home


while `/sbin/checkproc -p /home/moritz/pidat.txt /opt/kde3/bin/kfmclient exec file:/home`
do
	sleep 0.5
done

echo "Jetzt ist das Fenster geschlossen"
#eject /media/zip

das müsste doch jetzt so stimmen??? (Aber wenn ich das ausführe, dann kommt schon nach kurzer Zeit mein 'echo').
Und sonst noch, wenn ich die pidat.txt lösche, oder umbenenne stört der sich garnicht dran, geschweige denn, dass er so eine Datei erstellt...nur wenn ich die Datei leer erstelle, dann kommt das:

Code:

startproc: Can not handle pid file /home/moritz/pidat.txt with pid `'
checkproc: Can not handle pid file /home/moritz/pidat.txt with pid `'

Und wenn ich die Datei mit einer PID fülle, die es eigentlich schon gibt macht ihm das auch nix aus, genauso, wie er sie nicht in die aktuelle umschreibt...

oc2pus · 9 Dez. 2004

ok, reset - der kfmclient ist etwas besonderes.

Wenn man eine PID des Prozesses hat und diese in eine Datei schreibt geht die vorgeschlagene startproc, checkproc, killproc Klamotte.

Aber dieses kfmclient-Biest rückt die nicht raus

Selbst via DCOP ist der kfmclient nicht abfragbar. D.h. es gibt wohl ein internes KDE-API für den kfmclient, damit erhält man einen "handle" und kann den dann beenden, bzw abfragen aber das bedeutet sich selber ein kleines Programm zu schreiben ...

aber vielleicht hilft dir das:
http://www.scripps.edu/~jsmith/jazip/

Dr. Glastonbury · 9 Dez. 2004

Aha, ok - wenigstens bin ich nicht Schuld...lol
Also gegen n eigenes Programm schreiben hab ich eigentlich nichts...meinst du, ich kann das mit Java hinbekommen? Oder geht dieser Borland C - builder auch in Linux, damit könnte man evtl. n bisserl durch Dateien browsen....

Naja ich glaub ich werde mich mal n bisserl im Programming-Forum umschauen!

Bis bald und vielen Dank!!! :wink:

P.S.
Dein Link nutz mir leider weniger, weil ich
1. damit nicht so ganz zurecht komm (Installation is n bisserl seltsam)
2. Das nicht für Geräte geht, die an LPT hängen - oder ich hab mal wieder nicht genau genug gelesen....

oc2pus · 9 Dez. 2004

Features in version 0.34:

* Support for Parallel, SCSI, and ATAPI interface Zip drives (With proper kernel support. See the FAQ)

is parallel nicht LPT ????

Dr. Glastonbury · 9 Dez. 2004

oc2pus schrieb:
is parallel nicht LPT ????

Da sehn wirs mal wieder....ich les nicht genau genug...sorry!
Aber leider ist die Installation dennoch seltsam! - zumindest komm ich da nicht zurrecht, aber wenn, dann mach ich nen neuen Fred auf...dann ham die Admins ihre Freude!

Auf jeden Fall bin ich dank dir schon wieder mal schlauer geworden!
Bis bald mal wieder!