staging.inyokaproject.org

Hallo an alle!

Ich versuche nun schon eine Stunde lang einen Skript täglich auszführen, der mich daran erinnert schlafen zu gehen 😬

Hier erstmal der Code des Skriptes:

#!/bin/bash
export DISPLAY=:1

if zenity --question --text "Schlafenszeit...\nMöchtest du ausmachen?"; then
	dbus-send --print-reply --dest=org.gnome.SessionManager /org/gnome/SessionManager 		org.gnome.SessionManager.RequestShutdown
	sleep 2
	dbus-send --print-reply --dest=org.gnome.SessionManager /org/gnome/SessionManager 		org.gnome.SessionManager.
	exit;
fi

zenity --warning --text "Ok... Wie du meinst..."

Ich hab das Skript mit dem Manager "gnome-schedule" als cronjob eingetragen. Wenn es dann starten soll ignoriert er aber komischerweise das IF und führt nur den letzten Befehl ("OK... wie du meinst") aus. Ich hoffe ihr könnt mir helfen... Hab bestimmt nur ne Kleinigkeit übersehen ☺

mfg

Laiasi

Huhu! ☺

Du stellst mit dem if quasi eine Behauptung auf: Stell es dir so vor, dass, wenn du sagst, Linux sei schlecht, (then) das passiert, dass eine ganze Menge Nutzer dir hier die Bude eintrampeln werden. Übersetzt heißt das, du behauptest nur, aber sagst nicht, was passieren soll, wenn die Behauptung zutrifft. Also macht der Computer nix. Er versteht dich nicht.

Mir springt da jetzt auch kein Fehler ins Auge – außer vielleicht, dass du keine absoluten Pfade nutzt, was halt in Cronjobs problematisch sein kann.

Ignoriert er das if komplett oder zeigt er den ersten Dialog wenigstens noch an? Falls letzteres der Fall ist, dann weiß dbus vielleicht nicht, wo die Reise hingehen soll. Ein schnelles Suchen brachte diesen Blogpost auf den Plan – etwas ähnliches vermute ich bei dir. Schau doch in der Richtung mal. Um sicherzustellen, dass es an sowas liegt, würde ich einfach mal ein "date > /tmp/cron-hat-geklappt" vor die dbus-Commands stellen.

@neongelbe: Was genau meinst du? An dem if ist eigentlich nichts verkehrt. Zumindest fällt mir nichts auf. ☺

Hey danke für die schnelle Hilfe! Leider aber immer noch kein Erfolg...

Vain schrieb:

Ignoriert er das if komplett oder zeigt er den ersten Dialog wenigstens noch an? Falls letzteres der Fall ist, dann weiß dbus vielleicht nicht, wo die Reise hingehen soll. Ein schnelles Suchen brachte diesen Blogpost auf den Plan – etwas ähnliches vermute ich bei dir. Schau doch in der Richtung mal. Um sicherzustellen, dass es an sowas liegt, würde ich einfach mal ein "date > /tmp/cron-hat-geklappt" vor die dbus-Commands stellen.

Er ignoriert es scheinbar komplett... Das Komische ist ja dass wenn ich den Skript per Mausklick oder per Terminal ausführe klappt alles wie es soll... Nur beim Cronjob erscheint eben nur der zweite Dialog als ob da schon jemand auf "Nein" gedrückt hat 😕 .

Alle Pfade werden von mir absolut angegeben... Vielleicht macht ja auch "gnome-schedule" irgendein Fehler... Ich werde den Skript mal versuchen manuell per "crontabs -e" einzutragen obwohl ich da doch auch irgendwas bearbeiten muss weil zenity ja grafisch ist...

neongelbe schrieb:

Huhu! ☺

Du stellst mit dem if quasi eine Behauptung auf:

if zenity --question --text "aus?"; then echo "ja" ; else echo "nein"; fi

gibt bei mir - je nach dem - ja oder nein aus.

Ich verstehe Deine Behauptung nicht. ☺

Mein Telefon-Display war so klein, dass ich kein then gesehen habe. Die Code-Blocks werden abgeschnitten. Tschuldigung für die Fehldiagnose. Ich stand grad an der Bahn. ☹

