Script startet Anwendung nicht

F

fabio

Active member
Themenstarter
Registriert
11 März 2011
Beiträge
1.037
Hallo,

folgendes Problem: Ich habe mir endlich mal eine eigene Conky-Konfiguration zusammengebastelt und im Netz ein einfaches Start/Stop-Script dafür entdeckt. Das habe ich ein wenig abgeändert und mit einem Launcher verbunden. Auf dem PC läuft das einwandfrei. Aber auf dem Laptop startet es conky nicht. Beenden geht aber, also ist nichts schief gelaufen bei der Adressierung des Scriptes und ausführbar ist es auch. Im Moment ist mir das noch ein Rätsel. Aus dem Terminal öffnet sich conky auch ganz normal.

Das Script sieht folgendermaßen aus:
Code: 
#!/bin/bash
#conky an-aus script

hit=0
hit=$(ps x | grep -i 'conky' | wc -l)
if [[ "$hit" > 1 ]]
    then
	hit=0 
        killall conky
	exit
    else
	conky
    	exit
fi

Irgendjemand eine Idee, weshalb es sich auf PC und Laptop unterschiedlich verhalten könnte?

EDIT: die beiden Zeilen "hit=0" sind glaube ich überflüssig und die "exit" hab ich auch rausgenommen. Auf dem PC läuft immer noch alles wie es soll, auf dem Notebook nicht.
 
Zuletzt bearbeitet:
Hey,
warscheinlich geht ehr immer in den ersten Teil des ifparts...
Loesungsvorschlag:
fuer diesen Befehl 2 mal aus ps x | grep -i 'conky' | wc -l
Einmal wenn conky laeuft und einmal wenn conky aus ist.
Dementsprechend passt du deine if Abfrage an.
Zb bei mir gibt dieser Befehl eine 1 aus wenn conky aus ist und eine 2 wenn es laeuft dann muesste in der if ein >=1 stehen.
Waere meine Idee, wuerde mich ueber Rueckmeldung ob es daran lag freuen :)
 
Hi,

ich weiß nicht so richtig, ob ich deinen Vorschlag verstehe. Ich kann den Befehl doch nur einmal ausführen, weil er doch das Ergebnis liefert, ob conky läuft oder nicht. Ich kann also nicht einmal fragen wenn er an ist und einmal wenn er aus ist.

Ich hab auf die Anregung hin aber mal versucht das mit ">=1" genauer zu definieren und statt einem else-Abzweig ein zweites if zu benutzen, aber das bringt auch nichts. Trotzdem danke.

Was mich am meisten wundert ist eigentlich, dass es auf dem anderen Rechner ohne weiteres läuft und auf meinem Laptop nur zur Hälfte, also nur ausschaltet.
Ich hab sogar versucht die beiden Fälle umzudrehen, also die Bedingung zu ändern und das Einschalten in den if-Zweig zu legen und das Ausschalten in den else-Zweig. Auch ohne Erfolg.
 
Code: 
#!/bin/bash
#conky an-aus script

export DISPLAY=:0

hit=$(ps aux | grep -i 'conky' | grep -v grep | wc -l)
if [[ $hit != 0 ]]; then
   killall -9 conky
else
   conky &
fi
exit

das sollte es schon gewesen sein ;)

Kurze erklärung:

Wenn du grep aus dem Behfel mit grep -v grep nicht rausholst hast du quasi immer min. 1 ergebnis, manchmal auch 2

fabio schrieb:
Hallo,

folgendes Problem: Ich habe mir endlich mal eine eigene Conky-Konfiguration zusammengebastelt und im Netz ein einfaches Start/Stop-Script dafür entdeckt. Das habe ich ein wenig abgeändert und mit einem Launcher verbunden. Auf dem PC läuft das einwandfrei. Aber auf dem Laptop startet es conky nicht. Beenden geht aber, also ist nichts schief gelaufen bei der Adressierung des Scriptes und ausführbar ist es auch. Im Moment ist mir das noch ein Rätsel. Aus dem Terminal öffnet sich conky auch ganz normal.

Das Script sieht folgendermaßen aus:
Code: 
#!/bin/bash
#conky an-aus script

hit=0
hit=$(ps x | grep -i 'conky' | wc -l)
if [[ "$hit" > 1 ]]
    then
    hit=0 
        killall conky
    exit
    else
    conky
        exit
fi

Irgendjemand eine Idee, weshalb es sich auf PC und Laptop unterschiedlich verhalten könnte?

