rustyhamsterr
Anmeldungsdatum: 4. Oktober 2015
Beiträge: Zähle...
|
Moin alle zusammen, dies is mien erster Post hier und gleich eine Frage 😛 Da ich leider zu diesem Thema nichts hilfreiches finden konnte, weder hier, noch in den Tiefen des Netzes, möchte ich kurz mein Problem schildern. Ich habe ein Skript, dass bei meinem Convertible Laptop, nach dem drehen des Monitors, die Tastatur und den Trackpoint deaktivieren soll, damit ich beim schreiben nicht wahllose Dinge drücke 😉 So viel zur Theorie. Das eigentliche Problem ist, dass im debug Modus -x -v deutlich wird, dass er Codestellen zu verschlucken scheint.
Bei if [Bed1] && [Bed2] habe ich es so verstanden, dass 2 nicht angeschaut wird, wenn 1 schon false liefert. Damit bin ich soweit einverstanden. Das Problem ist die zweite if Abfrage, denn sie wird nicht angerührt.
Der Code sieht wie folgt aus:
#!/bin/bash -xv
#pastmode=`cat /sys/devices/platform/thinkpad_acpi/hotkey_tablet_mode`
echo "autorotate script ist gestartet.00" >> /home/rusty/boot_stat
pastmode=$( cat /sys/devices/platform/thinkpad_acpi/hotkey_tablet_mode)
while [ true ]
do
nowmode=$( cat /sys/devices/platform/thinkpad_acpi/hotkey_tablet_mode)
if [ 1 -eq "$pastmode" ] && [ 0 -eq "$nowmode" ]; then #aus tablet mode kommend
echo "change detected" >> /home/rusty/boot_stat
. /usr/bin/rotate_none &
echo 0 > /usr/bin/rotationmode
`xinput set-prop "TPPS/2 IBM TrackPoint" "Device Enabled" 1`
`xinput set-int-prop 5 "Device Enabled" 8 1
echo "Trackpoint aktiv und Tastatur aktiv" >> /home/rusty/boot_stat
pastmode=0
fi
if [ 0 -eq "$pastmode" ] && [ 1 -eq "$nowmode" ]; then #in tablet mode wechseln
. /usr/bin/rotate_inverted &
`xinput set-prop "TPPS/2 IBM TrackPoint" "Device Enabled" 0`
`xinput set-int-prop 5 "Device Enabled" 8 0`u
echo "Trackpoint und Tastatur deaktiviert" >> /home/rusty/boot_stat
echo 2 > /usr/bin/rotationmode
pastmode=1
fi
sleep 5
done Um ein konzeptionelles Versagen auszuschließen, da ich mit der Bash-Programmierung noch nicht so firm bin, habe ich ein kurzes Testscript geschrieben.
Das so aussieht:
#!/bin/bash -xv
while [ true ]
do
a=3
if [ 2 -eq "$a" ] && [ 1 -eq "$a" ]; then
echo "test 1 true"
fi
if [ 3 -eq $a ]; then
echo "test 1 false"
fi
sleep 5
done Im Testskript funktioniert die Idee, von einem ersten if in ein zweites überzugehen(Wie auch in Bash Beispielen und anderen Programmiersprachen). Man kann das auch mittels eines elif lösen, was mir eine Rechenoperation spart, etc 😛 In der Konsole wird mir angezeigt, dass die erste Klammer bearbeitet wird, er vergleicht die beiden Zahlen. (erster eq Vergleich erste if. Danach geht er direkt auf sleep am ende Oo) Aktuell bin ich wirklich am Verzweifeln, da ich gerne den Fehler verstehen würde ich ihn aber nicht sehe *Kopfkratz*
Ich wäre euch sehr dankbar, wenn sich jemand bereit erklärt mir zu helfen ☺ Ich hoffe auf gute Zusammenarbeit, wenn ihr noch infos braucht (wovon ich eig nicht ausgehe), einfach raushauen ☺ Lg rusty
Edit Debug output
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17607
Wohnort: Berlin
|
Hast Du mal pastmode und nowmode ausgegeben? Ich verstehe Dich so, dass Deine Annahme ist, dass diese entweder 1:0 sein müssen oder 0:1 - vielleicht ist es beides nicht. | `xinput set-prop "TPPS/2 IBM TrackPoint" "Device Enabled" 0`
|
Wofür sind die Backticks hier gut? Mehr noch diese, mit angehängtem 'u'?
| `xinput set-int-prop 5 "Device Enabled" 8 0`u
|
|
rustyhamsterr
(Themenstarter)
Anmeldungsdatum: 4. Oktober 2015
Beiträge: 8
|
Hey, danke für die Antwort ☺
Ja das u ist hier nen Tippfehler gewesen. kommt im ode nicht vor *duck* Ich habe mir past und nowmode angesehen, werden mit ausgegeben. Die Werte sind korrekt, wenn der Laptop offen ist, dann ist der wert nowmode 0 und wenn als tablet, dann 1. Die werte werden ja auhc korrekt verlichen mit -eq, jedoch prüft er immer nur die erste
if [ 1 -eq "$pastmode" ] && [ 0 -eq "$nowmode" ] Die zweite unten im Code wird nie geprüft. Die müsste sonst ja auch in der Ausgabe bei bash -xv auftauchen. in der Ausgabe ist nur die erste Abfrage zu sehen und dann direkt sleep und nächster Durchlauf.. + '[' true ']'
cat /sys/devices/platform/thinkpad_acpi/hotkey_tablet_mode
++ cat /sys/devices/platform/thinkpad_acpi/hotkey_tablet_mode
+ nowmode=0
+ '[' 1 -eq 0 ']'
+ sleep 5
+ '[' true ']'
cat /sys/devices/platform/thinkpad_acpi/hotkey_tablet_mode
++ cat /sys/devices/platform/thinkpad_acpi/hotkey_tablet_mode
+ nowmode=0
+ '[' 1 -eq 0 ']'
+ sleep 5 Das mit den Backticks hatte ich iwo als mögliche Fehlerlösung gefunden.. Ich Doktor scon länger daran rum 😀 Aber er kommt ja nichtmal dahin, da er ja nicht in den Tablet mode wechselt... Standard Beginn ist pastmode 0
nowmode 0 //Ich klappe den Laptop
// erster Schleifendurchlauf: pastmode 0
nowmode 1 //weitere durchläufe alle 5 sek: pastmode 1
nowmode 1 Achso und ja, die Kombinationen 0:1 und 1:0 sind interessant, weil das die Wechsel sind: Tablet/Notebook.
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
Hi rusty, erstmal herzlich willkommen hier auf dem Forum ! Hast Du Dir mal genauer angesehen, was Du da tatsächlich gemacht hast ? Guck Dir mal im Bash Manual genau an, wie das true zu verwenden wäre, was das "&&" tatsächlich bedeutet und wie eine UND- Verknüpfung geschrieben wird ... 😉 Du kannst Dich auch einfach in unserem Bash- Wiki einlesen. LG, track
|
rustyhamsterr
(Themenstarter)
Anmeldungsdatum: 4. Oktober 2015
Beiträge: 8
|
Hey track,
ich habe mir nun die Referenzen angeschaut.. da steht auch, && ist ein logischer Operator. Und ich verwende das doch auch hier als solchen.
Auch im wiki steht, dass && zum aneinderreihen von Befehlen/Tests verwendet wird.
Und da steht auch, bei mehreren Tests (mit && Verknüpft) wird halt nur das erste angeschaut und das zweite nur, wenn die Gesamtaussage nicht schon entschieden ist. Das leuchtet mir soweit ein und ist auch das was ich von meinem Befehl möchte.. Denke ich zumindest 😀 Wenn dem nicht so ist, gib mir nen Hinweis, was genau du meinst. Es kann auch sein, dass wir aneinander vorbeireden. Mir geht es halt darum, dass das zweite if in der while Schleife nicht angesehen wird. Zum true, ja ich sollte der Korrektheit wegen die Endlos while Schleife ohne die Klammern machen, da auch der Befehl false true zurückliefern würde wenn er in Klammern steht. Das sollte aber gehüpft wie gesprungen sein, wie man so sagt, denn die Schleife wird ja endlos ausgeführt 😉 P.S. ich möchte nicht den Eindruck erwecken, ich bräuchte alles komplett vorgekaut 😀 Ich bin bereit zu lernen, das ist der Plan, nur muss mich irgendwer in die richtige Richtung schubsen, da ich sie offensichtlich nicht sehe :/
|
Mooi
Anmeldungsdatum: 15. August 2014
Beiträge: 187
|
Wenn zwei Bedingungen mit UND verknüpft sind, und die erste Bedingung failt, braucht die zweite Bedingung gar nicht mehr geprüft werden. Denn das wird nichts mehr mit dem UND.
|
rustyhamsterr
(Themenstarter)
Anmeldungsdatum: 4. Oktober 2015
Beiträge: 8
|
Hi Mobi, das verstehe ich ja, deshalb steht das auch in den bisherigen Posts drin.
Um es nochmal deutlich zu machen: Es geht nicht um das [Bed1] && [Bed2] es geht um das zweite if
Verdeutlicht am Bsp Script: #!/bin/bash -xv
while [ true ]
do
a=3
if [ 2 -eq "$a" ] && [ 1 -eq "$a" ]; then
echo "test 1 true"
fi
# dieses ist das zweite if
if [ 3 -eq $a ]; then #<------- wird im tatsächlichen script (Eingangspost) nicht geprüft
echo "test 1 false"
fi
sleep 5
done Im Testscript wird es auch genutzt und geschaut ob a=3 ist. In dem richtigen script, dass ich darüber gepostet habe, ist im debug Modus nichts davon zu sehen, dass das zweite if überhaupt erreicht wird. Das ist, was ich komisch finde, denn nicht geschachtelte, nacheinanderfolgende if Abfragen, sollten immer angeschaut werden (wenigstens immer die erste Bedingung, abhängig davon etwaige folgende) korrekt?
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17607
Wohnort: Berlin
|
rustyhamsterr schrieb: Hey, danke für die Antwort ☺
Ja das u ist hier nen Tippfehler gewesen. kommt im ode nicht vor *duck*
Um sowas zu vermeiden bitte den fehlschlagenden Code mit Cut-und-Paste übertragen, sonst korrigiert man beim Übertragen nämlich auch leicht mal Fehler. Poste den nochmal.
|
ExcitedSpoon
Anmeldungsdatum: 17. Juli 2010
Beiträge: 226
Wohnort: /home/berlin
|
Hi, ich hab jetzt ne Weile versucht das seltsame Verhalten zu reproduzieren, was du beschrieben hast, bekomme es aber (zum Glück?) nicht hin. Da ich kein thinkpad mit tablet-mode habe, hab ich das auslesen der tp-acpi mit einem read -input (du musst 0 oder 1 für den nowmode eingeben) getestet. Verhält sich bei mir wie erwartet. Teste mal folgendes Script selbst. Habe lediglich sleep (zum debuggen) und die Befehle in den if-Blöcken entfernt:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 | #!/bin/bash -xv
pastmode=1
while true; do
read -p "enter nowmode (0 or 1): " nowmode
echo "past: $pastmode now: $nowmode"
if [ 1 -eq "$pastmode" ] && [ 0 -eq "$nowmode" ]; then
echo "Trackpoint aktiv und Tastatur aktiv"
pastmode=0
fi
if [ 0 -eq "$pastmode" ] && [ 1 -eq "$nowmode" ]; then
echo "Trackpoint und Tastatur deaktiviert"
pastmode=1
fi
done
|
Ich würde das generell eher mit nem case-switch machen. Ist geschmackssache, aber für mich ist sowas übersichtlicher:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19 | #!/bin/bash -xv
last=1
while true; do
read -p "enter now (0 or 1): " now
case "${last}${now}" in
01)
echo "Trackpoint und Tastatur deaktiviert"
last=1 ;;
10)
echo "Trackpoint aktiv und Tastatur aktiv"
last=0 ;;
00|11)
continue ;; # nothing to do
*)
echo "$(date +"%Y-%m-%d %H:%M:%S") error: invalid state: $last:$now" >> /tmp/tablet-mode-error.log ;;
esac
done
|
Grüße
|
rustyhamsterr
(Themenstarter)
Anmeldungsdatum: 4. Oktober 2015
Beiträge: 8
|
Heyo,
@unknown: Es war kopiert aus nano.. da nicht alles auf eine Seite passte wurde es von mir in 2 Blöcken kopiert. Nächstesmal wird das mit gedit geöffnet und kopiert, versprochen 😉 @ExcitedSpoon: Dein Script mit der Eingabe der modi funktioniert und alles wird durchlaufen, wie auch bei meinem kurzen Testscript wird jede Bedingung überprüft, auch die des zweiten if 😉 Ich werde jetzt den Rumpf von dir nehmen und meinen Code da reinhauen. Ich melde mich dann ob es funktioniert.
Du hast doch auch nichts anders gemacht, strukturell gesehen 😀 Meld mich gleich wieder
Edit: Meiner Meinung nach sieht der Code jetzt, auf das if Bezogen ganu so aus wie vorher bei mir, aber es geht Oo
Er schaut sich alle Bedinungen an und verarbeitet sie korrekt.. kurios... Vielleicht hat das einfach nochmal alles neu tippen geholfen.. Ich habe keine Ahnung 😀 Aber euch allen, die sich die Mühe gemacht haben mir zu helfen und mich vor dem Wahnsinn zu bewahren ein dickes DANKE ☺ In Anlehnung an Hape Kerkeling: Erkenntnis des Tages! Wenn sich ein Script ohne logischen Grund und trotz konzeptioneller Korrektheit absolut unerklärlich verhält: Tippe es ab, bevor du die Community bemühst. 😉 Nächste sache der ich nachgehe: wie mache ich die schnuckeligen Zeilenzahlen?, hab die hier schon öfter gesehen 😛
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17607
Wohnort: Berlin
|
rustyhamsterr schrieb: In Anlehnung an Hape Kerkeling: Erkenntnis des Tages! Wenn sich ein Script ohne logischen Grund und trotz konzeptioneller Korrektheit absolut unerklärlich verhält: Tippe es ab, bevor du die Community bemühst. 😉
Naja. Wenn man jeden Fehler versucht dadurch zu beheben, dass man den Lösungsweg vom letzten Mal beschreitet, dann kommt man nicht weit - es gibt massig unterschiedlicher Fehlerquellen. Hast Du alte, nichtfunktionierende Script noch? Könntest Du es mit rückwärts-cut-n-paste restaurieren? Dann könntest Du ein diff machen, um die Fehlerquelle exact einzugrenzen. Hast Du es ursprünglich vielleicht auf einem Win-System getippt?
Nächste sache der ich nachgehe: wie mache ich die schnuckeligen Zeilenzahlen?, hab die hier schon öfter gesehen 😛
Wenn Du die Code-Box des Syntaxhighlightenings aktivierst erscheinen die automatisch, aber nicht bei jeder Sprache bzw. erst ab einer gew. Zeilenzahl sowie ich weiß. In der Shell gibt es dafür nl (number lines), aber es empfiehlt sich nicht dieses für's Forum zu verwenden, weil dann der, der es rauskopiert, auch die Zeilennummern im Code hat.
|
rustyhamsterr
(Themenstarter)
Anmeldungsdatum: 4. Oktober 2015
Beiträge: 8
|
Hey unknown, hab das mal mit nem diff angeschaut und noch an der letzen stelle im orig code die backticks entfernt... Es geht Oo vmtl waren die die Ursache.. Aber ich verstehe nicht wieso, da sie ja in dem if statement eingekapselt sind, das nicht betreten wird.. Du hast sie zurecht infrage gestellt 😀 Ich habe das im Netz gefunden, dass die Befehle damit eingeschlossen werden. Weiß aber grade echt nichtmehr wo, das ist zu lang her ☹ Ich ändere die Lektion des Tages in: böse backticks...
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17607
Wohnort: Berlin
|
Backticks werden (nicht mehr) verwendet, um einer Variablen den Output eines Kommandos zuzuweisen z.B.: Aber es wird von ihnen abgeraten, denn es führt oft zur Verwechslung mit Apostrophen, sie lassen sich nicht schachteln und sie sind weniger portabel als die Alternative: Interessant, dass sie zu dem Fehler geführt haben - einen Reim kann ich mir nicht drauf machen und mit $(...) wäre es wohl auch passiert. Ohne Zuweisung zu einer Variablen wird der Output als Befehl ausgeführt, Beispiel:
| $(echo "echo a echo b echo c" | awk '{print $3" "$4}')
b
|
falls Du weiter darüber grübeln willst. 'Backticks are evil' ist aber ein guter Merksatz.
|
rustyhamsterr
(Themenstarter)
Anmeldungsdatum: 4. Oktober 2015
Beiträge: 8
|
Wenn das für die zuweisung ist, dann dürfen sie ja auch garnicht um den Befehl sein, so wie es bei meinem xinput der Fall war.
Will ja, dass er den Mist ausführt 😛 nur hätte ich nicht gedacht, dass sie Probleme verursachen ohne, dass die Passagen angerührt werden... Ich kratz mich weiter am Kopf.. 😀 Verwende für die Zuweisung eh $().. Habe in meiner suche nach Fehlern einfach zu gewillt nach jedem Strohhalm gegriffen 😀 Also nochmal Danke an alle ☺
Hab jetzt noch mehr Freude am x220t, da ich nichtmehr aufpassen muss, ob ich das display bewege oder net und damit mehr rumrennen kann ☺) *thumbsup*
|
Mooi
Anmeldungsdatum: 15. August 2014
Beiträge: 187
|
Hast Du das alte Script irgendwie mit Windows bearbeitet? Die Windows-Zeilenenden produzieren auf Linux die seltsamsten Fehler.
|