Hi Leutz

das ist sicherlich ein Standardproblem, weshalb ich hoffe ihr könnt mir helfen^^. Ich habe folgendes Script erstellt:

1
2
3
4
5

#!/bin/bash
echo "1.drehe $(date)" >> /home/kiigass/Desktop/bla.log
xrandr -o right
echo "2.danach $(date)" >> /home/kiigass/Desktop/bla.log
exit 0

Dieses Script wird von einem ACPI-Event aufgerufen. Das Script wird (denke ich) mit root-Rechten aufgerufen. Auch wenn die Befehle eigentlich keine root-Rechte benötigen.

Wird das Script automatisch (ACPI) aufgerufen, kommen die beiden Echos an, aber der Befehl dazwischen wird nicht ausgeführt. Rufe ich es manuell auf, funktioniert alles wie gewünscht. Wo liegt mein Fehler? (Eine Fehlermeldung gibt es nicht)

thx for help

greez Kiigass

Kiigass schrieb:

Dieses Script wird von einem ACPI-Event aufgerufen. Das Script wird (denke ich) mit root-Rechten aufgerufen. Auch wenn die Befehle eigentlich keine root-Rechte benötigen.

Wird das Script automatisch (ACPI) aufgerufen, kommen die beiden Echos an, aber der Befehl dazwischen wird nicht ausgeführt. Rufe ich es manuell auf, funktioniert alles wie gewünscht. Wo liegt mein Fehler? (Eine Fehlermeldung gibt es nicht)

Ändere es doch mal so und schau, was Dir berichtet wird:

1
2
3
4
5
6

#!/bin/bash
exec >>/home/kiigass/Desktop/bla.log 2>&1
echo "1.drehe $(date)" 
xrandr -o right
echo "2.danach $(date)"
exit 0

Jetzt werden auch alle Fehler in die Datei geschrieben.

Ciao

robert

danke für die schnelle Antwort. Jetzt steht in der Datei:

1.drehe Wed May 23 15:46:24 CEST 2012
Can't open display 
2.danach Wed May 23 15:46:24 CEST 2012
Failed to open Display .

Damit kann ich allerdings leider wenig anfangen.

PS: Kannst du mir kurz erklären, was deine Zeile genau macht? Vor allem das "2>&1" versteh ich nicht.

Kiigass schrieb:

danke für die schnelle Antwort. Jetzt steht in der Datei:

1.drehe Wed May 23 15:46:24 CEST 2012
Can't open display 
2.danach Wed May 23 15:46:24 CEST 2012
Failed to open Display .

Nun, es sieht so aus als ob xrandr Zugriff auf das X Display braucht, mit dem Du gerade arbeitest. Das steht aber an der Stelle nicht ohne weiteres zur Verfügung, da Dein Skript ja von einem anderen Benutzer ausgeführt wird. (Das ist im Prinzip dieselbe Beschränkung, die die Kollegen hier immer wieder ereilt, die gerne aus cron Jobs auf das Display zugreifen möchten.)

Es gibt vermutlich verschiedene Lösungen, die ich jetzt aber nicht im Detail aus dem Effeff beschreiben kann. Eine Möglichkeit ist, Inhalte von DISPLAY und einer anderen Umgebungsvariable in eine Datei zu schreiben, die dann von Deinem Skript ausgelesen werden und benutzt werden, um xrandr die passende Umgebung zur Verfügung zu stellen.

Vielleicht geht auch was über dbus, aber da kenne ich mich überhaupt nicht aus. Dann könntest Du natürlich noch ein Skript mit Deiner X-Session starten, das auf einem bestimmten Socket lauscht, dort ein Kommando liest ("landscape", "portrait") und dementsprechend xrandr ausführt. Dein Skript oben wäre dann nur der Proxy, der die Meldung fängt und über den Socket weiterreicht.

PS: Kannst du mir kurz erklären, was deine Zeile genau macht? Vor allem das "2>&1" versteh ich nicht.

Erst wird FD 1 (stdout) umgeleitet in die Datei und dann wird FD 2 (stderr) dahin umgeleitet, wohin FD 1 schreibt. So landet beides an der selben Stelle. man bash hat mehr Infos.

Ciao

robert

vielen Dank für die ausführliche Antwort. Dann ist das Problem damit schonmal klar und ich bin damit einen deutlichen Schritt weiter. Danke auch für deinen Lösungsvorschlag. Mein Gedanke war grad noch: Kann ich das script (anstatt als root) auch als ein anderer Benutzer ausführen lassen? Also ähnlich wie ich mir mit "sudo" root-Rechte holen kann, kann das Script nicht die Befehle mit meinem Nutzerkonto ausführen?

Also ich weiß, das ist ein wenig wirr formuliert, aber ich hoffe es wird klar was ich meine.

