Suche in Dateien

[TilmannW]

Hallo,
gibt es kein GUI-Programm mit dem man nach Strings in Dateien suchen kann ?
Also wenn man einen String innerhalb von Dateien in größeren Ordnerstrukturen suchen will.

Das man sich sowas aus Kommandozeilenbefehlen zusammenbasteln kann ist mir klar. Sowas weiß ich aber nicht auswendig und finde es sehr mühsälig.

Gruß Tilmann

[inne]

Welches GUI-Toolkit soll es sein

[TilmannW]

Ich habe die Frage nicht verstanden; habe aber auch eine Möglichkeit mittels Kommandozeile gefunden, die nicht so schlimm kompliziert ist:

Terminal; ins entsprechende Verzeichnis wechseln;
grep -r -i 'Suchwort' ./

funktioniert.

Gruß Tilmann

[inne]

Ok, ansonsten wollte ich wissen ob GTK (Gnome) oder QT (KDE) und was es da noch alles gibt.

Ich habe Heute zu agrep (eigentlich Fuzzy Suche) und ugrep gelesen. Letzteres ist vlt. ganz nett, wenn du nun auf der Commandozeile bleibst. Die Argument -r und -i sollten gleich bleiben. Habe das aber auch jetzt erst für mich gefunden und noch nicht so viel damit gemacht.

[heisenberg]

Als GUI hat linuxnews.de hat da vor kurzem was gehabt: Linuxnews: FSearch 0.2.1 ist da

Für die Kommandozeile gäbe es noch fzf, den fuzzy finder.

Habe beides noch nicht benutzt. Ich nutze nur grep.

[Meillo]

Ich habe die Frage nicht verstanden; habe aber auch eine Möglichkeit mittels Kommandozeile gefunden, die nicht so schlimm kompliziert ist:

Terminal; ins entsprechende Verzeichnis wechseln;
grep -r -i 'Suchwort' ./

funktioniert.

Noch zwei Tipps dazu:

Wenn du `fgrep' statt `grep' verwendest, dann kannst du auch nach Sonderzeichen suchen, ohne dass es zu Irritiationen wegen regulaerer Ausdruecke kommt.

Wenn du nur wissen willst, in welchen Dateien, der Suchbegriff vorkommt, dann kannst du noch ein `-l' (mnemonic: Liste) hinzufuegen.

Mehr als das brauchst du eigentlich nicht.

Btw: Natuerlich kannst du, statt zuerst ins passende Verzeichnis zu wechseln, den Verzeichnispfad auch einfach als Argument angeben. In deinem Beispiel `./' (was identisch ist wie nur ein Punkt) kannst du also ersetzen durch den Pfad.

Beispiele:

Code: Alles auswählen

fgrep -ri 'hallo' ~/Dokumente

fgrep -ril 'heute morgen' mein-buch/kapitel2/

fgrep -ri 'gnome' /usr/share/doc

[hikaru]

Das was du jetzt mit grep machst, sollte catfish in Farbe und bunt machen.

Falls du wider erwarten Strings in Binärdateien suchen solltest, dann wäre /usr/bin/strings aus binutils eine Option - das dann allerdings wieder ohne GUI.

[tobo]

Falls du wider erwarten Strings in Binärdateien suchen solltest, dann wäre /usr/bin/strings aus binutils eine Option - das dann allerdings wieder ohne GUI.

Der Treffer ansich funktioniert mit grep ebenso - will man ihn belegen, dann grep -a.

[hikaru]

Wenn man es allein mit grep macht, muss man aber für eine sinnvolle Ausgabe mit Regex arbeiten.

[Meillo]

Wenn man es allein mit grep macht, muss man aber für eine sinnvolle Ausgabe mit Regex arbeiten.

Darum mein Tipp mit `fgrep' (hast du vielleicht ueberlesen), das man an allen Stellen einfach statt `grep' verwenden kann. Der gesuchte Ausdruck wird dann als Suchwort verwendet, also literal, genau so wie man es angibt.

