Line-Feed-Manipulation durch Bash verhindern
Stefan Welscher
- webserver
Moinsen,
ich bin gerade dabei einen Server umzuziehen, musste jetzt aber feststellen, dass sich wohl in der neueren Distri die Bash in die Ausgabe der Character einmischt:
user@server:~> echo -e "test\r\ntest\r\ntest\r\ntest\r\ntest\r\n"
test[CR]
[CR][LF]
test[CR]
[CR][LF]
test[CR]
[CR][LF]
test[CR]
[CR][LF]
test[CR]
[CR][LF]
[CR][LF]
user@server:~>
Mir geht es darum, mit PHP Dateien unmanipuliert auf CLI-Ebene anzuzeigen, die u.U. mit Windows erstellt wurden und damit bereits mit \r\n versehen sind.
Die Bash scheint aber immer nochmal ein Replacement von \n durch \r\n durchzuführen.
Das zerstört letztendlich die Struktur der Dateien, die ich mir damit anzeigen lasse.
Natürlich könnte ich jetzt anfangen, wieder \r\n durch \n zu ersetzen, aber das ist ja nicht Sinn der Sache....
Wie kann ich also die Manipulation verhindern?
Gibt es einen Binmode oder ähnliches bei der Bash?
Oder kann ich eine Systemvariable oder Configdatei umbiegen?
Besten Dank,
Stefan
Moinsen,
Moin!
user@server:~> echo -e "test\r\ntest\r\ntest\r\ntest\r\ntest\r\n"
test[CR]
[CR][LF]
test[CR]
[CR][LF]
test[CR]
[CR][LF]
test[CR]
[CR][LF]
test[CR]
[CR][LF]
[CR][LF]
user@server:~>
Wie hast du denn die einzelnen Zeichen der Ausgabe bestimmt? Kann es nicht sein, dass dein Terminal sowohl \r als auch \n als Newline interpretiert? Auf was für einem Betriebssystem läuft denn eigentlich die Bash und in welcher Version? Ich habe GNU bash 4.2 unter Linux und bekomme immer nur eine neue Zeile.
Viele Grüße,
Robert
Wie hast du denn die einzelnen Zeichen der Ausgabe bestimmt? Kann es nicht sein, dass dein Terminal sowohl \r als auch \n als Newline interpretiert? Auf was für einem Betriebssystem läuft denn eigentlich die Bash und in welcher Version? Ich habe GNU bash 4.2 unter Linux und bekomme immer nur eine neue Zeile.
Viele Grüße,
Robert
Hi,
Bash-Version:
/bin/bash --version
GNU bash, version 3.2.51(1)-release (x86_64-suse-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
ppwd 3
dirs +0
Distribution ist SUSE Linux Enterprise Server 11 SP2 (x86_64)
Die Ausgabe wird normalerweise per SSH von einem Script einer anderen Maschine abgeholt.
Wenn ich die Ausgabe auf der Problemmaschine in eine Datei umleite und mir diese herunterlade ist noch alles OK, aber sobald ich SSH dazu verwende um den Remote-Befehl auszuführen habe ich die zusätzlichen Zeichen drin.
Über das Putty-Log kann ich das Verhalten dann ebenfalls reproduzieren.
Weder am Script, welches die Datei abholt, noch am Putty-Setup habe ich etwas verändert, also muss es etwas mit dem neuen Server zu tun haben. Und da die Umleitung in eine Datei noch funktioniert kann es denke ich nur noch die Bash sein, die das Problem verursacht.
Hallo,
Die Ausgabe wird normalerweise per SSH von einem Script einer anderen Maschine abgeholt.
Wenn ich die Ausgabe auf der Problemmaschine in eine Datei umleite und mir diese herunterlade ist noch alles OK, aber sobald ich SSH dazu verwende um den Remote-Befehl auszuführen habe ich die zusätzlichen Zeichen drin.
das lässt mich vermuten, dass nicht die bash der Übeltäter ist, sondern entweder der SSH-Server auf der einen Maschine oder der entsprechende Client auf der anderen eine Konvertierung von \n in \r\n vornimmt.
Über das Putty-Log kann ich das Verhalten dann ebenfalls reproduzieren.
Aha, Putty. Also Windows? Du arbeitest also *von* einem Windows-Host aus auf deinem SUSE-Server? Dann kann ich mir erst recht vorstellen, dass Putty auf Windows genau diese Umwandlung vornimmt.
Weder am Script, welches die Datei abholt, noch am Putty-Setup habe ich etwas verändert, also muss es etwas mit dem neuen Server zu tun haben. Und da die Umleitung in eine Datei noch funktioniert kann es denke ich nur noch die Bash sein, die das Problem verursacht.
Nein. Dann wären die "verkorksten" Steuerzeichen ja in der Datei auch drin, denn bash macht keinen Unterschied zwischen der Ausgabe zum Terminal oder in eine Datei. Also vielleicht eher der sshd auf der SUSE-Büchse.
So long,
Martin
Moin!
Über das Putty-Log kann ich das Verhalten dann ebenfalls reproduzieren.
Aha, Putty. Also Windows? Du arbeitest also *von* einem Windows-Host aus auf deinem SUSE-Server? Dann kann ich mir erst recht vorstellen, dass Putty auf Windows genau diese Umwandlung vornimmt.
Putty hat genau so eine Konvertierungseinstellung, die vor alle LF noch ein CR einfügt.
Unter "Terminal" als Checkbox "Implicit CR in every LF".
Das ist zwar standardmäßig abgeschaltet, aber man weiß ja nie, warum Dinge so sind, wie sie sind.
Das schließt die Bash an sich zwar auch noch nicht aus, aber der allernächste Kandidat serverseitig wäre dann tatsächlich der sshd dort, und dessen Konfiguration.
- Sven Rautenberg
Über das Putty-Log kann ich das Verhalten dann ebenfalls reproduzieren.
Aha, Putty. Also Windows? Du arbeitest also *von* einem Windows-Host aus auf deinem SUSE-Server? Dann kann ich mir erst recht vorstellen, dass Putty auf Windows genau diese Umwandlung vornimmt.
Putty hat genau so eine Konvertierungseinstellung, die vor alle LF noch ein CR einfügt.
Unter "Terminal" als Checkbox "Implicit CR in every LF".
Das ist zwar standardmäßig abgeschaltet, aber man weiß ja nie, warum Dinge so sind, wie sie sind.
Das schließt die Bash an sich zwar auch noch nicht aus, aber der allernächste Kandidat serverseitig wäre dann tatsächlich der sshd dort, und dessen Konfiguration.
- Sven Rautenberg
Also unter Putty ist in der Richtung nichts gesetzt.
Ich hab mir auch mal die neurere Version geholt (0.60 ursprünglich, jetzt 0.63), das Verhalten ändert sich da auch nicht.
SSH hätte ich jetzt am wenigsten zugetraut nochmal die Ausgabe zu verfälschen, aber wenn die Bash tatsächlich keinen Unterschied zwischen Dateiausgabe und Terminal-Ausgabe macht wäre das denke ich auch realistisch. Nur komme ich an der Stelle jetzt am besten weiter? Zu der Maschine ist leider nur SSH freigegeben. Ich bin leider auch kein Admin auf dem Server und kann mir nicht mal die sshd_config ansehen.,
Hallo,
Unter "Terminal" als Checkbox "Implicit CR in every LF".
Das ist zwar standardmäßig abgeschaltet, aber man weiß ja nie, warum Dinge so sind, wie sie sind.
- Sven Rautenberg
Also unter Putty ist in der Richtung nichts gesetzt.
Sicher?

Ich hab mir auch mal die neurere Version geholt (0.60 ursprünglich, jetzt 0.63), das Verhalten ändert sich da auch nicht.
Diese neue Version kann auch den Haken an der falschen Stelle haben...
SSH hätte ich jetzt am wenigsten zugetraut nochmal die Ausgabe zu verfälschen,
IMO einer der naheliegensten
bis dann
Ulli
Also unter Putty ist in der Richtung nichts gesetzt.
Sicher?

Jup, sicher.
@Topic: Nachdem ich nicht auf den alten Server zurück möchte da der ohnehin in einer Woche abgeschalten wird, bin ich jetzt den Weg des geringsten Widerstandes gegangen und habe die API so umgeschrieben, dass die Scriptausgabe auf der Remotemaschine zunächst in eine Datei geschrieben wird und diese dann über SCP abgeholt wird. Ist durch den zweiten Session-Aufbau zwar etwas langsamer, aber was will man machen... solange ich nicht weiß woher der Fehler genau kommt und was u.U. noch alles verändert wird.
Aber trotzdem Danke für die Hilfe!