Hi Laiasi,

erstmal noch willkommen auf dem Forum !

Hast Du den Aufruf von zenity mal mit absolutem Pfad, also als /usr/bin/zenity probiert ? (falls unter cron der Suchpfad nicht funktioniert)

Der Rückgabewert der bash wenn sie ein Programm nicht findet ist üblicherweise "127",
und den Rückgabewert könntest Du sowieso noch mal abfragen, mit einem Probe-Echo nach der zenity-Zeile:

if zenity --question --text "Schlafenszeit...\nMöchtest du ausmachen?"; ret=$?; then
	...
fi
echo "ret: $ret" >> /home/Laiasi/test.txt

Vielleicht bringt das etwas Licht in die Sache.
Überhaupt sind solche "debug"-echos oft recht nützlich.

track

Vielleicht auch den kompletten Pfad zu dbus-send und/oder sleep angeben.

Hallo!

Gute Idee das mit den "Debug"-Echos"! Danke... Hab einiges am Code geändert und eure Tipps berücksichtigt

Hier erstmal der Code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

#!/bin/bash
export DISPLAY=:0

if /usr/bin/zenity --question --text "Schlafenszeit...\nMöchtest du ausmachen?"; then
	ret=$? 
	echo "ret: $ret" >> /home/phileas/test.txt
	echo "Aus"
	exit; else
	ret=$?
fi

echo "An"
echo "ret: $ret" >> /home/user/test.txt
zenity --warning --text "Ok... Wie du meinst..."

So hab dann also diese kleine "LOG"-Datei test.txt nach dem normalen Ausfürhen und dem Ausführen per Cronjob erstellt.

Hier der Log("//" sind zum Kommentieren wie ihr wisst 😉 ):

// Normales Ausführen
ret: 0
ret: 1
// Ausführen per Cronjob (Minutüg zum Testen)
ret: 255
ret: 255
ret: 255
ret: 255
ret: 255
ret: 255

Nur wofür steht der Rückgabewert 255?

Hab auf die schnelle auch keine Antwort vom Herrn Google bekommen.

Achso hab mir überleght dass es vielleicht auch mit dem "export DISPLAY=:0" zusammenhängen könnte, da ich Twinview von Nvidia benutze... Denke ist aber doch eher unwarscheinlich weil der letzte Dialog ja funktioniert.

Aus dem Rückgabewert "255" werde ich auch nicht schlau, ich weiß nicht einmal von welchem Programm der geworfen wird.

Vielleicht hilft ein Log der Konsolen- und Fehlerausgabe weiter:

if /usr/bin/zenity --question --text "Schlafenszeit...\nMöchtest du ausmachen?"; then
	ret=$? 
	echo "ret: $ret" >> /home/phileas/test.txt
	echo "Aus"
	exit; 
else
	ret=$?
fi  >> /home/phileas/test.txt  2>&1

Dann siehst Du wenigstens das was Du sonst nicht siehst.

track

Hab's mal bei mir ausprobiert und ich würde sagen, dein Environment ist unvollständig. Insbesondere ist keine Locale gesetzt. Das wird bei deinem "ö" zum Problem:

if /usr/bin/zenity --question --text "Schlafenszeit...\nMöchtest du ausmachen?"; then

Du speicherst dein Skript ja ziemlich sicher als UTF8 ab. Wenn der Cronjob läuft, ist aber wohl keine UTF8-Locale aktiv und wenn sich das Programm dann auf Locales verlässt, knallt es. ☺ Versuch doch am Anfang des Skriptes mal das hier:

1
2
3

#!/bin/bash
export DISPLAY=:0
export LANG=de_DE.utf8

(Oder eine andere UTF8-Locale, siehe Ausgabe von "locale -a".)

Übrigens bekomme ich von Cron eine lokale Mail an meinen User geschickt, die mich über den Fehlschlag des Cronjobs informiert. Da steht dann drin:

Date: Wed, 12 May 2010 19:56:03 +0200
From: MobilTux <void@mobiltux.eis.suedpol>
To: void@mobiltux.eis.suedpol
Subject: cron for user void /tmp/hurz.sh

This option is not available. Please see --help for all possible usages.