EDIT: die beiden Zeilen "hit=0" sind glaube ich überflüssig und die "exit" hab ich auch rausgenommen. Auf dem PC läuft immer noch alles wie es soll, auf dem Notebook nicht.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
fabio schrieb:
Code: 
hit=$(ps x | grep -i 'conky' | wc -l)

if [[ "$hit" > 1 ]]
Zum Vergrößern anklicken....
Das grep-Kommando ist, so wie es dasteht, recht instabil (i.e. ungeeignet). Bspw. müsstest du das Skript nur conky_starten.sh nennen oder gerade deine conky-Config geöffnet haben, damit "$hit" > 1 (besser geschrieben als [[ "$hit" -gt 1 ]], da ">" ein Zeichenvergleich ist, z.B ist [[ "-1" > "0" ]] wahr!) immer erfolgreich ist (=> killall conky).

In einem solchen Fall bietet es sich an, einfach zu versuchen, conky zu beenden und den Fehlerfall "kein conky-Prozess gefunden" entsprechend zu behandeln (das "EAFP"-Prinzip ;)). In der einfachsten Form sieht das dann in etwa so aus:
Code: 
#!/bin/sh
killall conky 2>/dev/null || ( conky & )

vg
dywi
 
... ja, und conky sollte grundsaetzlich als letzte Anwendung auf dem Schirm starten. Baue also ein sleep ein.
Das war der Grund, warum Du conky auf dem Laptop "nicht gesehen", jedoch "beenden" konntest. :)
 
Das ist mir jetzt echt peinlich Leute...

@dywi Treffer. Der einzige Unterschied zwischen PC und Laptop war der "Name des Scriptes". Das hab ich einfach mal conky_an_aus.sh genannt :facepalm: Und der Enzeiler funktioniert natürlich auch.

Lacht ruhig, aber nicht böse sein :)

Aber trotzdem vielen Dank. Wobei eure Antworten natürlich auch wieder Fragen aufwerfen. Was ja gut ist, ich will ja dazulernen.

@blafoo
Code: 
1 export DISPLAY=:0
2
3 hit=$(ps aux | grep -i 'conky' | grep -v grep | wc -l)
4 if [[ $hit != 0 ]]; then
5    killall -9 conky
6 else
7    conky &
8 fi
9 exit
Zum Vergrößern anklicken....

wozu Zeile 1 und was ist, wenn ich kein exit wie in Zeile 9 angebe (oder wann könnte etwas passieren? Und die Schreibweise mit dem ; in Zeile 4 kannte ich auch noch nicht.

@maledora4 nein es ist kein Autostart, aber werd ich dran denken, danke. Ich konnte es beenden, wenn ich es vorher über die Konsole gestartet hatte,

@all was bewirkt das & hinter "conky &"?

Vielen Dank auf jeden Fall für eure Antworten.
 
Ach ja, die Sache mit dem extra grep -v. Das find ich gut (ich hatte das mal mit -1 gelöst, als es um ein genaues Ergebnis ging), aber das brauch ich doch nicht, wenn ich die Bedingung auf > 1 testen lasse oder? Worin liegt der Vorteil?
 
fishmac schrieb:
Hast Du 'ne Allergie gegen pgrep ? :D

kill -9 gleich zu Anfang ... :facepalm:
Zum Vergrößern anklicken....

Beides Erfahrung ;)

Warum pgrep wenn grep | grep -v grep das gleiche kann :D

Und -9 ist immer toll ;) So kann man sicher sein das es tot ist!

@ Fabio:

export DISPLAY=:0 setzt das Display .. es kann sein das wenn du nen Script via Autostart startest das es "keinen Monitor" findet und im Hintergrund startet .. so setzt du dem Teil halt die Variable und somit wei es auf welchem Display es starten soll.
; in Zeile 4: Auch hier gewohnheit .. deine Schreibweise war nicht falsch.

Du kannst das ganze, DAS ist aber Ekelig, alles in eine Zeile schreiben, du kannst damit Befehle trennen. Also Befehl1; Befehl2; blablu

Zb:
Code: 
#!/bin/bash
while [ true ]
 do
    free -m
    sleep 2
done

kannst du auch zu:
Code: 
while [ true ]; do free -m; sleep 2; done
machen :) Aber einzeiler sind selten hübsch :))

Das & heist das es den Befehl in den Hintergrund schiebt. Beispiel:

Du führst von einer Konsole conky aus, dann merkst du das du mit der Konsole nicht mehr machen kannst. Machst du aber conkey & machst, kannst du mit nem Enter die Konsole weiternutzen (aber Conky haut weiterhin output auf das Terminl, das kann irritieren)

@dywi .. natürlich .. vergessen zu erwaehnen das auch der Weg nicht hübsch ist (aber funktioniert) solange das Script selber nicht so heist .. natürlich :)

@Fabio .. Bash ist wie eine Religion .. jeder "Denkt / Meint" was anderes. Du fragst 5 Leute und du wirst 10 Antworten erhalten ;) dywi machts mit befehle || befehl2, ich würds auf deinen Weg machen (das funktioniert, damit verdien ich hauptberuflich mein Geld ;)) .. Erfahrung und auch von wem man lernt prägt den Stil wie man schreibt und es kann vorkommen das andere Sagen: ey das is aber hässlich und ich würds so machen :)

Ein Tip:

Auch wenn du [[ ]] benutzt: Variablen sollten NUR in " " wenn du sie gegen Chars vergleichst.
Also:
$variable == 1234
"$variable" == "einszweidrei1234"
Das ist "schöner" [[ ]] umgeht das Teilweis, und hilft dir da, aber man sollte es von vornerein wissen / kennen.

Die Variable hit hast du vorab mit 0 befüllt .. das ist nicht verkehrt. Bash kann mit dem Standard [ ] keine leeren Variablen benutzten.

D.h. nen

hit=""
"$bla" == "$hit" gibt nen Fehler aus. Entweder du benuttz [[ ]] oder füllst sie vorab oder umgehst es:

"x$bla" == "x$hit" .. so kann $bla notfalls immer gegen x abgefragt werden und so geht das auch mit []

Grüße
 
fabio schrieb:
Ach ja, die Sache mit dem extra grep -v. Das find ich gut (ich hatte das mal mit -1 gelöst, als es um ein genaues Ergebnis ging), aber das brauch ich doch nicht, wenn ich die Bedingung auf > 1 testen lasse oder?
Zum Vergrößern anklicken....
Brauchst du nicht.

Worin liegt der Vorteil?
Zum Vergrößern anklicken....
Mit pgrep kommst du hier genauer bzw. mit weniger Aufwand an die gewünschten Informationen:

Code: 
# nur Prozesse erfassen, deren Name genau conky entspricht
pgrep -x conky
# wie oben, aber Anzahl der Prozesse ausgeben
pgrep -x conky -c
 
Man sollte aber faireshalber erwähnen:

Pgrep "ist kein Standard"
grep ist notfalls in jeder Busybox drin.

Auf dem System auf dem ich nun täglich, seit fast 3 Jahren, arbeite ist "nur" eine kleine Busybox vorhanden ;) Da is nichts mit pgrep. Und man sollte, bevor man zu echt schicken klamotten wie egrep / pgrep greift, wissen wie es notfalls auch ohne geht.

Grüße
 
blafoo schrieb:
Beides Erfahrung ;)

Warum pgrep wenn grep | grep -v grep das gleiche kann :D
Zum Vergrößern anklicken....
Genau ... Warum einfach ... ? :D

Und -9 ist immer toll ;) So kann man sicher sein das es tot ist!
Zum Vergrößern anklicken....
Das challenged den Hobby-Forensiker :D Die .lock-files sind auszudrucken und auf Anfrage vorzuzeigen :D


blafoo schrieb:
Man sollte aber faireshalber erwähnen:

Pgrep "ist kein Standard"
grep ist notfalls in jeder Busybox drin.
Zum Vergrößern anklicken....

Ist conky in Deiner BusyBox drin ? :D
 
Natürlich ist Conky nich in BB drin du Fogel (ja mit Fogel FFFFFFFF :DDDD) :D :love:

.lock files .. argument .. Gibt aber selten "Gui-Programme" die sowas tatsächlich haben .. stimmt sollte / muss man bedenken.

Macht der Gewohnheit .. .. ist einfach so ;) Früher .. vor Dekaden der Zeit ... gabs nur grep :P SO! Egrep / Pgrep sind neumodischer Kram .. das braucht keiner :D

Und naja .. irgendwann .. ich seh es kommen .. sitzt er zb an seinem Debian-Server .. übernommen vonnem Kumpel .. Debian 4.1 .. erinnert sich dran : ahh mit pgrep -x BLAFOO -c kann ich Prozesse zaehlen lassen .. zack "Command not found" .. und dann? muss er wieder googlen ;))

