UNIX find, strings und fgrep in sinnvoller Art und Weise verknüpft ?

  • Ich suche auf einer UNIX-Maschine auf der Festplatte inkl. Unterverzeichnissen in Dateien jeglicher Art (also auch in Binärdateien) eine Zeichenkette.


    Dazu ist mir folgendes eingefallen:


    find / -type f -exec strings '{}' | fgrep 'qwerty' \;


    Das funktioniert soweit, aber ich kriege dann nur eine Ausgabe, dass 'qwerty' gefunden wurde, aber nicht in welcher Datei.

    Das Problem ist, den Dateinamen nur bei einem Treffer auszugeben, die Zeichenkette nochmal ausgegeben zu bekommen ist eigentlich nicht wirklich mein Ziel.


    Hat jemand eine Idee, wie man das Problem lösen kann ?

    "Ich habe keine Zeit mich zu beeilen." (Igor Strawinsky)


    ... und schaut auch mal bei meinem Blog vorbei ...

  • Ok, mein UNIX hier ist das "Coherent", das kann via grep Befehl definitiv nicht rekursiv suchen. Daher ist das so oder so, selbst wenn Binärdateien durchsucht werden könnten, keine Option. Daher auch meine Frage, wie man das mit "find" auch schaffen kann...

    "Ich habe keine Zeit mich zu beeilen." (Igor Strawinsky)


    ... und schaut auch mal bei meinem Blog vorbei ...

  • ...

    Das funktioniert soweit, aber ich kriege dann nur eine Ausgabe, dass 'qwerty' gefunden wurde, aber nicht in welcher Datei.

    Wenn grep an mehr als einem Ort sucht, gibt es den Fundort an. Als fiktiver zweiter Suchort tut es auch /dev/null. Statt zum Beispiel

    Code
     find . -type f -name \*.xml -exec grep bla {} \;

    wäre dies möglich:

    Code
    find . -type f -name \*.xml -exec grep bla {} /dev/null \;
  • das grep den Fundort selber ausgibt geht nur wenn grep auch 'weiß' das es mehrere files durchsucht hat. da durch das find die einzelnen grep aufrufe unabhängig voneinander sind hilft das hier nicht. man müßte aber im find zwei expressions per and verknüpfen können. die erste expression ist das exec und danach noch ein -print das nur greift wenn das exec true geliefert hat.


    also etwas in der art:


    Code
    find . -type f -name \*.xml -exec grep bla {} \; -a -print


    wenn dein grep das kann reicht vielleicht aber auch ein -H um dein filenamen in jedem fall auszugeben.

  • Ich habe es gelöst, indem ich nicht 'strings' gepiped nach 'grep' (bzw. 'fgrep') nach dem '-exec' aufrufe, sondern indem ich das in eine shell-script Datei reingeschrieben habe, in dem Skript kann ich $1 (als übergebenen Parameter mit dem Dateinamen) beliebig auch mehrfach verarbeiten.


    In Coherent kann das 'grep' fast gar nichts, und schon mal gar nicht binäre Dateien durchsuchen. Daher erübrigen sich alle weiteren Versuche mit diversen 'grep' Optionen.

    "Ich habe keine Zeit mich zu beeilen." (Igor Strawinsky)


    ... und schaut auch mal bei meinem Blog vorbei ...

  • Läuft Windows 2.11 überhaupt selbst?


    Im Ernst, dieselbe Version des Tools macht auf jeden Fall auf jedem unterstützen Windows dasselbe. Ich nutze es schon zig Jahre, aber ab welcher Windows Version weiß ich nicht mehr. Wenn ich den Thread lese, gilt das ja für grep nicht ansatzweise, dass es EIN grep in EINER Version für alle UNIXe gibt mit EINER Synatx und demselben Satz an Command Line Switches gibt.

  • Im Ernst, dieselbe Version des Tools macht auf jeden Fall auf jedem unterstützen Windows dasselbe. Ich nutze es schon zig Jahre, aber ab welcher Windows Version weiß ich nicht mehr. Wenn ich den Thread lese, gilt das ja für grep nicht ansatzweise, dass es EIN grep in EINER Version für alle UNIXe gibt mit EINER Synatx und demselben Satz an Command Line Switches gibt.

    Hmm, also ohne das hier schönreden zu wollen muss ich doch UNIX ein klein wenig verteidigen...


    1) Coherent ist kein UNIX sondern ein rewrite. Wenn ich hier jetzt zuhause ein Programm schreibe und das auch XYexplorer nenne, dann wird das auch nicht identisch funktionieren.


    2) hier wird gerade ein modernes grep (also Jahrgang 2021) verglichen mit einem aus Coherent (Letzte offizielle Version von 1994.) Mach das mal mit XYxplorer. Achja, das gab es ja damals noch nicht ;)


    3) Mal abgesehen von alten und neuen Versionen gibt es bei UNIX im wesentlichen seit langem 2 Linien: BSD und System-V. Ganz so verwirrend wie sie manchmal dargestellt wird ist die Situation dann doch nicht.


    4) Du vergleichst ein kostenpflichtiges Zusatz-Programm mit dem Basissystem. Das Zusatz-Programm XYxplorer gibt es überhaupt nur weil der IExplorer immer scheiße war :)


    Übrigens bin ich gerade nicht sicher ob XYxplorer regexp in Binärdateien kann. Überhaupt unterstützung für reguläre Ausdrücke ist da noch nicht so lange enthalten ;)

    Suche: SGI Indigo (gerne IP12), DEC/DIGITAL CRT Monitor und ein VT240 (inkl. Monitor).

  • Alles richtig, ich wollte hier auch keinen Religionskrieg entfachen, aber eine Zeile wie

    find . -type f -name \*.xml -exec grep bla {} /dev/null \;

    hat das geradezu herausgefordert.


    Ich nutze XYplorer seit ziemlich genau 13 Jahren. Mein Outlook Archiv sagt zur ersten gekauften Lizenz "Valid: for all versions below v8.70". Zu welcher Windows Version das passte, kann ich nicht mehr sagen. Heute sind wir jedenfalls etliche Versionen weiter und wann regexp da reinkam, kann ich auch nicht sagen.


    So, das sagt einer, der seit über 40 Jahren irgendwelche UNIXen immer mal wieder extrem sporadisch nutzen musste, der es ebenso lange aus tiefstem Herzen verabscheut, weil er sich solche grep Zeilen einfach nicht merken kann und jedesmal an den man Pages verzweifelt und der - nicht zu vergessen - den K&R Hoax namens "C" zum Anlass nahm, das Programmieren für die nachfolgenden Jahrzehnte einzustellen. Jetzt bin ich für UNIX und C wohl zu :soonbart: , da wird wohl keine Liebe mehr erwachsen. Wenn ich bloß wüsste wie ich bei Windows die Zwangsupdates aussperre...::cry::;)

  • Du wirst es kaum glauben, aber so eine Zeile halten Leute, die das regelmäßig benutzen für total normal. Für meinen Begriff fehlen da sogar noch zwei backslashes, jeweils einer vor jeder geschweiften Klammer. Dann sieht das noch abartiger aus. ;)


    Das ist aber auch genau der einzige Fehler an dem ganzen: Wenn man es nicht regelmäßig benutzt, ist es teils abartig skurril. Und auch solche Sachen, wie eine Shell, die eigentlich komplett programmierbar ist, aber per se keine Countervariablen zuläßt, kann man schon als sehr seltsam empfinden.

    Bei "C" ist es eigentlich so ähnlich. Das wird auch besser, wenn man es immer mal ausprobiert.

  • Aber mal zurück zum Thema: GREPA hat doch einen Parameter der es nur den Fundort (Datei) ohne die Fundstelle (Zeile) ausgeben lässt. Ist das nicht -s oder -q oder so?

    Also grep -r -s / QWERTY müsste doch reichen. (Oder -q halt)

  • In Coherent kann das 'grep' fast gar nichts, und schon mal gar nicht binäre Dateien durchsuchen. Daher erübrigen sich alle weiteren Versuche mit diversen 'grep' Optionen.


    Doch, auch das sollte da schon gehen, wenn auch auf Umwegen


    Bsp:


    for i in ./*.jpg ; do if ( hexdump -v -e '/1 "%02X "' $i | grep "51 57 45 52 54 59" ) ; then echo "true in Datei"; echo $i ; else echo "none found"; fi ; done


    Da Hexdump dann evtl. zwischendurch immer mal was schreibt, sollte man die Dateinamen mit echo $i >> dateiliste.lst besser in eine Liste schreiben.

  • ThoralfAsmussen - da ist ein Denkfehler drin. Denn wenn 'hexdump' das zeilenweise ausgibt, kann es auch mal passieren, dass so eine Byte-Folge gerade am Ende der einen Zeile anfängt, und dann in der nächsten fortgesetzt wird - dazwischen steht dann bspw. auch die Byte-Adresse/Zeilennummer noch, die das Ganze vereiteln würde. Außerdem habe ich das Thema schon längst für mich beerdigt, hatte es ja anders gelöst.

    "Ich habe keine Zeit mich zu beeilen." (Igor Strawinsky)


    ... und schaut auch mal bei meinem Blog vorbei ...

  • Allerdings hatte coherent noch kein hexdump. Es gibt od, das macht dann aber wieder Zeilenumbrüche und erlaubt keine Format strings.


    Und wenn man jetzt anfängt Software zu kompilieren kann man auch einfach gleich ein modernes grep nehmen ;)

    Suche: SGI Indigo (gerne IP12), DEC/DIGITAL CRT Monitor und ein VT240 (inkl. Monitor).