Kiigass schrieb:

vielen Dank für die ausführliche Antwort. Dann ist das Problem damit schonmal klar und ich bin damit einen deutlichen Schritt weiter. Danke auch für deinen Lösungsvorschlag. Mein Gedanke war grad noch: Kann ich das script (anstatt als root) auch als ein anderer Benutzer ausführen lassen? Also ähnlich wie ich mir mit "sudo" root-Rechte holen kann, kann das Script nicht die Befehle mit meinem Nutzerkonto ausführen?

Ja, das kannst Du - aber es bringt Dir nix. Du musst an die X-Berechtigungen ran. Schau mal mit man xauth.

Also ich weiß, das ist ein wenig wirr formuliert, aber ich hoffe es wird klar was ich meine.

Passt scho.

Bis neulich

robert

rklm schrieb:

Dann könntest Du natürlich noch ein Skript mit Deiner X-Session starten, das auf einem bestimmten Socket lauscht, dort ein Kommando liest ("landscape", "portrait") und dementsprechend xrandr ausführt. Dein Skript oben wäre dann nur der Proxy, der die Meldung fängt und über den Socket weiterreicht.

Das klingt doch gut. Und mit einer „named pipe“ statt Sockets ist das in einem Shellskript auch gar nicht so schwer.

listener.sh, was du zusammen mit deiner X-Session im Autostart startest:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#!/bin/bash

f=/tmp/rotater.fifo
if [[ ! -p "$f" ]]
then
	rm -f "$f"
	mkfifo -m 600 "$f" || exit 1
fi

while true
do
	read line < "$f" || exit 1
	case $line in
		landscape)
			# ... xrandr-Drehbefehl für Landscape ...
			echo "Switching to landscape mode."
			;;
		portrait)
			# ... xrandr-Drehbefehl für Portrait ...
			echo "Switching to portrait mode."
			;;
	esac
done

Das Skript beim ACPI-Event führt dann ein

1

echo landscape > /tmp/rotater.fifo

oder

1

echo portrait > /tmp/rotater.fifo

aus.

Mit einem solchen Ansatz umgehst du den ganzen Authorisierungskrempel, weil die listener.sh im richtigen Kontext läuft.

danke euch, ich hab mich die letzten Stunden mal mit dem Thema beschäftigt. Xauth ist gar nicht so leicht dazu zu kriegen dem root den Zugriff auf das Display zu gewähren. Ich hab dahin gehend versucht in der /root/.bashrc zu setzen:

XAUTHORITY=/home/kiigass/.Xauthority
DISPLAY=:0.0

genmäß dieser Quelle: http://www.pug.org/mediawiki/index.php/Als_root_das_Display_des_Users_nutzen

Allerdings hat das zu keinem Ergebnis geführt.

Auf der anderen Seite steht der Vorschlag von Vain. Dazu hab ich mal ne ganz blöde Frage: Wenn ich das richtig sehe läuft da eine Endlosschleife, die ständig einen Wert aus einer Datei liest (pollt). Ist das nicht ziemlich belastend für die Systemressourcen?

Kiigass schrieb:

danke euch, ich hab mich die letzten Stunden mal mit dem Thema beschäftigt. Xauth ist gar nicht so leicht dazu zu kriegen dem root den Zugriff auf das Display zu gewähren. Auf der anderen Seite steht der Vorschlag von Vain. Dazu hab ich mal ne ganz blöde Frage: Wenn ich das richtig sehe läuft da eine Endlosschleife, die ständig einen Wert aus einer Datei liest (pollt). Ist das nicht ziemlich belastend für die Systemressourcen?

Nein => blocking IO.

Vain, kann es sein, dass da eine Schleife überflüssig ist?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#!/bin/bash

f=/tmp/rotater.fifo
if [[ ! -p "$f" ]]
then
	rm -f "$f"
	mkfifo -m 600 "$f" || exit 1
fi

while read line < "$f"
do
	case $line in
		landscape)
			# ... xrandr-Drehbefehl für Landscape ...
			echo "Switching to landscape mode."
			;;
		portrait)
			# ... xrandr-Drehbefehl für Portrait ...
			echo "Switching to portrait mode."
			;;
                *)      # unexpected
                        echo "Someone send us crap: $line" >&2
                        exit 1
                        ;;
	esac
done

Ciao

robert

Stimmt.

Ich hatte ursprünglich die Umlenkung hinter dem done. Da beendet sich dann die Schleife, nachdem ein Schreiber auf seiner Seite die Pipe geschlossen hat. Folglich: Die Pipe muss in jedem Durchlauf neu zum Lesen geöffnet werden. Das tun unser beider Lösungen, aber deine ist natürlich eine Stufe eleganter.

okay danke euch nochmals. Ich habe nun drei Fragen:

1. "mkfifo ... || exit 1" ist vermutlich ein logisches OR: Bei Fehlschlag des mkfifo folgt das exit? Sieht gut aus, ich hab sowas nur vorher noch nie gesehen.

2. funktioniert blocking I/O nur bei pipes oder auch bei files?

3. macht es einen Unterschied ob die Umlenkung hinter dem done steht?

Kiigass schrieb:

das ist sicherlich ein Standardproblem, weshalb ich hoffe ihr könnt mir helfen^^. Ich habe folgendes Script erstellt:

1 2 3 4 5

#!/bin/bash echo "1.drehe $(date)" >> /home/kiigass/Desktop/bla.log xrandr -o right echo "2.danach $(date)" >> /home/kiigass/Desktop/bla.log exit 0

Kannst Du das exit 0 irgendwie erklären, und wenn nicht, es stillschweigend entfernen. Danke.

nun das exit 0 gibt meines Wissens nach eine 0 an die Shell zurück. In diesem Falle könnte man sicherlich auch darauf verzichten, weil sonst ja der Rückgabewert von echo übergeben wird und es sonst keine Verzweigungen und exits gibt, aber ich habe mich durch viele andere Programmiersprachen daran gewöhnt jeder Funktion einen definierten Rückgabewert zu geben. Ich halte das für eine saubere(re) Programmierung.

Die drei Fragen von oben sind noch offen.

Kiigass schrieb:

1. "mkfifo ... || exit 1" ist vermutlich ein logisches OR: Bei Fehlschlag des mkfifo folgt das exit? Sieht gut aus, ich hab sowas nur vorher noch nie gesehen.

Jo.

2. funktioniert blocking I/O nur bei pipes oder auch bei files?

Blocking I/O ist der Normalfall, insbesondere in Shellskripten. Asynchrones Lesen und Schreiben ist immer mit komplexerem Code verbunden, weswegen du das – so würde ich mutmaßen – eher selten antriffst. Naja, zumindest wenn es um so einfache Dinge wie „lies mal diese Konfigurationsdatei ein“ oder so geht.

Gibt auf der anderen Seite natürlich auch Projekte, die intensiven Gebrauch von Non-Blocking I/IO machen. Ich finde aber, dass das unter „spezieller Anwendungsfall“ fällt.

3. macht es einen Unterschied ob die Umlenkung hinter dem done steht?

Ja. Wenn sie hinter dem „done“ steht, dann gilt sie für die ganze Schleife. Also:

• Öffne die Datei.

• Solange du eine Zeile aus der Datei lesen kannst (Position innerhalb der Datei rückt voran!), führe den Schleifenrumpf aus.

Man setzt die Umleitung hinter das „done“, wenn man einmalig eine ganze Datei lesen möchte.

Wenn die Umleitung direkt hinter dem „read“ steht, gilt sei nur für dieses eine „read“. Das sieht dann so aus:

• Solange du die Datei öffnen und eine Zeile daraus lesen kannst (immer die erste Zeile!), führe den Schleifenrumpf aus.

Kiigass schrieb:

nun das exit 0 gibt meines Wissens nach eine 0 an die Shell zurück. In diesem Falle könnte man sicherlich auch darauf verzichten, weil sonst ja der Rückgabewert von echo übergeben wird und es sonst keine Verzweigungen und exits gibt, aber ich habe mich durch viele andere Programmiersprachen daran gewöhnt jeder Funktion einen definierten Rückgabewert zu geben.

In vielen Ländern bedeutet Kopfschütteln Nein, und nicken Ja. In Bulgarien ist es aber umgekehrt. Bulgarien beginnt mit B wie Bash.

Ich halte das für eine saubere(re) Programmierung.

Dein Script gibt sowieso zurück, was der letzte Fehler war - also mutmaßlich 0. Du könntest mit einem ausdrücklichen 0 also lediglich verschleiern, dass es einen Fehler gab.

Außerdem könnte jemand auf die Idee kommen Dein Script zu sourcen, und peng - geht sein Shellfenster zu, weil er ja exit ausgesprochen hat. Und das kann wirklich sehr ärgerlich sein. So ein exit ist wie eine kl. Handgranate, und sollte auch so gehandhabt werden. Es ist eben kein return.

Es hat also 0 Vorteile, und 2 entscheidende Nachteile hier exit zu benutzen. Dazu kommt der Metanachteil, dass andere das hier sehen, und übernehmen. Das Wiki ist voll von diesem Blödsinn.

Wenn man Muster imitiert, die man wo gesehen, aber nicht verstanden hat, nennt man das übrigens Cargo-Cult-Programmierung.

Und meine Ansprache diesbezüglich ist bewusst schroff und kompromisslos gehalten, weil ich in der Sache kompromisslos bin.