staging.inyokaproject.org

Moin moin, ich habe folgendes Problem: Ich möchte den Inhalt einer Variable verändern, ich möchte Zeilenumbrüche einfügen.

1
2
3
4

VAR1="Hallo wie geht es euch"
VAR1=$(echo $VAR1 | sed 's/wie/\nwie\n/g')
echo $VAR1
#ergibt leider : "Hallo wie geht es euch"

Was mache ich falsch?

1
2
3
4

echo "$VAR1"
Hallo 
wie
 geht es euch

Shellmaskierung von Whitespace, $IFS sind Schlüsselworte für die Suche. Womöglich möchtest Du so was:

1
2
3
4
5

VAR1=$(echo $VAR1 | sed 's/wie /\nwie\n/g')
echo "$VAR1"
Hallo 
wie
geht es euch

Bei dem echo in $(…) würde ich glaube ich auch schon quoten. Ich quote ja sowieso gerne. Besser zu viel als wenn man es dann irgendwo vergisst. ☺

Marc_BlackJack_Rintsch schrieb:

Bei dem echo in $(…) würde ich glaube ich auch schon quoten.

Brauchst Du nicht:

1
2
3
4
5
6

$ foo=$(echo -e 'abc\ndef')
$ echo $foo
abc def
$ echo "$foo"
abc
def

Man muss nur bei der Ausgabe quoten.

Ich quote ja sowieso gerne. Besser zu viel als wenn man es dann irgendwo vergisst. ☺

☺ Genau, schaden tut es jedenfalls nicht.

Wieso brauche ich das nicht?

1
2
3
4

$ foo=$(echo -e 'abc\ndef')
$ foo=$(echo $foo)
$ echo "$foo"
abc def

$VAR1 in dem Beispiel vom OP war ”harmlos”, aber da kann ja sonstwas drin stehen was man nicht einfach so ungequoted an echo übergeben möchte. Der Satz könnte auch mit einem ! enden oder ein & enthalten oder * oder $RANDOM oder…

Marc_BlackJack_Rintsch schrieb:

Wieso brauche ich das nicht?

$VAR1 in dem Beispiel vom OP war ”harmlos”, aber da kann ja sonstwas drin stehen was man nicht einfach so ungequoted an echo übergeben möchte. Der Satz könnte auch mit einem ! enden oder ein & enthalten oder * oder $RANDOM oder…

Nein, da kann nicht sonstwas drin stehen. Jedenfalls nicht von selbst.

Wenn was anderes drin steht ist es ein anderes Script und dann kann es sein, dass es gequotet werden muss, es kann aber auch sein dass es dann weiterhin nicht gequotet werden muss. Die Annahme, dass der Inhalt geändert wird, ist eine Spekulation aus dem Nichts.

Ebenso kann man spekulieren, dass das Programm in Python implementiert worden soll - dafür könnte man andere Vorkehrungen treffen um dann weniger Aufwand zu haben.

Es ist Zeitverschwendung in Hinblick auf eine irgendwie vage, mögliche Zukunft Maßnahmen zu ergreifen. Später Quotes einzufügen wo sie nötig sind ist nicht mehr Arbeit, als sie gleich einzufügen aber mehr Arbeit als es zu lassen, wenn es dann später gar nicht benötigt wird.

Vor allem aber nährt es die Illusion, es sei syntaktisch notwendig und behindert damit die Erkenntnis, wozu Quotes überhaupt in der Bash und ähnlichen Shells nötig sind, denn in vielen anderen Sprachen sind Quotes ja syntaktisch nötig.

Wie wäre es mit:

1
2
3
4
5

#!/bin/bash