Wenn du `fgrep' statt `grep' verwendest, dann kannst du auch nach Sonderzeichen suchen, ohne dass es zu Irritiationen wegen regulaerer Ausdruecke kommt.

... oder man macht den RegExp-Kurs und kann dann die Macht von regulaeren Ausdruecken nutzen.

[hikaru]

Darum mein Tipp mit `fgrep' (hast du vielleicht ueberlesen),

Ja hatte ich tatsächlich überlesen, aber es ändert nichts an meinem Punkt, dass es mit strings einfacher ist.

Beispielaufgabe:
Erstelle eine Liste der unterstützten ABI-Symbole deiner glibc!

[Meillo]

[...] es ändert nichts an meinem Punkt, dass es mit strings einfacher ist.

`strings' listet nur alle lesbaren Teile einer Binaerdatei auf, die eine gewisse Laenge haben. Wenn man darin suchen will, dann muss man zudem durch fgrep pipen. Das kann aber durchaus die beste Wahl sein, bezogen auf die Ausgabe, weil hier sicher keine Binaerdaten ausgegeben werden. Insofern finde ich deinen Hinweis auf `strings' wertvoll als Ergaenzung.

`fgrep -a' kann in Binaerdateien ebenso nach lesbaren Zeichen suchen wie in Textdateien, allerdings wird die Ausgabe vermutlich nicht wie gewuenscht sein. Man wird das also mit `-o' oder `-l' nutzen wollen.

Beispielaufgabe:
Erstelle eine Liste der unterstützten ABI-Symbole deiner glibc!

Dafuer ist `nm' das Tool der Wahl: ``nm - list symbols from object files''.

Ich wuesste nicht, wie ich das mit `strings' oder `grep -a' hinbekommen sollte, weil beide Programme auch alle einkompilierten Strings auflisten werden.

[TRex]

Es mag euch ja Spaß machen, aber irgendwie beschleicht mich das Gefühl, dass TillmannW nicht die Absicht hat, mit regulären Ausdrücken [oder] in Binärdateien zu suchen

[Meillo]

Es mag euch ja Spaß machen, aber irgendwie beschleicht mich das Gefühl, dass TillmannW nicht die Absicht hat, mit regulären Ausdrücken [oder] in Binärdateien zu suchen

Ich habe den Eindruck, dass er mit dem von ihm erwaehnten grep-Befehl und mit hikarus Hinweis auf catfish sein Problem vollstaendig geloest hat, und wir uns nun mit Detaildiskussionen austoben koennen.

Falls ein Teil deiner Frage, TilmannW, aber noch offen sein sollte, dann sag es uns. Dann schieben wir die Ausuferungen beiseite und widmen uns reuevoll wieder deinen Fragen.

[hikaru]

`fgrep -a' kann in Binaerdateien ebenso nach lesbaren Zeichen suchen wie in Textdateien, allerdings wird die Ausgabe vermutlich nicht wie gewuenscht sein. Man wird das also mit `-o' oder `-l' nutzen wollen.

Ja. Aber wenn du ausschließlich mit (f)grep und -o hantierst, dann musst du mit Regex arbeiten, falls du nur einen Teil des Suchstrings kennst. Und du musst zumindest das Pattern kennen, auf das der Gesamtstring matcht.

Beispielaufgabe:
Erstelle eine Liste der unterstützten ABI-Symbole deiner glibc!

Dafuer ist `nm' das Tool der Wahl: ``nm - list symbols from object files''.

Wenn ich das auf meine glibc loslasse, dann bekomme ich keine ABI-Symbole zurück:

Code: Alles auswählen

$ nm /lib/x86_64-linux-gnu/libc-2.31.so
nm: /lib/x86_64-linux-gnu/libc-2.31.so: no symbols

Ich wuesste nicht, wie ich das mit `strings' oder `grep -a' hinbekommen sollte, weil beide Programme auch alle einkompilierten Strings auflisten werden.

