grep kaputt?

Du hast Probleme mit Deinem eMail-Programm, Webbrowser oder Textprogramm? Dein Lieblingsprogramm streikt?
tobo
Beiträge: 1991
Registriert: 10.12.2008 10:51:41

Re: grep kaputt?

Beitrag von tobo » 13.01.2023 22:28:07

Meillo hat geschrieben: ↑ zum Beitrag ↑
13.01.2023 22:23:13
Ich denke daher, wenn man sich

Code: Alles auswählen

grep -a apt ~/.bash_history | od -c
anschaut, dann wird man dort irgendwelche Bytes finden, die ``komisch'' sind.
Genau, und zwar in zeile 46!

michaa7
Beiträge: 4628
Registriert: 12.12.2004 00:46:49
Lizenz eigener Beiträge: MIT Lizenz

Re: grep kaputt?

Beitrag von michaa7 » 13.01.2023 22:57:11

Tja ... wir werden dies als Heisenbug oder spontane Betriebssysteselbstheilung einsortieren müssen.

Während ihr euch weiter den Kopf zerbrochen habt habe ich meine .bash_history

- in nano geöffnet
- in .bash_history-test umbenannt
- zeilenweise ein paar dinge rausgelöscht die in der Öffentlichkeit nicht unbedingt gepostet werden müssen
- dann abgespeichert.

Code: Alles auswählen

cat .bash_history-test | grep apt
Tat was es soll. Finden nun (wieder) Zeilen die das Wort "apt" beinhalten.

Dann die Überraschung:

Code: Alles auswählen

cat .bash_history | grep apt
tut nun auch was es soll, findet nun (wieder) Zeilen die das Wort "apt" beinhalten.
8O

Leute, ich habe das gestern mehrfach wiederholt, immer kam die Binärdatei Meldung. Nun ist alles ok ... weil die Datei in nano geöffnet und unter einem anderem Namen gespeichert wurde?

BTW, Zeile 40-50 der Ursprungsdatei:

Code: Alles auswählen

 40 xterm -fa 'Mono' -fs 18 -geometry +300+150 -e "lsblk --sort mountpoint -o m>
 41 lsblk --sort mountpoint -o mountpoint,label,name,FSAVAIL
 42 man egrep
 43 lsblk --sort mountpoint -o mountpoint,label,name,FSAVAIL| egrep -e "/" -e ">
 44 su -
 45 cd rezept/gem*
 46 cd rezept/gemüse
 47 cd rezept/gerüse
 48 cd rezept
 49 cd rezepte
 50 cd gem*
Edit:
Zeile 46 wäre (nach augenschein) die erste Zeile in der ein Umlaut vorkommt! Ob hier das öffnen mit nano einen Kodierfehler repariert hat? Dies konnte ich allerdings mit einem test (.bash_history weggesichert. In neu erzeute text mit umlaut geschireben. Fehler tritt nicht auf) nicht verivizieren.

Danke an alle Beteiligten für die HArtnäckigkeit. So habe ich den Fehler verstanden und behoben und mein Verständnis von cat ist wieder in der Spur! LEider werden wir der Ursache nun wohl nicht mehr auf die Spur kommen ....
gruß

michaa7

-------------------------------
Menschen ändern gelegentlich ihre Ansichten, aber nur selten ihre Motive. (Oskar Negt)

Benutzeravatar
Phineas
Beiträge: 348
Registriert: 20.06.2012 20:26:19

Re: grep kaputt?

Beitrag von Phineas » 13.01.2023 23:35:13

cat -v sollte dem Binarzeugs den Garaus machen.
Das ist aber nur ein Schuss ins Blaue.

michaa7
Beiträge: 4628
Registriert: 12.12.2004 00:46:49
Lizenz eigener Beiträge: MIT Lizenz

Re: grep kaputt?

Beitrag von michaa7 » 13.01.2023 23:42:14

Wenn ihr doch noch weiter untersuchen wollt :wink: ... die .bash_history des nutzers root zeigt das selbe Fehlverhalten:

Code: Alles auswählen

~# cat .bash_history | grep apt
grep: (Standardeingabe): Übereinstimmungen in Binärdatei

Code: Alles auswählen

cmp ~/.bash_history <(strings ~/.bash_history)
/root/.bash_history /dev/fd/63 sind verschieden: Byte 2304, Zeile 90
Wie kann ich mir Zeile 90 anzeigen lassen ohne die Datei in nano zu öffnen?

Code: Alles auswählen

# sed -n '90p' .bash_history
mc

# sed -n '85,95p' .bash_history
apt policy  linux-image-5.17.0-trunk-amd64 linux-headers-5.17.0-trunk-amd64
apt install  linux-image-5.17.0-trunk-amd64 linux-headers-5.17.0-trunk-amd64
apt autoclean
apt install  linux-image-5.17.0-trunk-amd64 linux-headers-5.17.0-trunk-amd64
sdrn
mc
apt update && apt dist-upgrade -d
apt dist-upgrade
apt update && apt dist-upgrade -d
apt policy connman-iptables 
apt update && apt dist-upgrade -d
Ein Ausschnitt aus "# grep -a apt ~/.bash_history | od -c" der wg. der Zahlen merkwürdig aussieht

Code: Alles auswählen

...
0103260   p   t       i   n   s   t   a   l   l       s   y   s   t   e
0103300   m   d  \n   a   p   t       i   n   s   t   a   l   l        
0103320   s   y   s   t   e   m   d   -   r   e   s   o   l   v   e   d
0103340  \n 302 273   a   p   t   -   g   e   t       u   p   d   a   t
0103360   e  \n 302 273   a   p   t       u   p   d   a   t   e  \n   a
0103400   p   t       i   n   s   t   a   l   l           s   y   s   t
0103420   e   m   d   -   r   e   s   o   l   v   e   d  \n   a   p   t
0103440       i   n   s   t   a   l   l           s   y   s   t   e   m
0103460   d   -   r   e   s   o   l   v   e   d  \n   a   p   t       p
...
gruß

michaa7

-------------------------------
Menschen ändern gelegentlich ihre Ansichten, aber nur selten ihre Motive. (Oskar Negt)

Benutzeravatar
Phineas
Beiträge: 348
Registriert: 20.06.2012 20:26:19

Re: grep kaputt?

Beitrag von Phineas » 14.01.2023 06:34:01

Code: Alles auswählen

~> printf 'a\000b\n' | grep a
Übereinstimmungen in Binärdatei (Standardeingabe)
~> printf 'a\000b\n' | cat -v | grep a
a^@b
~>
Also:

Code: Alles auswählen

cat -v .bash_history | grep apt

tobo
Beiträge: 1991
Registriert: 10.12.2008 10:51:41

Re: grep kaputt?

Beitrag von tobo » 14.01.2023 09:08:21

Leicht angepasst, funktioniert einwandfrei:

Code: Alles auswählen

$ printf 'a\000b\n' >f
$ cmp f <(strings -n1 f)
f /dev/fd/63 differ: byte 2, line 1
$

Benutzeravatar
Meillo
Moderator
Beiträge: 8813
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: grep kaputt?

Beitrag von Meillo » 14.01.2023 11:26:04

Wenn ihr genau lest, was ich gepostet habe: Dateien, die Null-Bytes enthalten, werden *immer* als binaer interpretiert. Das ist bei unserem Phaenomen aber nicht der Fall, also sollten wir auch nicht mit Null-Bytes testen. Stattdessen haben wir *manche* Zeilen, die invalide Bytes enthalten, und zwar sind die in ``apt''-Zeilen enthalten, nicht aber in ``policy''-Zeilen. Um nun zu schauen, um was fuer Bytes es sich handelt, filtern wir die ``apt''-Zeilen raus und untersuchen ihren Inhalt:

Code: Alles auswählen

grep -a apt ~/.bash_history | od -c
(Diesen Befehl habe ich oben auch schon mal geschrieben.)

Damit nicht alles michaa7 machen muss, kann er uns den Ausschnitt der (sicherlich inhaltlich unproblematischen) apt-Befehle bereitstellen:

Code: Alles auswählen

grep -a apt ~/.bash_history >apt-zeilen.txt
Und dann uns die Datei (ohne Editorbearbeitungen oder Inhaltkopieren, sondern die Datei an sich) im Pastbin hochladen.

Wir schauen uns dann die nicht-druckbaren Zeichen an. Falls es zu viel Inhalt fuer:

Code: Alles auswählen

<apt-zeilen.txt |od -c
ist, koennen wir den Inhalt auch erstmal vorfiltern:

Code: Alles auswählen

<apt-zeilen.txt tr -d '[:print:]' | od -c
Use ed once in a while!

michaa7
Beiträge: 4628
Registriert: 12.12.2004 00:46:49
Lizenz eigener Beiträge: MIT Lizenz

Re: grep kaputt?

Beitrag von michaa7 » 14.01.2023 13:16:13

Ok, werde ich machen, *aber* ...

... steckt der Fehler nicht hier
0103340 \n 302 273 a p t - g e t u p d a t
0103360 e \n 302 273 a p t u p d a t e \n a
?
gruß

michaa7

-------------------------------
Menschen ändern gelegentlich ihre Ansichten, aber nur selten ihre Motive. (Oskar Negt)

michaa7
Beiträge: 4628
Registriert: 12.12.2004 00:46:49
Lizenz eigener Beiträge: MIT Lizenz

Re: grep kaputt?

Beitrag von michaa7 » 14.01.2023 13:40:14

Meillo hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 11:26:04
... Stattdessen haben wir *manche* Zeilen, die invalide Bytes enthalten, und zwar sind die in ``apt''-Zeilen enthalten, nicht aber in ``policy''-Zeilen.
...
Alle "policy" Zeilen sind auch "apt" Zeilen (kommt von "apt policy foo")
Nicht alle "apt" Zeilen sind auch "policy" Zeilen (z.B. "apt install foo")
Dies nur zur Klärung

...
Meillo hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 11:26:04
Wir schauen uns dann die nicht-druckbaren Zeichen an. Falls es zu viel Inhalt fuer:

Code: Alles auswählen

<apt-zeilen.txt |od -c
ist, koennen wir den Inhalt auch erstmal vorfiltern:

Code: Alles auswählen

<apt-zeilen.txt tr -d '[:print:]' | od -c
Alles durchgeführt, Ergebnis wie oben:

Code: Alles auswählen

~# <apt-zeilen.txt tr -d '[:print:]' | od -c
0000000  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n
*
0001720  \0  \0  \0  \0  \0  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n
0001740  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n
0001760  \n 302 273  \n 302 273  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n
0002000  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n
*
0002240  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n
0002252
Ist 302 und 273 dezimal oder oktal?
Dezimal aus utf-16:

Code: Alles auswählen

đ	273	0000000100010001	111	421	&#273;
Į	302	0000000100101110	12e	456	&#302;
Oktal:

Code: Alles auswählen

»	187	BB	273	Right-pointing double angle quotation mark
Â	194	C2	302
Octal aus UTF-8:

Code: Alles auswählen

U+0080	 	0302 0200		 	<control>

********************************
U+00BB	»	0302 0273	&raquo;	»	&#187;	»	RIGHT-POINTING DOUBLE ANGLE
********************************
???
gruß

michaa7

-------------------------------
Menschen ändern gelegentlich ihre Ansichten, aber nur selten ihre Motive. (Oskar Negt)

Benutzeravatar
Meillo
Moderator
Beiträge: 8813
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: grep kaputt?

Beitrag von Meillo » 14.01.2023 14:08:22

Man koennte bei `tr' auch noch Newlines wegfiltern:

Code: Alles auswählen

tr -d '[:print:]\n'
Dann wird's nochmal etwas uebersichtlicher.


Danke fuer deine Analyse. Die Loesung scheint gefunden! :-)

(`od -c' gibt die Bytes oktal aus.)

Das war vielleicht ein Copy'n'Paste-Fehler mit dem Quote-Zeichen damals, der nun dafuer sorgt, dass die Ausgabe dieser Zeile als binaer gewertet wird.


Hier zum Testen:

Code: Alles auswählen

printf "foo\nbar\302\273\n" | grep foo   # sollte gehen

printf "foo\nbar\302\273\n" | grep bar   # sollte die binaermeldung ausgeben
(Ich habe kein aktuelles GNU grep, um es selber zu testen.)

Vermutlich kommt es auch noch auf das Locale an. @michaa7: Bitte poste noch die Ausgabe von `locale'.
Use ed once in a while!

michaa7
Beiträge: 4628
Registriert: 12.12.2004 00:46:49
Lizenz eigener Beiträge: MIT Lizenz

Re: grep kaputt?

Beitrag von michaa7 » 14.01.2023 14:24:36

Meillo hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 14:08:22
Man koennte bei `tr' auch noch Newlines wegfiltern:

Code: Alles auswählen

~# <apt-zeilen.txt tr -d '[:print:]\n' | od -c
0000000  \0  \0  \0  \0  \0 302 273 302 273
Meillo hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 14:08:22
...
(`od -c' gibt die Bytes oktal aus.)
Danke für den Hinweis.
Meillo hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 14:08:22
Das war vielleicht ein Copy'n'Paste-Fehler mit dem Quote-Zeichen damals, der nun dafuer sorgt, dass die Ausgabe dieser Zeile als binaer gewertet wird.
Das war es ziemlich sicher. Ich hatte Problem mit dem Netzwerk über systemd und habe u.a. gegoogelt. Dabei tauchte das Paket systemd-resolved in einem Beitrag auf und mir fiel sofort ein, dass ich vergessen hatte dieses Paket zu installieren :oops: . Gut möglich dass ich "systemd-resolved" aus der Website in meine Konsole kopiert habe und da irgendwie zuviel erwischt habe. Komisch ist allerdings, dass "»" in der Konsole dargestellt wird. Ich verstehe nicht wie es da zu einer Fehlinterpretation kommt.
Meillo hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 14:08:22
Hier zum Testen:

Code: Alles auswählen

printf "foo\nbar\302\273\n" | grep foo   # sollte gehen

printf "foo\nbar\302\273\n" | grep bar   # sollte die binaermeldung ausgeben
Nicht ganz so wie von dir gedacht:

Code: Alles auswählen

~$ printf "foo\nbar\302\273\n" | grep foo
foo

~$ printf "foo\nbar\302\273\n" | grep bar 
bar»
Meillo hat geschrieben: ↑ zum Beitrag ↑
14.01.2023 14:08:22
... @michaa7: Bitte poste noch die Ausgabe von `locale'.

Code: Alles auswählen

~$ locale
LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_ALL=
EDIT:
BTW, diese "302 273 302 273" oktal Sequenz ist im entsprechenden File in meinem User Profil welches durch öffnen in nano wohl repariert wurde (das file) nicht mehr vorhanden
gruß

michaa7

-------------------------------
Menschen ändern gelegentlich ihre Ansichten, aber nur selten ihre Motive. (Oskar Negt)

Antworten