VAR1="Hallo wie geht es euch"
VAR1=${VAR1// /\\n}
echo -e $VAR1

@user_unknown: Das war ganz klar ein Beispiel, also ist das alles andere als Spekulation, dass im tatsächlichen Code ein anderer Text steht. Und nur zu quoten wenn es wirklich nötig ist, also immer alles anzuschauen und explizit nicht zu quoten wenn mit den aktuellen Werten kein Problem entsteht, bedeutet das man bei Änderungen immer das ganze Skript nach allen möglichen Folgen absuchen muss. Das macht es dann sehr wahrscheinlich, dass das dann nicht gemacht wird, denn es ist eben doch mehr Arbeit als es gleich zu machen, denn wenn man es gleich macht, muss man die Stellen nicht erst suchen und muss sich auch nicht erst wieder in das Skript einarbeiten. Selbst wenn man es nie wieder ändert, hat man mehr Arbeit darüber nachzudenken was nicht gequoted werden muss, statt es einfach grundsätzlich zu machen.

Wenn man nur das Allernötigste quoted, hat man im besten Fall Skripte die scheinbar funktionieren, bis man dann halt mal auf einen Fall trifft wo's schief läuft. Im schlechteren Fall fällt das dann wegen irgendwelcher Sonderzeichen, zum Beispiel Leerzeichen in Dateinamen auf die Nase. Und wenn's ganz blöd kommt, hat man sich eine Sicherheitslücke eingebaut.

Ich mache mir doch nicht mehr Arbeit um unsicherere Skripte zu schreiben, nur weil da irgendjemand eine falsche Vorstellung von Shell-Syntax bekommen könnte. Grundsätzlich zu quoten, ausser man möchte das semantisch tatsächlich mal nicht, ist eine einfache, schnell umgesetzte Massnahme um Fehler zu vermeiden, die so gut wie nichts kostet. Das anders zu machen führt allzu häufig zu Skripten die auch im Jahr 2018 nicht mal mit Leerzeichen in Dateinamen klar kommen.

Marc_BlackJack_Rintsch schrieb:

Wieso brauche ich das nicht?

1 2 3 4

$ foo=$(echo -e 'abc\ndef') $ foo=$(echo $foo) $ echo "$foo" abc def

$VAR1 in dem Beispiel vom OP war ”harmlos”, aber da kann ja sonstwas drin stehen was man nicht einfach so ungequoted an echo übergeben möchte. Der Satz könnte auch mit einem ! enden oder ein & enthalten oder * oder $RANDOM oder…

Du hast aber den Testaufbau geändert. Auch in Deinem Fall musst Du nicht $(...) quoten sondern innerhalb! Der Zeilenumbruch geht nämlich da schon verloren:

1
2
3
4
5

$ foo=$(echo -e 'abc\ndef')
$ foo=$(echo "$foo")
$ echo "$foo"
abc
def

Aaargh! Ich merke gerade, ich habe Dich missverstanden. Ich dachte, Du meintest außen herum. Aber Du meintest innerhalb der runden Klammern. Ja, das ist richtig. 👍

Marc_BlackJack_Rintsch schrieb:

@user_unknown: Das war ganz klar ein Beispiel, also ist das alles andere als Spekulation, dass im tatsächlichen Code ein anderer Text steht. Und nur zu quoten wenn es wirklich nötig ist, also immer alles anzuschauen und explizit nicht zu quoten wenn mit den aktuellen Werten kein Problem entsteht, bedeutet das man bei Änderungen immer das ganze Skript nach allen möglichen Folgen absuchen muss.

Wieso sollte das der Fall sein?

Wenn Du den Text änderst, so dass er Quotes braucht, machst Du eben Quotes hin.

Das macht es dann sehr wahrscheinlich, dass das dann nicht gemacht wird, denn es ist eben doch mehr Arbeit als es gleich zu machen, denn wenn man es gleich macht, muss man die Stellen nicht erst suchen und muss sich auch nicht erst wieder in das Skript einarbeiten.

Nein. Wenn Du den Text änderst, dann hast Du ja eine Vorstellung davon, wie es bisher aussah und wie es zukünftig aussehen soll.

Selbst wenn man es nie wieder ändert, hat man mehr Arbeit darüber nachzudenken was nicht gequoted werden muss, statt es einfach grundsätzlich zu machen.

Und wenn der Text selbst Quotes enthält?

Wenn man nur das Allernötigste quoted,

Es gibt kein Spektrum von nötigen Quotes, sehr nötigen Quotes und nötigsten Quotes. Entweder sie sind nötig oder nicht.

hat man im besten Fall Skripte die scheinbar funktionieren, bis man dann halt mal auf einen Fall trifft wo's schief läuft. Im schlechteren Fall fällt das dann wegen irgendwelcher Sonderzeichen, zum Beispiel Leerzeichen in Dateinamen auf die Nase. Und wenn's ganz blöd kommt, hat man sich eine Sicherheitslücke eingebaut.

Hätte, hätte, Fahrradkette.

Die Fehler, von denen Du sprichst, müsste man erst einbauen um sie zu haben. Man kann auch auf eine Reise in die Sahara einen Regenschirm mitnehmen, denn wenn man sich verfährt, und in London rauskommt, muss man sich dann dort keinen kaufen.

Ich mache mir doch nicht mehr Arbeit um unsicherere Skripte zu schreiben, nur weil da irgendjemand eine falsche Vorstellung von Shell-Syntax bekommen könnte. Grundsätzlich zu quoten, ausser man möchte das semantisch tatsächlich mal nicht, ist eine einfache, schnell umgesetzte Massnahme um Fehler zu vermeiden, die so gut wie nichts kostet. Das anders zu machen führt allzu häufig zu Skripten die auch im Jahr 2018 nicht mal mit Leerzeichen in Dateinamen klar kommen.

Ich habe keinen Dateinamen gesehen.

Keine Sorge, ich werde nicht wieder den Terminus Cargo-Cult-Programmierung in die Debatte einbringen.

Ich habe nämlich einen neuen: Strohmannprogrammierung.

Man benutzt ein Mittel mit dem man ein Problem lösen könnte, das man gar nicht hat. Stellvertretend für die Leute, die das Problem haben und es nicht lösen.

user_unknown schrieb:

Marc_BlackJack_Rintsch schrieb:

@user_unknown: Das war ganz klar ein Beispiel, also ist das alles andere als Spekulation, dass im tatsächlichen Code ein anderer Text steht. Und nur zu quoten wenn es wirklich nötig ist, also immer alles anzuschauen und explizit nicht zu quoten wenn mit den aktuellen Werten kein Problem entsteht, bedeutet das man bei Änderungen immer das ganze Skript nach allen möglichen Folgen absuchen muss.

Wieso sollte das der Fall sein?

Wenn Du den Text änderst, so dass er Quotes braucht, machst Du eben Quotes hin.

Ja aber eben überall dort wo das im Skript Änderungen nach sich zieht und diese Stellen muss man dann eben erst mal alle ausfindig machen. Es ist ja noch nicht einmal so das der Text selbst Quotes brauchen muss. Beispiel die Zuweisung eines ehemals ”harmlosen” Wertes für var wird geändert zu:

1

var=< * >

Das braucht keine Quotes, aber man muss jetzt überall schauen wo $var oder Werte die von dem Wert von $var irgendwie abgeleitet werden verwendet werden und ob das jetzt alles entsprechend gequoted ist. Wenn man grundsätzlich quoted wo es nötig sein könnte, kann man die Änderung machen ohne das es irgendwo Probleme damit gibt.

Das macht es dann sehr wahrscheinlich, dass das dann nicht gemacht wird, denn es ist eben doch mehr Arbeit als es gleich zu machen, denn wenn man es gleich macht, muss man die Stellen nicht erst suchen und muss sich auch nicht erst wieder in das Skript einarbeiten.

Nein. Wenn Du den Text änderst, dann hast Du ja eine Vorstellung davon, wie es bisher aussah und wie es zukünftig aussehen soll.

Fremde haben aber keine Vorstellung davon. Die Erfahrung sagt, das man spätestens nach x Monaten selbst der Fremde ist, der sich wieder in den Code einarbeiten muss. Wenn Dir das nicht so geht hast Du Glück, aber den meisten Programmierern geht es anders.

Selbst wenn man es nie wieder ändert, hat man mehr Arbeit darüber nachzudenken was nicht gequoted werden muss, statt es einfach grundsätzlich zu machen.

Und wenn der Text selbst Quotes enthält?

Dann escaped man die entsprechend‽

hat man im besten Fall Skripte die scheinbar funktionieren, bis man dann halt mal auf einen Fall trifft wo's schief läuft. Im schlechteren Fall fällt das dann wegen irgendwelcher Sonderzeichen, zum Beispiel Leerzeichen in Dateinamen auf die Nase. Und wenn's ganz blöd kommt, hat man sich eine Sicherheitslücke eingebaut.

Hätte, hätte, Fahrradkette.

Die Fehler, von denen Du sprichst, müsste man erst einbauen um sie zu haben. Man kann auch auf eine Reise in die Sahara einen Regenschirm mitnehmen, denn wenn man sich verfährt, und in London rauskommt, muss man sich dann dort keinen kaufen.

Nette Sprüche, nur ist es wesentlich wahrscheinlicher das ein Skript auf die Nase fällt weil jemand nicht konsequent gequoted hat, als das man sich auf dem Weg in die Sahara nach London verfährt. Zumal man den Schirm in der Sahara auch gut gegen die Sonne verwenden kann. Ich habe mich noch nie auf dem Weg in die Sahara nach London verfahren, und habe das auch noch von keinem gehört. Das Skripte nicht mit Leerzeichen in Dateinamen klargekommen sind und das durch ein paar Quotes einfach heilbar war, habe ich allerdings schon öfter gehört, und auch selbst erlebt.

Keine Sorge, ich werde nicht wieder den Terminus Cargo-Cult-Programmierung in die Debatte einbringen.

Ich habe nämlich einen neuen: Strohmannprogrammierung.

Ich setze „Defensive Programmierung“ dagegen.

Man benutzt ein Mittel mit dem man ein Problem lösen könnte, das man gar nicht hat. Stellvertretend für die Leute, die das Problem haben und es nicht lösen.

Doch ich löse damit ein Problem das ich habe: Ich möchte weder jetzt noch später darüber nachdenken müssen ob wirklich gequoted werden muss, weil der Nutzen es einfach zu tun für mich deutlich höher ist als die Kosten. Quoten ist billig, sowohl beim schreiben als auch beim ausführen. Fehler aufgrund fehlenden Quotens suchen und bei jeder Änderung immer wieder schauen was davon betroffen ist und dann neu gequoted werden muss, oder was dann nicht mehr gequoted werden muss, kostet wesentlich mehr Zeit.

Marc_BlackJack_Rintsch schrieb:

Beispiel die Zuweisung eines ehemals ”harmlosen” Wertes für var wird geändert zu:

1

var=< * >

Das braucht keine Quotes,

Das halte ich für ein Gerücht.

1
2

var=< * >
bash: Syntaxfehler beim unerwarteten Wort »newline«

aber man muss jetzt überall schauen wo $var oder Werte die von dem Wert von $var irgendwie abgeleitet werden verwendet werden und ob das jetzt alles entsprechend gequoted ist. Wenn man grundsätzlich quoted wo es nötig sein könnte, kann man die Änderung machen ohne das es irgendwo Probleme damit gibt.

Jemand, der nicht weiß, dass var=< * > ein Syntaxfehler ist, den sollte man prinzipiell nicht an Produktivcode heranlassen.

Das macht es dann sehr wahrscheinlich, dass das dann nicht gemacht wird, denn es ist eben doch mehr Arbeit als es gleich zu machen, denn wenn man es gleich macht, muss man die Stellen nicht erst suchen und muss sich auch nicht erst wieder in das Skript einarbeiten.

Nein. Wenn Du den Text änderst, dann hast Du ja eine Vorstellung davon, wie es bisher aussah und wie es zukünftig aussehen soll.

Fremde haben aber keine Vorstellung davon. Die Erfahrung sagt, das man spätestens nach x Monaten selbst der Fremde ist, der sich wieder in den Code einarbeiten muss. Wenn Dir das nicht so geht hast Du Glück, aber den meisten Programmierern geht es anders.

Ich muss selbst wissen, was wann gequotet werden muss und wann nicht oder ich muss zumindest wissen was ich nicht weiß, um für den Fall des Falles überprüfen zu können, ob das, was ich machen will, funktioniert. Das Quoten in der Shell ist prinzipiell schwer, daher weiß ich vieles nicht auswendig. Aber was heikel werden kann, kann ich riechen. "< * >" sieht super heikel aus - hier lauern Dateiumlenkungen und Globbing und wenn da vorher stand var="foo", jetzt steht da var="< * >", dann würde ich schauen wie $var im weiteren Verlauf benutzt wird. Dass da jemand fremdes Quotes gesetzt hat, darauf würde ich mich nicht verlassen.

Wenn derjenige nur ich selbst sein kann, vor mehr als 6 Monaten, und ich einerseits immer alles quote, was bei 3 nicht auf den Bäumen ist, und zweitens alles Scripte mit shellcheck checke, bis keine Warnungen mehr auftreten, dann weiß ich immer noch nicht, ob die Besetzung mit "< * >" harmlos ist. In anderen Fällen wie "dummes Blank.txt" wäre ich mir da dann aber relativ sicher.

Bei Skripten, die ich schreibe, weiß ich in 90% der Fälle vorher, ob da Blanks oder sonst zu maskierendes stehen darf oder nicht und schreibe das Skript dementsprechend. Und wenn ich eins ändern muss, weil ich unerwarteter Weise doch etwas verarbeiten muss, was maskiert werden muss, dann weiß ich auch noch genug um schnell zu finden, wo die Änderung ansetzen muss und von da ergibt sich auch rasch, welche Stellen in Folge kontrolliert werden müssen.

Ich weiß aber nicht wie lang Deine Scripte sind, dass das eine Schwierigkeit für Dich darstellt. Das vorgestellte Beispiel ist kurz und gibt Anlass für Sorge und Ängste nicht her.

Selbst wenn man es nie wieder ändert, hat man mehr Arbeit darüber nachzudenken was nicht gequoted werden muss, statt es einfach grundsätzlich zu machen.

Und wenn der Text selbst Quotes enthält?

Dann escaped man die entsprechend‽

Und muss die spätere Verwendung im Script nicht überprüfen?

hat man im besten Fall Skripte die scheinbar funktionieren, bis man dann halt mal auf einen Fall trifft wo's schief läuft. Im schlechteren Fall fällt das dann wegen irgendwelcher Sonderzeichen, zum Beispiel Leerzeichen in Dateinamen auf die Nase. Und wenn's ganz blöd kommt, hat man sich eine Sicherheitslücke eingebaut.

Hätte, hätte, Fahrradkette.

Die Fehler, von denen Du sprichst, müsste man erst einbauen um sie zu haben. Man kann auch auf eine Reise in die Sahara einen Regenschirm mitnehmen, denn wenn man sich verfährt, und in London rauskommt, muss man sich dann dort keinen kaufen.

Nette Sprüche, nur ist es wesentlich wahrscheinlicher das ein Skript auf die Nase fällt weil jemand nicht konsequent gequoted hat, als das man sich auf dem Weg in die Sahara nach London verfährt.

Nein.

So wie das Skript ist funktioniert es.

Vermutungen, welche Änderungen es durchlaufen wird, und welche, entbehren jeder Grundlage. Was da wahrscheinlich ist oder nicht kannst Du nicht wissen.

Zumal man den Schirm in der Sahara auch gut gegen die Sonne verwenden kann. Ich habe mich noch nie auf dem Weg in die Sahara nach London verfahren, und habe das auch noch von keinem gehört. Das Skripte nicht mit Leerzeichen in Dateinamen klargekommen sind und das durch ein paar Quotes einfach heilbar war, habe ich allerdings schon öfter gehört, und auch selbst erlebt.

Hat nur mit dem vorliegenden Script nichts zu tun.

Keine Sorge, ich werde nicht wieder den Terminus Cargo-Cult-Programmierung in die Debatte einbringen.

Ich habe nämlich einen neuen: Strohmannprogrammierung.

Ich setze „Defensive Programmierung“ dagegen.

Man benutzt ein Mittel mit dem man ein Problem lösen könnte, das man gar nicht hat. Stellvertretend für die Leute, die das Problem haben und es nicht lösen.

Doch ich löse damit ein Problem das ich habe: Ich möchte weder jetzt noch später darüber nachdenken müssen ob wirklich gequoted werden muss, weil der Nutzen es einfach zu tun für mich deutlich höher ist als die Kosten. Quoten ist billig, sowohl beim schreiben als auch beim ausführen. Fehler aufgrund fehlenden Quotens suchen und bei jeder Änderung immer wieder schauen was davon betroffen ist und dann neu gequoted werden muss, oder was dann nicht mehr gequoted werden muss, kostet wesentlich mehr Zeit.

Du bist aber nicht das Zielpublikum.

Das Zielpublikum ist jemand, der offenbar erst mal Schwierigkeiten mit dem Maskieren überhaupt hat. Da ist der Rat, immer so viel wie möglich zu quoten, eine unterkomplexe Faustregel, die ganz ungünstig zu Lernverweigerung ermuntert.