Ich weiß nicht, ob wir hier aneinander vorbeireden. In das glibc-Binary sind die Namen der ABI-Symbole als Strings einkompiliert. Nach diesen Strings suchen Programme, die eine bestimmte glibc-Version voraussetzen, weil sie Funktionen nutzen, die erst ab dieser Version verfügbar sind. U.A. diese Liste gibt mir strings und dann lassen sich, ohne Regex benutzen zu müssen, die Versionen extrahieren:

Code: Alles auswählen

$ strings /lib/x86_64-linux-gnu/libc-2.31.so | grep GLIBC
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
GLIBC_2.18
GLIBC_2.22
GLIBC_2.23
GLIBC_2.24
GLIBC_2.25
GLIBC_2.26
GLIBC_2.27
GLIBC_2.28
GLIBC_2.29
GLIBC_2.30
GLIBC_PRIVATE
GNU C Library (Debian GLIBC 2.31-13+deb11u3) stable release version 2.31.

Edit:
So zumindest der Stand unter Debian. Unter Suse sieht es eher so aus, wie du es darstellst:

Code: Alles auswählen

:nm /lib64/libc-2.31.so | grep GLIBC
0000000000000000 A GLIBC_2.10
0000000000000000 A GLIBC_2.11
0000000000000000 A GLIBC_2.12
0000000000000000 A GLIBC_2.13
0000000000000000 A GLIBC_2.14
0000000000000000 A GLIBC_2.15
0000000000000000 A GLIBC_2.16
0000000000000000 A GLIBC_2.17
0000000000000000 A GLIBC_2.18
0000000000000000 A GLIBC_2.2.5
0000000000000000 A GLIBC_2.2.6
0000000000000000 A GLIBC_2.22
0000000000000000 A GLIBC_2.23
0000000000000000 A GLIBC_2.24
0000000000000000 A GLIBC_2.25
0000000000000000 A GLIBC_2.26
0000000000000000 A GLIBC_2.27
0000000000000000 A GLIBC_2.28
0000000000000000 A GLIBC_2.29
0000000000000000 A GLIBC_2.3
0000000000000000 A GLIBC_2.3.2
0000000000000000 A GLIBC_2.3.3
0000000000000000 A GLIBC_2.3.4
0000000000000000 A GLIBC_2.30
0000000000000000 A GLIBC_2.4
0000000000000000 A GLIBC_2.5
0000000000000000 A GLIBC_2.6
0000000000000000 A GLIBC_2.7
0000000000000000 A GLIBC_2.8
0000000000000000 A GLIBC_2.9
0000000000000000 A GLIBC_PRIVATE
00000000003e7500 d ___sys_errlist_GLIBC_2_1
00000000003e7500 d ___sys_errlist_GLIBC_2_3
00000000003e7500 d ___sys_errlist_GLIBC_2_4
00000000001be678 r ___sys_nerr_GLIBC_2_1
00000000001be67c r ___sys_nerr_GLIBC_2_3
00000000001be680 r ___sys_nerr_GLIBC_2_4
0000000000118a9e t __bdflush_GLIBC_2_0
00000000003e7500 d __sys_errlist_GLIBC_2_1
00000000003e7500 d __sys_errlist_GLIBC_2_3
00000000003e7500 d __sys_errlist_GLIBC_2_4
00000000001be678 r __sys_nerr_GLIBC_2_1
00000000001be67c r __sys_nerr_GLIBC_2_3
00000000001be680 r __sys_nerr_GLIBC_2_4

Und ein simples, Regex-freies grep auf den strings-Output reicht hier auch nicht (Ausgabe wegen Länge gekürzt):

Code: Alles auswählen

