Buster, arbeitet grep anders?

[ingo2]

Ich hatte ja vor einiger Zeit meine Temperaturaufzeichning mit einem RTL-SDR-Stick ausführlich beschrieben: viewtopic.php?f=15&t=174293.
Das lief brav auf meinem Serverlein (pcengines APU.2) und lieferte schöne Plots. Seit Upgrade auf Buster liefert die Ausgabe nur einen leeren String .

Bin der Sache jetzt auf den Grund gegangen und habe folgendes mit Tests im Terminal gefunden:
Der Befehl

Code: Alles auswählen

rtl_433 -R 02 -E 1 -T 130 2>/dev/null | grep "Temperature:"

liefert unter Stretch:

Code: Alles auswählen

Channel   : 1            Battery   : OK            Temperature: 2.8 C        Integrity : CRC

aber unter Buster nur:

Code: Alles auswählen

Temperature: 3.0 C

Ich muß also jetzt den Temperaturwert mit awk '{print $2}' statt vorher awk '{print $8}' ausfiltern. Damit läuft alles wieder perfekt.

Der volle Output ohne grep im Terminal ist in beiden Fällen aber gleich:

Code: Alles auswählen

time      : 2019-12-05 17:28:12
model     : Rubicson Temperature Sensor            House Code: 161
Channel   : 1            Battery   : OK            Temperature: 2.9 C        Integrity : CRC

Hat da Jemand eine Erklärung?

Gruß, Ingo

[hikaru]

Der volle Output ohne grep im Terminal ist in beiden Fällen aber gleich:

Code: Alles auswählen

time      : 2019-12-05 17:28:12
model     : Rubicson Temperature Sensor            House Code: 161
Channel   : 1            Battery   : OK            Temperature: 2.9 C        Integrity : CRC

Wenn ich diesen Code-Block in eine Datei stecke und darauf grep loslasse, dann bekomme ich unter Stretch und Buster das selbe Ergebnis, nämlich das was du auch unter Stretch hattest.
Am grep-Verhalten hat sich also offenbar nichts geändert. Alles Andere würde mich auch wundern.

Aber hat sich vielleicht der Output des Eingangskommandos geändert, so dass Feldtrenner nun nicht mehr Whitespaces sind, sondern irgendwas, das grep als Linebreaks sieht, aber in der Terminalausgabe nicht als neue Zeile erscheint (z.B. CR ohne LF?)?

Zur Veranschaulichung ("\n"):

Code: Alles auswählen

time      : 2019-12-05 17:28:12
model     : Rubicson Temperature Sensor            House Code: 161
Channel   : 1            \nBattery   : OK            \nTemperature: 2.9 C        \nIntegrity : CRC

Das würde jedenfalls das "neue" grep-Verhalten erklären.

[Meillo]

Das waere auch viel sinnvoller. Der derzeitige Output scheint mir eher ein Bug zu sein. Warum sonst werden manche Werte auf einer Zeile zusammengefasst und andere nicht? Und wenn sie schon zusammengefasst werden, warum werden die Doppelpunkte dann in Festbreiten-Abstaenden gesetzt?

Btw: Ihr solltet beim Testen des Outputs durch cat(1) pipen, da sich manche Programme unterschiedlich verhalten, ob die Ausgabe ins Terminal oder in eine Pipeline gehen.

[hikaru]

Btw: Ihr solltet beim Testen des Outputs durch cat(1) pipen, da sich manche Programme unterschiedlich verhalten, ob die Ausgabe ins Terminal oder in eine Pipeline gehen.

Das hebt "useless use of cat" auf ein ganz neues Level!

[ingo2]

Sorry, auf den Test hätte ich vorher auch schon kommen können, aber das Binary rtl_433, welches den Output erzeugt, habe ich unter Stretch kompiliert und dann einfach nach Buster kopiert - die sind auch binär identisch.

Dennoch ist der Output ganz anders, wenn ich den in eine Datei umleite mit z.b.

Code: Alles auswählen

rtl_433 -R 02 -E 1 -T 130 2>/dev/null > buster-output    (bzw. > stretch-output)

Das sieht jetzt so aus, sogar die Dateigrößenm sind unterschiedlich:

buster-output: 194Byte

Code: Alles auswählen

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

time      : 2019-12-05 21:53:15
model     : Rubicson Temperature Sensor
House Code: 161
Channel   : 1
Battery   : OK
Temperature: 2.1 C
Integrity : CRC

stretch-output: 513Byte

Code: Alles auswählen

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2019-12-05 20:18:15
model     : Rubicson Temperature Sensor            House Code: 161
Channel   : 1            Battery   : OK            Temperature: 2.4 C        Integrity : CRC

Fazit: nicht grep ist der Schuldige - wer das jedoch ist, ist mir ein Rätsel.

Da nachzuforschen lohnt wohl nicht. rtl-sdr hat wohl einen größeren Versionssprung von Stretch nach Buster gemacht.

EDIT:
Im x-term (via ssh auf meinem Serverlein) sieht der Output jedoch in beiden Fällen identisch aus wie oben schon gepostet.

Also "sorry" für die falsche Verdächtigung von grep,
Ingo

[hikaru]

Da nachzuforschen lohnt wohl nicht.

Praktisch vielleicht nicht, akademisch fände ich es allerdings schon interessant, warum das selbe Binary unter Stretch und Buster unterschiedliche Ausgaben erzeugt - insbesondere angesichts dieser Aussage:

Im x-term (via ssh auf meinem Serverlein) sieht der Output jedoch in beiden Fällen identisch aus wie oben schon gepostet.

Die Ausgabe schein also in Bezug auf das verwendete Terminal (die Shell?) kontextsensitiv zu sein.
Im Interesse der Reproduzierbarkeit fände ich es erstrebenswert, diesen Kontext zu ergründen. Wir sind ja hier schließlich im Debianforum und nicht beim Support-Chat eines berühmten Spielestarters.

[Meillo]

Im x-term (via ssh auf meinem Serverlein) sieht der Output jedoch in beiden Fällen identisch aus wie oben schon gepostet.

Die Ausgabe schein also in Bezug auf das verwendete Terminal (die Shell?) kontextsensitiv zu sein.
Im Interesse der Reproduzierbarkeit fände ich es erstrebenswert, diesen Kontext zu ergründen. Wir sind ja hier schließlich im Debianforum [...]

[pferdefreund]

Na ja, Programme sind zwar mit Sicherheit binär identisch, die verwendeten Bibliotheken aber sicherlich nicht nach einem Upgrade - und das mit dem Terminal kenne ich. Bei manchen funktionieren die PF-Tasten bei verschiedenen Anwendungen nicht, in anderen aber doch - so verwende ich für Gnu-Cobol-Programme rxvt, weil die hier fruchten.

[ingo2]

Die Ausgabe schein also in Bezug auf das verwendete Terminal (die Shell?) kontextsensitiv zu sein.
Im Interesse der Reproduzierbarkeit fände ich es erstrebenswert, diesen Kontext zu ergründen. Wir sind ja hier schließlich im Debianforum und nicht beim Support-Chat eines berühmten Spielestarters.

Da brauche ich aber eure Hilfe - ich liefere gerne alle dazu nötigen Informationen. Fange mal hier an:

1. Habe die beiden Outputs in einen Hex-Editor geladen und mir angeschaut:
Die erste Zeile hat jeweils eine unterschiedlich Menge von "5F 20" (20x bei Buster, 48x bei Stretch. Die 1. Zeile endet mit 2x "0A" bei Buster und 1x"0A" bei Stretch am Zeilenende.
Alle weiteren Zeilenumbrüche sind ein einfaches "0A" - also Linux-conform. Die Darstellung in meinem Post weiter oben ist also soweit korrekt.
Die Zeilenzahl, welche wc ermittelt, ist also auch korrekt, die enorme Zahl an Wörtern ist den vielen Leerzeichen in der 1. Zeile geschuldet:

Code: Alles auswählen

$ wc stretch-output 
  4 184 513 stretch-output
  
$ wc buster-output 
  9  44 194 buster-output

2. Die Ausgabe im Terminal ist (offenbar mittels ncurses) aufgehübscht mit farbigen Text, so wie man hier sieht: https://github.com/merbanan/rtl_433.
Wenn ich die Ausgabe mit tee gleichzeitig anschaue, ist die Ausgabedatei wie gehabt, die Anzeige im x-term jedoch rein s/w.

3. Beim Kompilieren von rtl_433 habe ich noch folgende *.dev-Pakete gebraucht:
libusb-1.0.0-dev, librtlsdr-dev, libltdl-dev.

4. Beim kopieren der rtl_433-Installation habe ich folgende Dateien (sind alle aus dem Compile-Prozess) übertragen:

Code: Alles auswählen

Install the project...
	-- Install configuration: "Release"
	-- Installing: /usr/local/include/rtl_433.h
	-- Installing: /usr/local/include/rtl_433_devices.h
	-- Installing: /usr/local/bin/rtl_433
	-- Installing: /usr/local/etc/rtl_433/EV1527-4Button-Universal-Remote.conf
	-- Installing: /usr/local/etc/rtl_433/EV1527-PIR-Sgooway.conf
	-- Installing: /usr/local/etc/rtl_433/chungear_bcf-0019x2.conf
	-- Installing: /usr/local/etc/rtl_433/energy_count_3000.conf
	-- Installing: /usr/local/etc/rtl_433/pir-ef4.conf
	-- Installing: /usr/local/etc/rtl_433/rtl_433.example.conf
	-- Installing: /usr/local/etc/rtl_433/silverline_doorbell.conf
	-- Installing: /usr/local/etc/rtl_433/steffen_switch.conf
	-- Installing: /usr/local/etc/rtl_433/valeo_car_key.conf

und die wurden auch nicht beim Upgrade Stretch -> Buster angefaßt!

So, mehr fällt mir jetzt nicht ein, bitte sagt was noch fehlt,
Ingo