Shell-Script mit if-Abfrage?
Hallo,
irgendwie bin ich gerade Betriebs-Blind... wo ist dieser verdammte Fehler?
Dieses Skript wird mit einer udev-Regel getriggert.
Der Output lautet:
Device detected: sda
...not assignable!
...wenn ich einen USB-Strick einstecke...
Da dies aber doch auf die erste if-Abfrage zutrifft sollte heir stehen:
Device detected: sda
...it's the Master-Stick!
Fehler selber gefungen... abgesehen davon, dass ich zweimal fragte ob "==" ist... es fehlten SPACES innerhalb der Eckigen Klammern...
FALSCH:
if [["$device" == "$trigger"]]; then
RICHTIG:
if [[_"$device" == "$trigger"_]]; then
3 Antworten
Hallo
irgendwie bin ich gerade Betriebs-Blind... wo ist dieser verdammte Fehler?
- muss ich mal meckern das Du statt eines Textes ein Bild bereitstellst, das ist zum einen blöd weil man es nicht bearbeiten kann und es zum anderen mehr Speicherplatz benötigt als die paar Zeilen Text.
- Dann fällt mir auf das Du bei den Angaben der Variablen Leerzeichen rechts & links vom Gleichheitszeichen benutzt - Das ist schonmal falsch.
- Auch fällt mir auch direkt auf das Du die eckigen Klammern direkt am Inhalt hast anstatt ein Leerzeichen zu benutzen - Das ist ebenso falsch.
- Ebenso verstehe ich nicht die doppelten eckigen Klammern wenn doch einfache genügen.
- Des weiteren steht in Deiner Abfrage zweimal "$device" == "$trigger" was so wohl auch keinen Sinn macht. Bestimmt sollte es sowas sein: if [ ${device} != ${trigger} ]; then... oder?
- Auch würde ich die Gänsefüßchen um die Variablen weglassen, schon weil sie dem Syntax-Highlightning entgegen wirken. Stattdessen könnte man die Variablenangaben in geschweifte Klammern setzen.
Das könnte etwa so aussehen:
#!/bin/bash
# Variablen definieren
DEV="$1"
TRIG="sda"
echo >> /home/pi/log.txt
echo "Device detected: $1" >> /home/pi/log.txt
if [ ${DEV} == ${TRIG} ]; then
echo "...it's the Master-Stick!" >> /home/pi/log.txt
elif [ ${DEV} != ${TRIG} ]; then
echo "...it's a Target-Stick!" >> /home/pi/log.txt
else
echo "...not assignable!" >> /home/pi/log.txt
fi
exit 0
Linuxhase
Wenn das alles so richtig ist, weshalb funktioniert dann sein Script nicht ;-)
Logik-Fehler, ist @XentriX5526 dann ja im Nachgang noch aufgefallen.
Bei mir funktioniert es wie beschrieben, egal was Deine Links sagen.
¯\_(ツ)_/¯
Es gibt (zumindest unter Debian) die Pakete shellcheck und devscripts, womit man seine Shell-Skripte validieren kann. Dort kann auch ein Standard angegeben werden (z. B. POSIX), sodass die Skripte auf diesen hin überprüft werden.
Tipp: Nutze die dash oder posh anstatt bash, so fallen dir bei der Entwicklung schneller Fehler auf.
Auch würde ich die Gänsefüßchen um die Variablen weglassen
Nein, die sind sehr sinnvoll um Fehler zu vermeiden. Am besten immer setzen, wenn man nicht sicher ist, dass die Variable niemals ein Leerzeichen beinhaltet.
Hinter der eckigen Klammer [ verbirgt sich das Programm /usr/bin/[
Du musst ein Leerzeichen tippen, damit der Interpreter erkennt, dass es sich dort um den Aufruf eines Unix-Werkzeuges handelt. Das Programm [ entspricht dem Programm /usr/bin/test.
Wenn du ein POSIX-kompatibles Shell-Skript schreiben möchtest, vergleichst du korrekterweise wie folgt zwei Strings:
#!/bin/sh
a="A"
b="B"
if [ "$a" = "$b" ]; then
# do something
fi
Die doppelten Klammern [[ und ]] sind nicht durch POSIX standardisiert.
Tipp: Schreibe deine Logik in Funktionen und rufe am Ende eine Funktion (ähnlich zur bekannten main Funktion) auf, die die einzelnen Funktionen aufruft.
Die Bedingungen in if und elif sind ja identisch, oder? So wird das nicht klappen.
Nein, das ist gelebte Praxis, Teil vieler Styleguides fuer Shell Skripting und einfach netter zu lesen.
Doublebrackets koennen mehr und sind nicht nur test.
https://www.tldp.org/LDP/abs/html/testconstructs.html#DBLBRACKETS
http://mywiki.wooledge.org/BashFAQ/031
http://mywiki.wooledge.org/BashGuide/Practices#Bash_Tests
Wie @PrinceSaid schon kommentiert hat: lieber benutzen. Das ist ebenfalls best practice: https://www.tldp.org/LDP/abs/html/quotingvar.html
Weiterfuehrend ist auch https://google.github.io/styleguide/shell.xml empfehlenswert zu lesen.