user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
| date +"%d.%m.%Y $(echo "$NEU-$ALT" | bc)" >> kwh_tag.txt
|
@schragge:
Wieso benutzt Du mal Apostrophe, mal Anführungsstriche und wozu überhaupt (Zeile 2, 3, 4 und Anfang 5)?
|
schragge
Anmeldungsdatum: 27. Januar 2022
Beiträge: 159
|
user_unknown schrieb: @schragge:
Wieso benutzt Du mal Apostrophe, mal Anführungsstriche und wozu überhaupt (Zeile 2, 3, 4 und Anfang 5)?
Zitat aus Bash-Skripting-Guide für Anfänger (Abschnitt „Quoting“): Variablen, die mit Dateinamen belegt sein können, sollten in doppelten Anführungszeichen stehen.
|
user_unknown
(Themenstarter)
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
schragge schrieb: user_unknown schrieb: @schragge:
Wieso benutzt Du mal Apostrophe, mal Anführungsstriche und wozu überhaupt (Zeile 2, 3, 4 und Anfang 5)?
Tja, da werden Situationen benannt, in denen man Quotes braucht, aber hier trifft nichts davon zu.
Wir sehen den Pfad und die Dateinamen in ihrer vollen Pracht als literale Konstanten ohne irgendein Zeichen, das des Quotings bedürfte.
Ein schönes Beispiel für Sich-selbst-ins-Knie-schießen. @13:30 benutzt er überflüssige Quotes für echo, um dann kompliziert herumzudoktern und die Quotes auszuschalten, weil er dann wirklich Quotes braucht. | echo foo bar\'bla
foo bar'bla
|
ist alles was er braucht. Er benutzt 7 statt 2 Zeichen und erklärt das ganze auch noch als besser lesbar (als seine Alternative mit 6 Zeichen).
Zitat aus Bash-Skripting-Guide für Anfänger (Abschnitt „Quoting“): Variablen, die mit Dateinamen belegt sein können, sollten in doppelten Anführungszeichen stehen.
Wenn man sehr gutmütig ist, dann kann man das so verstehen, dass eine Variable, deren Inhalt erst zur Laufzeit festgelegt wird, weil der User den Wert vielleicht als Argument übergeben hat, maskiert werden sollten um Wordsplitting zu vermeiden, falls der Name Whitespace enthält. Wenn man aber weiß, dass der Name keine Zeichen enthält, die der Maskierung bedürfen, ist das überflüssiger Kokolores und eher schädlich, da es dem Leser des Codes ja signalisiert, dass da etwas ist, das der Maskierung bedarf - sonst würde man es ja nicht maskieren. Der schlechte Stil kommt daher, dass viele Shellskripter die Shell nur sporadisch nebenbei nutzen, ohne es mal richtig zu lernen, und dann Angewohnheiten aus anderen Sprachen importieren, wie das Einfassen von Strings in Anführungsstrichen - das kennen sie so von Python, Ruby oder C. Die Leute schließen dann auch gerne Kommandos mit Semikolon ab - gut, die Pythonleute vielleicht nicht so - und beenden ihre Skripte feierlich mit einem "exit 0;" Das ist Cargocult-Programmierung.
|
schragge
Anmeldungsdatum: 27. Januar 2022
Beiträge: 159
|
Und was wenn der Pfad dann später geändert wird, und bekommt ein Leerzeichen? In einem 5-Zeilen-Skript wäre das natürlich kein Problem, wenn es aber um mehrere Hundert Zeilen geht, besteht die Gefahr, das man Quoting an irgendeiner Stelle vergißt. Es gibt noch zwei Überlegungen für pauschales Quoting aller Zeichenfolgen in Shell-Skripten:
Sie werden dann in Text-Editoren einheitlich gefärbt; ShellCheck liefert keine Warnungen.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12832
|
schragge schrieb: Und was wenn der Pfad dann später geändert wird, und bekommt ein Leerzeichen? In einem 5-Zeilen-Skript wäre das natürlich kein Problem, wenn es aber um mehrere Hundert Zeilen geht, besteht die Gefahr, das man Quoting an irgendeiner Stelle vergißt.
Ich gehöre auch zu denen, die Variablen, die Dateinamen enthalten können, fast immer quoten.
Es gibt noch zwei Überlegungen für pauschales Quoting aller Zeichenfolgen in Shell-Skripten:
Sie werden dann in Text-Editoren einheitlich gefärbt; ShellCheck liefert keine Warnungen.
Pauschales Quoten ist eine schlechte Idee, finde ich. Manchmal will man tatsächlich mehrere getrennte Werte in einer Variablen haben, ohne gleich auf die bash wechseln zu müssen. Auch, wenn man weiß, dass eine Variable z.B. immer nur eine Zahl enthält, muss man nicht quoten.
|
user_unknown
(Themenstarter)
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
schragge schrieb: Und was wenn der Pfad dann später geändert wird, und bekommt ein Leerzeichen?
Dann kann man immer noch quoten, oder den Pfad und den Dateinamen heilen, so dass sie derlei nicht mehr enthalten. Such mal die Linuxkernelquellen nach Leerzeichen in Dateinamen ab und frag Dich, wieso die da wohl so selten sind.
In einem 5-Zeilen-Skript wäre das natürlich kein Problem, wenn es aber um mehrere Hundert Zeilen geht,
Ja, wenn der Pfad geändert wird und wenn das Skript auf 1000 Zeilen anwächst, und wenn der Betreuer keine Ahnung vom Shellscripten hat und wenn und wenn und wenn.
besteht die Gefahr, das man Quoting an irgendeiner Stelle vergißt.
Und das besteht nicht, wenn man von Anfang an alles quotet? Verlässt man sich dann nicht blind darauf, dass alles gequotet ist und ermuntert das einen nicht, intensiven Gebrauch von Leerzeichen, Zeilenumbrüchen und Schlimmerem in Datei- und Pfadnamen zu machen?
Es gibt noch zwei Überlegungen für pauschales Quoting aller Zeichenfolgen in Shell-Skripten:
Sie werden dann in Text-Editoren einheitlich gefärbt;
Du willst Dich auf Einfärbungen eines Editors verlassen, der Shellsyntax nicht versteht?
ShellCheck liefert keine Warnungen.
Du willst Dich auf Warnungen eines Hilfsmittels verlassen, das Shellsyntax nicht versteht?
|
Dakuan
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Ich denke, man muss das Thema mit Augenmaß behandeln, denn Quoting ist nicht das Allheilmittel. Ich habe da schon recht "schwierig" zu handhabende Dateinamen erlebt. So Dinger wie:
Some Swingin' Fingerpickin' Ragtime Guitar!-7Lu9EfIyatQ.mp4
sind da noch harmlos. Ich habe, bei Downloads, aber auch schon Dateinamen mit Doublequotes gesehen. Da hilft dann nur noch escapen. Und Dateinamen, die mit "-" oder Leerzeichen (Video-dowloadhelper) beginnen sind auch nicht wirklich selten. Natürlich versuche ich so etwas zu vermeiden, aber bei Downloads kann da auch mal was durchrutschen.
|
schragge
Anmeldungsdatum: 27. Januar 2022
Beiträge: 159
|
user_unknown schrieb: Sie werden dann in Text-Editoren einheitlich gefärbt;
Du willst Dich auf Einfärbungen eines Editors verlassen, der Shellsyntax nicht versteht?
Ich meinte überwiegend Vim und Neovim, die nutze ich am meisten. Hab jetzt mit mehreren Editoren
ausprobiert. Hier sind die Ergebnise: Konsoleneditoren, die nach deiner Definition Shellsyntax nicht verstehen: dte, Elvis, Emacs, JED, JOE, Kakoune, LE, mcedit, micro, nano, ne, Neovim, o, Pico, Textadept, THE, Tilde, vile, Vim, vis, XEmacs. GUI-Editoren, die nach deiner Definition Shellsyntax nicht verstehen: Atom, Bluefish, Code::Blocks, Emacs, Enki, Geany, gedit, GVim, jEdit, NEdit, Textadept, Visual Studio Code, xed, XEmacs, XNEdit, xvile. Der einzige GUI-Editor, der nach deiner Definition Shellsyntax versteht: Sublime Text. Für einen Konsoleneditor habe ich ein gemischtes Ergebnis: Led unterscheidet zwar nicht zwischen gequoteten und ungequoteten Zeichenfolgen,
da wird aber überhaupt sehr spärlich gefärbt: nur Codewords/Builtins, Nummern
und Kommentare. Sogar Klammern werden nicht hervorgehoben. user_unknown schrieb: schragge schrieb: ShellCheck liefert keine Warnungen.
Du willst Dich auf Warnungen eines Hilfsmittels verlassen, das Shellsyntax nicht versteht?
Ich habe zwar mal einen Fehler in ShellCheck gefunden, würde mich trotzdem immer darauf verlassen. Und auch anderen es gerne empfehlen. Es ist wirklich das beste Hilfsmittel für einen Shellskripter.
|
user_unknown
(Themenstarter)
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
schragge schrieb: user_unknown schrieb: Sie werden dann in Text-Editoren einheitlich gefärbt;
Du willst Dich auf Einfärbungen eines Editors verlassen, der Shellsyntax nicht versteht?
Ich meinte überwiegend Vim und Neovim, die nutze ich am meisten. Hab jetzt mit mehreren Editoren
ausprobiert. Hier sind die Ergebnise: Konsoleneditoren, die nach deiner Definition Shellsyntax nicht verstehen:
Ja, aber was heißt "nach deiner Definition" - welche alternative Definition hast Du denn anzubieten? Es ist ja ein Fakt, dass sie die Shellsyntax nicht verstehen oder dass sie etwas highlighten, was der User dann missversteht. Auf die Weise leiten sie den User also noch in die falsche Richtung. Nicht, dass Syntaxhighlightening für die Shell eine triviale Sache wäre - auch so ist das schon eine komplexe Aufgabe, mit Kommentaren in Text und Text in Kommentaren usw.
user_unknown schrieb: schragge schrieb: ShellCheck liefert keine Warnungen.
Du willst Dich auf Warnungen eines Hilfsmittels verlassen, das Shellsyntax nicht versteht?
Ich habe zwar mal einen Fehler in ShellCheck gefunden, würde mich trotzdem immer darauf verlassen. Und auch anderen es gerne empfehlen. Es ist wirklich das beste Hilfsmittel für einen Shellskripter.
Tja, nach meiner Erfahrung ist Shellcheck ein guter Assistent bei der Fehlersuche, aber man kann ihm nicht blind vertrauen.
|
schragge
Anmeldungsdatum: 27. Januar 2022
Beiträge: 159
|
user_unknown schrieb: Ja, aber was heißt "nach deiner Definition" - welche alternative Definition hast Du denn anzubieten?
Ich hab folgendermaßen getestet:
Und Sublime Text war der einzige Editor, der sowohl bar als auch baz als Zeichenketten erkannt, und beide einheitlich eingefärbt hat.
|
schragge
Anmeldungsdatum: 27. Januar 2022
Beiträge: 159
|
Dakuan schrieb: Ich habe da schon recht "schwierig" zu handhabende Dateinamen erlebt. So Dinger wie:
Some Swingin' Fingerpickin' Ragtime Guitar!-7Lu9EfIyatQ.mp4
Dein Beispiel ist ein bisschen daneben. Hier ist was ich meine:
| #!/bin/sh
foo="Some Swingin' Fingerpickin' Ragtime Guitar!-7Lu9EfIyatQ.mp4"
bar="${foo%.*}.ogv"
baz=${foo%.*}.webm
ffmpeg -i "$foo" -c:v libtheora -q:v 6 -c:a libvorbis -q:a 6 "$bar"
ffmpeg -i "$foo" -c:v libvpx-vp9 -crf 30 -b:v 0 -c:a libopus "$baz"
|
Alle sind einverstanden, dass es in den Zeilen 2, 5 und 6 gequotet werden muss. Wir streiten hier über die Zeilen 3 und 4. Ich würde in beiden Zeilen quoten, weil sie dann im Editor ähnlich wie Zeile 2 aussehen, was mich ästhetisch anspricht. user_unknown würde lieber nicht quoten, weil es von der Shellsyntax her nicht erforderlich ist.
|