:thumbsup:
 
@blafoo Vielen Dank!
export DISPLAY=:0 setzt das Display....
Zum Vergrößern anklicken....
das muss ich mir merken.

; ... du kannst damit Befehle trennen
Zum Vergrößern anklicken....
ach klar :facepalm: Ich hätte nur nicht gedacht, dass das "then" als euer Befehl gesehen wird. Ich hätte eher gedacht das gibt ein Syntax-Error :D Wieder was dazugelernt.

Du führst von einer Konsole conky aus, dann merkst du das du mit der Konsole nicht mehr machen kannst. Machst du aber conkey & machst, kannst du mit nem Enter die Konsole weiternutzen (aber Conky haut weiterhin output auf das Terminl, das kann irritieren)
Zum Vergrößern anklicken....
Aha, das war auch neu für mich. Das muss ich mir auch merken.

Variablen sollten NUR in " " wenn du sie gegen Chars vergleichst.
Zum Vergrößern anklicken....
Ok.

Die Variable hit hast du vorab mit 0 befüllt .. das ist nicht verkehrt. Bash kann mit dem Standard [ ] keine leeren Variablen benutzten.
Zum Vergrößern anklicken....
Aber kann ich das nicht auch weglassen? hit wird ja durch "hit=$(ps aux | grep -i 'conky' | grep -v grep | wc -l)" befüllt.

Und was ist wenn ich das exit am Ende weg lasse?
 
Wenn der Befehl failed, warum auch immer!, kann die Variable leer sein.

Geht hier mehr darum das du dir das direkt angewöhnt es sauber zu machen :), nicht ob es nun 100% zutrifft.

Also, im Skript ist es immer so das am ende "quasi" ein Exit steht.

Code: 
BEFEHL
BEFEHL
BEFEHL
(EXIT)

Weil das beendet sich ja.

Wenn du nun hergehst:

Code: 
If
  bla
  exit
else
  blub
  exit
fi
exit

Ist punkt eins das letzte Exit überflüssig, und die 2 anderen gehen einfach her das Script "frühzeitig" zu beenden. D.h. wenn im if-Teil schon das exit steht kommt er gar nicht mehr zum Fi. Kann man machen muss man aber nicht.
Sobald das Script am Ende ist wird eh ein Exit gesetzt.

Zudem kannst du mit Exit verschiedene Statusse setzten.

Nach dem Ausführen deines Scriptes kannst du ein echo $? machen um den End-Status deines Scriptes aufzurufen. Das wird wohl 0 sein.

Normal heist:
0 = Ordentlich beendet
1= Unordentlich beendet

Zudem kannst du mit zb:

Code: 
Exit 123

hergehen und eigene Statuswerte setzten, machst du dann ein $? kommt ein "123" raus.

So kannst du Werte an andere Scripte zb übergeben:

Code: 
If
  bla
  exit 123
else
  blub
  exit 124
fi
exit 255

$? == 123 heist das er im If-Teil beendet hat, $? == 124 heist das er im else-Teil geendet hat, $? == 255 heist er hat den IF-ELSE-Teil gar nicht bearbeitet, warum auch immer.

http://tldp.org/LDP/abs/html/exit-status.html

Grüße
 
Ok, vielen Dank nochmal für die ganzen Erklärungen!

mein Script sieht jetzt übrigens so aus:
Code: 
hit=0
hit=$(ps aux | grep -i 'conky$' | grep -v grep | wc -l)
if [[ $hit != 0 ]]
    then
        killall conky
    else
        conky &
fi      
exit

Damit gibt es auch nicht mehr so schnell eine verwechslung mit z.B. gedit /home/meine_scripte/conky/soundso.sh, wie es z.B. bei mir grad ist :)
 
Zuletzt bearbeitet:
Fishmac .. findest?!

Ich dachte das wäre "verdauliche" Kost, seine Vorarbeit war ja nicht schlecht.

Das Galileobuch ist natürlich auch gut :)

Grüße
 
Danke, ist als Lesezeichen gespeichert :)

Ich denke/hoffe ich hab alles soweit verstanden. Ich denke die Schwierigkeit ist eher sich ohne etwas Routine an alle Fälle zu erinnern. Aber ich bin froh, dass ich gestern diesen dummen kleinen Fehler in der Namensgebung gemacht habe :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben