grep kaputt?

Du hast Probleme mit Deinem eMail-Programm, Webbrowser oder Textprogramm? Dein Lieblingsprogramm streikt?
michaa7
Beiträge: 4611
Registriert: 12.12.2004 00:46:49
Lizenz eigener Beiträge: MIT Lizenz

grep kaputt?

Beitrag von michaa7 » 12.01.2023 18:20:48

Seit Jahren suche ich mit Mustern in der Art:

Code: Alles auswählen

# cat .bash_history | grep "apt"
Nun erhalte ich:

Code: Alles auswählen

# cat .bash_history | grep "apt"
grep: (Standardeingabe): Übereinstimmungen in Binärdatei
Stehe ich gerade auf dem Schlauch oder ist grep kaputt?

BTW: Debian/ sid(uction)
gruß

michaa7

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

DeletedUserReAsG

Re: grep kaputt?

Beitrag von DeletedUserReAsG » 12.01.2023 18:27:23

michaa7 hat geschrieben: ↑ zum Beitrag ↑
12.01.2023 18:20:48
Stehe ich gerade auf dem Schlauch oder ist grep kaputt?
Wenn gewisse (Steuer-)Zeichen in einer Datei auftauchen, wird sie als Binärdatei angenommen. Die Manpage ist diesbezüglich eigentlich recht ergiebig.

OT: useless use of cat, btw.

Benutzeravatar
debilian
Beiträge: 1162
Registriert: 21.05.2004 14:03:04
Wohnort: 192.168.43.7
Kontaktdaten:

Re: grep kaputt?

Beitrag von debilian » 12.01.2023 18:33:42

dann wäre

Code: Alles auswählen

grep apt .bash_history
richtig?
-- nichts bewegt Sie wie ein GNU --

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

Re: grep kaputt?

Beitrag von michaa7 » 12.01.2023 18:46:26

Danke, das ist natürlich viel einfacher! Werde ich zukünfigt so machen.

Aber dennoch, auch wenn kompliziert, bislang ging das so wie oben beschrieben... jetzt nicht mehr. Das stört einfach mein Verständnis einer pipe ... ich würde gerne verstehen was (nun) falsch ist. Für mich schaut das so aus als verstünde grep "apt" nicht mehr als zu suchendes Wort.
Zuletzt geändert von michaa7 am 12.01.2023 18:50:40, insgesamt 1-mal geändert.
gruß

michaa7

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

DeletedUserReAsG

Re: grep kaputt?

Beitrag von DeletedUserReAsG » 12.01.2023 18:47:28

michaa7 hat geschrieben: ↑ zum Beitrag ↑
12.01.2023 18:46:26
ich würde gerne verstehen was (nun) falsch ist.
niemand hat geschrieben: ↑ zum Beitrag ↑
12.01.2023 18:27:23
Wenn gewisse (Steuer-)Zeichen in einer Datei auftauchen, wird sie als Binärdatei angenommen.

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

Re: grep kaputt?

Beitrag von michaa7 » 12.01.2023 18:59:12

niemand hat geschrieben: ↑ zum Beitrag ↑
12.01.2023 18:27:23
Wenn gewisse (Steuer-)Zeichen in einer Datei auftauchen, wird sie als Binärdatei angenommen.
Ok, verstanden ... "cat .bash_history | grep policy" funktioniert wie gehabt.

Könnte man grep dazu bewegen "apt" als Suchwort zu betrachten? (mal ganz unabhängig davon das meine methode unnötig kompliziert ist)
gruß

michaa7

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

DeletedUserReAsG

Re: grep kaputt?

Beitrag von DeletedUserReAsG » 12.01.2023 19:05:12

michaa7 hat geschrieben: ↑ zum Beitrag ↑
12.01.2023 18:59:12
"cat .bash_history | grep policy" funktioniert wie gehabt.
Das ist dann in der Tat seltsam: der Suchbegriff sollte auf die Einordnung der Eingangsdaten keinen Einfluss haben.

Mein Versuch zum Testen wäre grep -a 'apt' .bash_history

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

Re: grep kaputt?

Beitrag von Meillo » 12.01.2023 19:45:21

niemand hat geschrieben: ↑ zum Beitrag ↑
12.01.2023 19:05:12
michaa7 hat geschrieben: ↑ zum Beitrag ↑
12.01.2023 18:59:12
"cat .bash_history | grep policy" funktioniert wie gehabt.
Das ist dann in der Tat seltsam: der Suchbegriff sollte auf die Einordnung der Eingangsdaten keinen Einfluss haben.
Da stimme ich dir zu. Vielleicht hat sich zwischen den zwei Befehlen die .bash_history veraendert, weil es eine neue Shell mit neuer History ist oder weil die History kurz ist und manche Befehle rausgewandert sind.

niemand hat geschrieben: ↑ zum Beitrag ↑
12.01.2023 19:05:12
Mein Versuch zum Testen wäre grep -a 'apt' .bash_history
So solltest du es machen.


Im Uebrigen ist es kein Fehler `cat' zu verwenden. Ich finde die Useless-use-of-cat-Anmerkungen viel nerviger als ich die Verwendung von cat schlecht finde, da die Verwendung von cat das Verstaendnis des wertvollen Pipes-and-Filters-Konzepts demonstriert, wohingegen der Zeitperformancenachteil heutzutage (in so gut wie allen angemeckerten Faellen) irrelevant ist. Hier habe ich meine Meinung dazu ausfuehrlicher dargelegt: https://www.ulm.ccc.de/ccc/chaosseminar ... rformance/
Use ed once in a while!

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

Re: grep kaputt?

Beitrag von michaa7 » 13.01.2023 00:04:52

Meillo hat geschrieben: ↑ zum Beitrag ↑
12.01.2023 19:45:21
...
Im Uebrigen ist es kein Fehler `cat' zu verwenden.
...
ok, aber es funktioniert nicht konsistent wie meine Beispiele darlegen. "policy" wird als Wort betrachtet, "apt" nicht als (Such-) wort (sondern als Binärdatei).
gruß

michaa7

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

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

Re: grep kaputt?

Beitrag von Meillo » 13.01.2023 05:52:02

michaa7 hat geschrieben: ↑ zum Beitrag ↑
13.01.2023 00:04:52
Meillo hat geschrieben: ↑ zum Beitrag ↑
12.01.2023 19:45:21
...
Im Uebrigen ist es kein Fehler `cat' zu verwenden.
...
ok, aber es funktioniert nicht konsistent wie meine Beispiele darlegen. "policy" wird als Wort betrachtet, "apt" nicht als (Such-) wort (sondern als Binärdatei).
Dieses Phaenomen hat mit Sicherheit nichts mit der Verwendung von `cat' zu tun.

Code: Alles auswählen

:-Q printf 'a\000b\n' | grep a                
Binary file (standard input) matches

:-Q printf 'a\000b\n' >/tmp/a ; grep a /tmp/a
Binary file /tmp/a matches
Du kannst mich vom Gegenteil ueberzeugen, wenn du zweimal hintereinander nach dem gleichen Wort greppst, einmal mit und einmal ohne `cat', und dabei verschiedenes Verhalten erscheint. (Kopiere dazu die .bash_history, damit sie sich durch die Shellverwendung nicht zwischendurch veraendert.)
Use ed once in a while!

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

Re: grep kaputt?

Beitrag von michaa7 » 13.01.2023 12:07:22

Meillo hat geschrieben: ↑ zum Beitrag ↑
13.01.2023 05:52:02
...
Dieses Phaenomen hat mit Sicherheit nichts mit der Verwendung von `cat' zu tun.
...
Das habe ich auch nicht behauptet und es ist nicht meine Meinung.

Ich wollte dir nur entgegnen dass dem Gebrauch von cat so wie ich es mir laienhaft zusammengebastelt habe eben ein inkonsistentes Verhalten von grep entgegensteht.
gruß

michaa7

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

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

Re: grep kaputt?

Beitrag von Meillo » 13.01.2023 12:22:31

Die Frage ist, was du willst:

1) Eine Loesung fuer dein Problem? Dann nutze `grep -a' und die Sache ist erledigt.

2) Verstehen, *warum* es sich so verhaelt, wie es sich verhaelt? Dann musst du das Phaenomen mit einer moeglichst kleinen Inputdatei reproduzierbar machen.
Use ed once in a while!

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

Re: grep kaputt?

Beitrag von michaa7 » 13.01.2023 12:42:22

Meillo hat geschrieben: ↑ zum Beitrag ↑
13.01.2023 12:22:31
...
1) Eine Loesung fuer dein Problem? Dann nutze `grep -a' und die Sache ist erledigt.
...
Ok, danke. Das war ja schon oben erwähnt, aber jetzt habe ich geschnallt wie es gemeint war.
( Das mit dem Verstehen schiebe ich mal ans Ende der gaaaanz langen todo Liste ;-) )

Erledigt.
gruß

michaa7

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

Benutzeravatar
detix
Beiträge: 1699
Registriert: 07.02.2007 18:51:28
Wohnort: MK

Re: grep kaputt?

Beitrag von detix » 13.01.2023 17:15:02

Meillo hat geschrieben: Vielleicht hat sich zwischen den zwei Befehlen die .bash_history veraendert, weil es eine neue Shell mit neuer History ist oder weil die History kurz ist und manche Befehle rausgewandert sind.
Seh ich genauso, der aktuelle Befehl zum Lesen aus der .bash_history wird auch zeitgleich in die .bash_history geschrieben, kann funktionieren muss aber nicht...
Gruß an alle Debianer, und immer daran denken:
Macht ohne Haftung funktioniert nicht!

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

Re: grep kaputt?

Beitrag von michaa7 » 13.01.2023 17:53:41

detix hat geschrieben: ↑ zum Beitrag ↑
13.01.2023 17:15:02
...
Seh ich genauso, der aktuelle Befehl zum Lesen aus der .bash_history wird auch zeitgleich in die .bash_history geschrieben,...
Nein, wird er nicht. Der wird erst mit dem Schließen des Terminals geschrieben. Selbst ein "sync" schreibt den nicht.
gruß

michaa7

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

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

Re: grep kaputt?

Beitrag von Meillo » 13.01.2023 18:02:02

Ich wiederhole mich:
Meillo hat geschrieben: ↑ zum Beitrag ↑
13.01.2023 12:22:31
2) Verstehen, *warum* es sich so verhaelt, wie es sich verhaelt? Dann musst du das Phaenomen mit einer moeglichst kleinen Inputdatei reproduzierbar machen.
D.h. alle Einflussfaktoren so weit wie moeglich reduzieren, u.a. dadurch, dass du nicht auf der Datei ~/.bash_history arbeitest, die von anderen Programmen in irgendwelcher Weise veraendert werden kann, sondern auf einer Kopie davon ... deren Inhalt du dann immer weiter kuerzt, bis der Phaenomen verschwindet, dann weisst du welcher Teil der Datei das Phaenomen erzeugt, Diesen isolierst du, bis am Ende eine Datei mir nur noch einer oder ein paar Zeilen uebrig bleibt, die das Phaenomen erzeugt. Dann postest du diese Datei und die Befehle, damit wir das Phaenomen reproduzieren koennen. Auf diesem Weg finden wir den Grund und die Erklaerung fuer das Phaenomen.

Weiter darueber zu reden, ohne diesen Weg zu nehmen, ist Zeitverschwendung.
Use ed once in a while!

chrbr
Beiträge: 547
Registriert: 29.10.2022 15:53:26

Re: grep kaputt?

Beitrag von chrbr » 13.01.2023 18:40:32

Hallo Michaa7,
am einfachsten ist es so:
  • Die Datei mit split in viele kleine Abschnitte aufzuteilen und alle mit find und cat + grep zu behandlen. Bei mindestens einem der neuen Bruchstücke sollte dann der Fehler auftreten.
  • Die cat Ausgabe der Date durch head und tail zu pipen und somit den Bereich einzugrenzen.
Das Bearbeiten einzelner Bereiche mit einem Editor kann nicht zielführend sein, wenn der Editor so programmiert ist, daß er solche Fehler selbstständig korrigiert.

Benutzeravatar
detix
Beiträge: 1699
Registriert: 07.02.2007 18:51:28
Wohnort: MK

Re: grep kaputt?

Beitrag von detix » 13.01.2023 19:07:09

michaa7 hat geschrieben: ↑ zum Beitrag ↑
13.01.2023 17:53:41
detix hat geschrieben: ↑ zum Beitrag ↑
13.01.2023 17:15:02
...
Seh ich genauso, der aktuelle Befehl zum Lesen aus der .bash_history wird auch zeitgleich in die .bash_history geschrieben,...
Nein, wird er nicht. Der wird erst mit dem Schließen des Terminals geschrieben. Selbst ein "sync" schreibt den nicht.
Ok, könnte auch an meinem Eintrag in der .bashrc liegen:

Code: Alles auswählen

# historyfile sofort schreiben, um die zuletzt eingegebenen Befehle zwischen mehreren Konsolen zu teilen
PROMPT_COMMAND="history -a; history -c; history -r"
Ich nehm alles zurück...
Gruß an alle Debianer, und immer daran denken:
Macht ohne Haftung funktioniert nicht!

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

Re: grep kaputt?

Beitrag von tobo » 13.01.2023 19:12:46

chrbr hat geschrieben: ↑ zum Beitrag ↑
13.01.2023 18:40:32
am einfachsten ist es so:
  • Die Datei mit split in viele kleine Abschnitte aufzuteilen und alle mit find und cat + grep zu behandlen. Bei mindestens einem der neuen Bruchstücke sollte dann der Fehler auftreten.
Will man die Anzahl der Versuche niedrig halten, dann würde man wohl eher immer die Datenmenge halbieren.

@michaa7:
Kommt hier was Sinnvolles raus?

Code: Alles auswählen

cmp ~/bash_history <(strings ~/.bash_history)

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

Re: grep kaputt?

Beitrag von michaa7 » 13.01.2023 20:04:43

Ich habe einen "." ergänzt den du vermtl. vergessen hast.

Code: Alles auswählen

$ cmp ~/.bash_history <(strings ~/.bash_history)
/home/mh/.bash_history /dev/fd/63 sind verschieden: Byte 2392, Zeile 46
Zu all den Ratschlägen was ich testen soll, mir ist einfach nicht klar zu was das dienen soll. Möglicherweise reden wir auch aneinander vorbei. Wie ich meine grep -Suche auf andere Weise als von mir normalerweise durchgeführt zum Erfolg führen kann habt ihr mir ja gezeigt. Danke dafür.

Mein Gedankenproblem besteht in folgendem (um das nochmals auf den Punkt zu bringen):

"cat .bash_history | grep policy" findet alle Zeilen in denen in der Datei .bash_history das Wort "policy" vorkommt, also etwa die Zeile "apt policy xfe".

"cat .bash_history | grep apt" findet ***nicht*** alle Zeilen in denen in der Datei .bash_history das Wort "apt" vorkommt, es findet *keine* derartige Zeile, es finded nicht "apt policy xfe", es sucht vermutlich nicht einmal nach irgendetwas sondern gibt diesen Hinweis auf eine Binardatei aus. So verstehe ich eure Hinweise und so geschieht es ja auch.
Grep sucht nicht nach "apt" weil es "apt" nicht als Suchmuster interpretiert (wie es das jedoch bei "policy" macht), sondern als Binärdatei (was in diesem Zusammenhang den Suchenden einen XXXX interessiert).

*Das* ist das Verhalten, welches ich nicht als kohärent ansehe.

Dass ich das Verhalten von grep mit dem "-a" Schalter entsprechend ändern kann habe ich verstanden. Dennoch ist meine Meinung auch dazu dass dies die Inkohärenz nur bestätigt.
Kohärent wäre es das Defaultverhalten und den Einsatz des Schalters umzukehren ...

Zu welchen zusätzlichen Erkenntnissen eure Testvorschläge führen sollen ist mir unklar. Und nur als Hinweis, die Worte "apt" und "policy" kommen beide ***dutzentfach*** in der .bash_history vor, so das es für meine Fragestellung unerheblich ist, ob da vielleicht die letzte Zeile aus irgendeinem Grund unterschiedlich ist.
gruß

michaa7

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

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

Re: grep kaputt?

Beitrag von tobo » 13.01.2023 20:18:14

michaa7 hat geschrieben: ↑ zum Beitrag ↑
13.01.2023 20:04:43
Zu welchen zusätzlichen Erkenntnissen eure Testvorschläge führen sollen ist mir unklar.
Man könnte Schlussfolgern:
1. Wie man die Text-Datei grundsätzlich von Binärdaten befreien könnte und
2. In welcher Zeile der erste Fund von Binärdaten ist

JTH
Moderator
Beiträge: 3014
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: grep kaputt?

Beitrag von JTH » 13.01.2023 20:26:02

Ich hab das Thema gerade nicht bis ins Detail verfolgt. Aber um weitere Verwirrung auszuschließen mal so deutlich geschrieben:

Das hier
michaa7 hat geschrieben: ↑ zum Beitrag ↑
13.01.2023 20:04:43
Grep sucht nicht nach "apt" weil es "apt" nicht als Suchmuster interpretiert (wie es das jedoch bei "policy" macht), sondern als Binärdatei (was in diesem Zusammenhang den Suchenden einen XXXX interessiert).
ist falsch und Unsinn.

In beiden Fällen

Code: Alles auswählen

cat .bash_history | grep policy
cat .bash_history | grep apt
ist das erste (und einzige) Argument für grep – „policy“ bzw. „apt“ – das Suchmuster, das ausschließlich als Zeichenkette interpretiert wird. Völlig Wurst, ob das zufällig der Name eines Programms in /bin oder so ist.

Wenn sich grep über

Code: Alles auswählen

grep: (Standardeingabe): Übereinstimmungen in Binärdatei
beschwert oder diese bemerkt, dann bezieht sich das immer auf die durchsuchte Datei/die durchsuchten Daten. Also liefert hier das

Code: Alles auswählen

cat .bash_history
keine reinen Textdaten, weswegen grep vermutet, dass man eine Binärdatei durchsuchen möchte. Und dazu muss man grep je nach dem mit dem Schalter -a ausdrücklich überreden.

Warum sich die Suche bei dir nun für diese vermeintlich ähnlichen Suchen unterscheidet, das wollen dir die verschiedenen Antwortenden suchen helfen.
Manchmal bekannt als Just (another) Terminal Hacker.

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

Re: grep kaputt?

Beitrag von Meillo » 13.01.2023 21:12:24

Dem Phaenomen kommen wir nur auf die Spur, wenn wir die Datei analysieren koennen. michaa7 scheint nicht gewillt zu sein, das zu tun. Wir koennten es auch selber tun, aber nur wenn er uns die Datei zur Verfuegung stellt, was jedoch problematisch ist, da eine Shell-History oft sensible Daten enthaelt.

Vielleicht hat jemand einen Vorschlag, wie man eine Kopie der Datei erzeugen kann, in der alle druckbaren Zeichen durch `x' ersetzt sind, ausser den Worten `apt' und `policy'. Dann koennte michaa7 eine so anonymisierte Kopie erstellen und uns bereitstellen, falls das Phaenomen bei ihr auch weiterhin vorhanden ist.

Andernfalls ziehe ich mich hier zurueck, weil ich es zunehmend frustrierend finde, dass es nur nutzloses Rumgerate ist und niemand was tun kann, um das Phaenomen zu ergruenden -- so kann man nichts lernen. :roll:
Use ed once in a while!

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

Re: grep kaputt?

Beitrag von michaa7 » 13.01.2023 22:22:42

JTH hat geschrieben: ↑ zum Beitrag ↑
13.01.2023 20:26:02
...
Warum sich die Suche bei dir nun für diese vermeintlich ähnlichen Suchen unterscheidet, das wollen dir die verschiedenen Antwortenden suchen helfen.
Ok, danke! Jetzt habe ich das erste mal verstanden, dass das von mir beschriebene Verhalten *nicht* das ist was zu erwarten ist sondern auch eurer Meinung nach irgendwie irritierend (woran immer das liegen mag).
Jetzt erscheint es auch mir sinnvoll dies weiter zu untersuchen.

Melde mich bald.
gruß

michaa7

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

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

Re: grep kaputt?

Beitrag von Meillo » 13.01.2023 22:23:13

JTH hat mich (in einer PM) auf einen Loesungsweg gebracht. Er hat das Relevante geschrieben, es selber wohl nur nicht richtig interpretiert, sonst haette er diese Erklaerung auch gesehen.

Frueher stand in der Manpage von GNU grep:
If the first few bytes of a file indicate that the file contains binary data, assume that the file is of type TYPE.
D.h. eine Datei wurde als binaer eingestuft, wenn der Beginn der Datei binaer aussah.

In einem aktuellen GNU grep steht in der Manpage:
Non-text bytes indicate binary data; these are either output bytes that are improperly encoded for the current locale, or null input bytes when the -z option is not given.
D.h. wenn Null-Bytes enthalten sind, wird die Datei als binaer angesehen, oder -- und hier kommt nun die interessante, neue Regel -- wenn der *Output* im aktuellen Locale nicht korrekt kodiert waere.

Folglich ist die theoretische Ueberlegung, dass alle Zeilen, die ``policy'' enthalten, valide im aktuellen Locale der Shell sind. Damit arbeitet GNU grep wie auf einer reinen Textdatei. Zumindest eine der Zeilen, die aber ``apt'' enthalten, enthaelt irgendwelche Bytes die im aktuellen Locale nicht valide kodiert sind. Darum werden diese nicht ausgegeben, sondern die Datei wird stattdessen als binaer angesehen.

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.

Das Verhalten hat sich vermutlich aus dem Grund geaendert, dass eine neuere Version von GNU grep eingesetzt wird, die sich hier anders verhaelt als es frueher der Fall war.

Da ich kein aktuelles GNU grep zur Verfuegung habe, kann ich das Phaenomen nicht reproduzieren, aber vielleicht kann es jemand von euch.
Use ed once in a while!

Antworten