Das hat mich darauf gebracht, mal nach und nach alle Möglichkeiten zu testen, die bei der Angabe der Optionen zu Fehlern führen könnten. So eine Mail müsstest du eigentlich auch bekommen haben. Die wird bloß leider irgendwo unter "/var/spool/mail/phileas" (oder so) vergammeln, vermute ich mal... 😉

👍 Ich glaub das ist es. Das "Standard-Rückfall-Locale" ist ja C, und damit bekomme ich das auch:

track@ubuntu:~$ LC_ALL=C /usr/bin/zenity --question --text "Schlafenszeit...\nMöchtest du ausmachen?"; echo $?
This option is not available. Please see --help for all possible usages.
255
track@ubuntu:~$ LC_ALL=C /usr/bin/zenity --question --text "Schlafenszeit...\nMxchtest du ausmachen?"; echo $?          # <- aber das funktioniert !
0
track@ubuntu:~$ 

Die Lösung ist also ganz einfach, genau wie Vain sagt:

LC_ALL=de_DE.utf8 /usr/bin/zenity --question --text "Schlafenszeit...\nMöchtest du ausmachen?";

Diese Variante würde ich deswegen vorziehen, weil dann das Locale wirklich nur für den einen Befehl umgestellt wird.
(ich trau mich immer nicht so eine Einstellung unnötig großflächig vorzunehmen, wegen möglicher Nebeneffekte)

track

Danke das Skript läuft nun! 😀

Es lag echt an dem kleinen "ö" und daran dass LANG=de_DE.utf8 eben nicht gesetzt war.

Also einfach "export LANG=de_DE.utf8" am Anfang einfügen und dann klappts.

Wäre ich aber nie drauf gekommen.

Naja werde mir das für die Zukunft merken... Aus Fehlern lernt man bekanntlich ja.

Also Danke nochmal für die schnelle Hilfe 👍

mfg

Laiasi

PS: Vielleicht sollte ich mal was ins Wiki dazu schreiben, falls da noch irgendjemand das Problem hat

Vain: Hast Du eigentlich eine Idee, wie weit die Locale-Einstellung durch das export zurück vererbt wird ?

Ich hätte da nämlich Angst dass ich da irgendwas in das System impfe, und ich weiss nicht was damit passieren könnte ...
Aus purer Vorsicht und Unwissenheit habe ich bisher die Variable ja deshalb erstmal entweder 1. lokal per Befehl mitgeben:

LC_ALL=de_DE.utf8  <Befehl>

oder 2. allenfalls begrenzt gültig nur für das Skript (ohne "export"):

#!/bin/bash
LC_ALL=de_DE.utf8

<Befehle>

edit: Die Antwort habe ich inzwischen selber gefunden: http://steve-parker.org/sh/variables1.shtml

Also völlig unbegründet die Angst, nach "oben" wird sowieso nichts exportiert.
Es ist sogar so, dass meine Variante 2. Mist ist, weil die Variable dann für aufgerufene Programme gar nicht sichtbar wäre.
Meine Variante 1. ist praktisch ein "export", gültig nur für diesen einen Befehl.

Was Vain oben vorgeschlagen hat ist also doch die solideste Variante.

track

track schrieb:

Vain: Hast Du eigentlich eine Idee, wie weit die Locale-Einstellung durch das export zurück vererbt wird ? Ich hätte da nämlich Angst dass ich da irgendwas in das System impfe, und ich weiss nicht was damit passieren könnte ...

Zurück? Also nach meinem Kenntnisstand geht das sowieso gar nicht. Du kannst das Environment immer nur zu den Kindern hin vererben, aber nie nach oben. So steht es auch in der Buchempfehlung von deinem/eurem Guide auf Seite 78, hab eben nochmal nachgeschaut – hab das Buch zufällig. ☺

Cron wird das Skript auch kaum in seinem eigenen Prozess ausführen (können), sondern normal über fork() + exec() einen neuen erzeugen. Insofern würde ich mir da keine Gedanken über eine "Vergiftung" machen. ☺

-edit: Oh, okay. Hab nebenher was anderes gemacht und deinen Edit nicht mitgekriegt. 😉