:strings /lib64/libc-2.31.so | grep GLIBC | tail
fmemopen@@GLIBC_2.22
clock_gettime@@GLIBC_2.17
posix_spawnp@GLIBC_2.2.5
getrpcent_r@@GLIBC_2.2.5
key_secretkey_is_set@GLIBC_2.2.5
getprotobynumber_r@@GLIBC_2.2.5
host2netname@GLIBC_2.2.5
getmsg@GLIBC_2.2.5
_IO_file_close_it@@GLIBC_2.2.5
_obstack@GLIBC_2.2.5

[Meillo]

`fgrep -a' kann in Binaerdateien ebenso nach lesbaren Zeichen suchen wie in Textdateien, allerdings wird die Ausgabe vermutlich nicht wie gewuenscht sein. Man wird das also mit `-o' oder `-l' nutzen wollen.

Ja. Aber wenn du ausschließlich mit (f)grep und -o hantierst, dann musst du mit Regex arbeiten, falls du nur einen Teil des Suchstrings kennst. Und du musst zumindest das Pattern kennen, auf das der Gesamtstring matcht.

Ich merke, dass es doch sehr von den Anwendungsszenarien abhaengt, die wir im Kopf haben. Je nachdem wie das aussieht, passen die Ansaetze besser oder schlechter.

Beispielaufgabe:
Erstelle eine Liste der unterstützten ABI-Symbole deiner glibc!

Dafuer ist `nm' das Tool der Wahl: ``nm - list symbols from object files''.

Wenn ich das auf meine glibc loslasse, dann bekomme ich keine ABI-Symbole zurück:

Code: Alles auswählen

$ nm /lib/x86_64-linux-gnu/libc-2.31.so
nm: /lib/x86_64-linux-gnu/libc-2.31.so: no symbols

Ich wuesste nicht, wie ich das mit `strings' oder `grep -a' hinbekommen sollte, weil beide Programme auch alle einkompilierten Strings auflisten werden.

Ich weiß nicht, ob wir hier aneinander vorbeireden. In das glibc-Binary sind die Namen der ABI-Symbole als Strings einkompiliert. Nach diesen Strings suchen Programme, die eine bestimmte glibc-Version voraussetzen, weil sie Funktionen nutzen, die erst ab dieser Version verfügbar sind. U.A. diese Liste gibt mir strings und dann lassen sich, ohne Regex benutzen zu müssen, die Versionen extrahieren:

Code: Alles auswählen

$ strings /lib/x86_64-linux-gnu/libc-2.31.so | grep GLIBC
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
GLIBC_2.18
GLIBC_2.22
GLIBC_2.23
GLIBC_2.24
GLIBC_2.25
GLIBC_2.26
GLIBC_2.27
GLIBC_2.28
GLIBC_2.29
GLIBC_2.30
GLIBC_PRIVATE
GNU C Library (Debian GLIBC 2.31-13+deb11u3) stable release version 2.31.

Edit:
So zumindest der Stand unter Debian. Unter Suse sieht es eher so aus, wie du es darstellst:

Code: Alles auswählen

:nm /lib64/libc-2.31.so | grep GLIBC
0000000000000000 A GLIBC_2.10
0000000000000000 A GLIBC_2.11
0000000000000000 A GLIBC_2.12
0000000000000000 A GLIBC_2.13
0000000000000000 A GLIBC_2.14
0000000000000000 A GLIBC_2.15
0000000000000000 A GLIBC_2.16
0000000000000000 A GLIBC_2.17
0000000000000000 A GLIBC_2.18
0000000000000000 A GLIBC_2.2.5
0000000000000000 A GLIBC_2.2.6
0000000000000000 A GLIBC_2.22
0000000000000000 A GLIBC_2.23
0000000000000000 A GLIBC_2.24
0000000000000000 A GLIBC_2.25
0000000000000000 A GLIBC_2.26
0000000000000000 A GLIBC_2.27
0000000000000000 A GLIBC_2.28
0000000000000000 A GLIBC_2.29
0000000000000000 A GLIBC_2.3
0000000000000000 A GLIBC_2.3.2
0000000000000000 A GLIBC_2.3.3
0000000000000000 A GLIBC_2.3.4
0000000000000000 A GLIBC_2.30
0000000000000000 A GLIBC_2.4
0000000000000000 A GLIBC_2.5
0000000000000000 A GLIBC_2.6
0000000000000000 A GLIBC_2.7
0000000000000000 A GLIBC_2.8
0000000000000000 A GLIBC_2.9
0000000000000000 A GLIBC_PRIVATE
00000000003e7500 d ___sys_errlist_GLIBC_2_1
00000000003e7500 d ___sys_errlist_GLIBC_2_3
00000000003e7500 d ___sys_errlist_GLIBC_2_4
00000000001be678 r ___sys_nerr_GLIBC_2_1
00000000001be67c r ___sys_nerr_GLIBC_2_3
00000000001be680 r ___sys_nerr_GLIBC_2_4
0000000000118a9e t __bdflush_GLIBC_2_0
00000000003e7500 d __sys_errlist_GLIBC_2_1
00000000003e7500 d __sys_errlist_GLIBC_2_3
00000000003e7500 d __sys_errlist_GLIBC_2_4
00000000001be678 r __sys_nerr_GLIBC_2_1
00000000001be67c r __sys_nerr_GLIBC_2_3
00000000001be680 r __sys_nerr_GLIBC_2_4

Und ein simples, Regex-freies grep auf den strings-Output reicht hier auch nicht (Ausgabe wegen Länge gekürzt):

Code: Alles auswählen

:strings /lib64/libc-2.31.so | grep GLIBC | tail
fmemopen@@GLIBC_2.22
clock_gettime@@GLIBC_2.17
posix_spawnp@GLIBC_2.2.5
getrpcent_r@@GLIBC_2.2.5
key_secretkey_is_set@GLIBC_2.2.5
getprotobynumber_r@@GLIBC_2.2.5
host2netname@GLIBC_2.2.5
getmsg@GLIBC_2.2.5
_IO_file_close_it@@GLIBC_2.2.5
_obstack@GLIBC_2.2.5

Wir haben hier schon zum Teil aneinander vorbei geredet, aber auch nicht in jeder Weise.

Wie ich jetzt auch erst gelernt habe, muss man `nm' fuer Shared Objects mit `-D' aufrufen, dann bekommst du eine Ausgabe.

Ich verstehe, was an `strings | grep' bequem ist. Mir geht es hier mehr um den strukturellen Unterschied:

Mit `strings' schaust du ohne Inhaltskenntnis in die Binaerdatei und holst alles raus was so aehnlich aussieht. Wenn in der Binaerdatei ein String steckt (z.B. fuer eine Fehlermeldung oder einen Vergleich), der ``GLIBC_99.88.77'' lautet, dann wird der ebenso aufgelistet wie die Versionsnummern, da `strings' keine Inhaltskenntnis hat, sondern nur schaut, was druckbare Zeichen bestimmter Laenge sind.

`nm' dagegen hat ein Verstaendnis des Aufbaus von Object Files. Es listet nur die darin enthaltenen Symbole auf, nicht aber irgendwelche sonstigen Strings. Wenn es dir also um Symbole geht, dann waere es sinnvoller -- finde ich -- ein Tool zu verwenden, das nur Symbole auflistet, weil dessen Antwort korrekter ist. (`strings' ist vermutlich bequemer, aber mit den Kosten moeglicher false Positives. Wenn das fuer einen schnellen Blick nicht stoert, kann man es ja trotzdem nutzen.)


Hier geht es ja auch nicht darum, den besten oder gar einzig wahren Weg zu finden, sondern wir beschreiben verschiedene Wege und ihre Eigenschaften, damit wir unser Repertoire an Moeglichkeiten und unser Verstaendnis erweitern.