Suchen nach Text
Oft weiß der Benutzer, dass sich unterhalb des aktuellen Pfades irgendwo eine Datei versteckt, in der sich ein gesuchter Textstring »Blabla« befindet. In der Shell ließe sich nun ein Find-Befehl wie etwa
find . -type f -exec grep Blabla {}/dev/null \;
absetzen, aber das ist extrem viel Tipparbeit und erfordert einiges Nachdenken, speziell wegen des Tricks mit »/dev/null« , das bei Einzeltreffern auch den Dateinamen anzeigt, und mit dem seltsamerweise erforderlichen maskierten Semikolon, das der Option »-exec« zeigt, dass das ihr übergebene Kommando damit endet.
Früher hatte ich ein Skript »findgrep« , das mit Perls File::Find-Modul eine rekursive Textsuche startete, aber seit es »ack« [3] gibt, lade ich stattdessen das mächtige Kommando einfach vom CPAN und tippe
ack Blabla
ein – fertig ist der Lack. Allerdings ist das Skript sehr penibel mit Dateitypen: Nur was es aufgrund der Namensendung als textähnliche Datei ansieht, untersucht es auch. Wer alle Dateien durchforsten will, muss »ack -a Blabla« eingeben.
Wer gesteigerten Wert auf Performance legt, ist in einem Git-Repository mit der oft übersehenen Funktion
git grep Blabla
weit besser bedient. Da Git die von ihm verwalteten Dateien in einem Index abspeichert, braucht es für die rekursive Suche keine Dateibäume zu durchforsten und schlägt deshalb den ungeschlachten Ansatz gerade bei Dateien, die noch nicht im Buffercache des Operationssystems liegen und in tief verschachtelten Ordnern ausharren, um Längen.
Automatisch formatiert
Damit selbst geschriebene Perl-Skripte vorgegebenen Normen genügen, schickt der ordnungsliebende Programmierer sie am Ende durch den Beautifyer »perltidy« . Dieses Skript ist als CPAN-Modul erhältlich und versteht eine Fülle von Konfigurationen, die jedem Stil gerecht werden. Wo stehen die geschweiften Klammern – in der If-Zeile oder in der nächsten? Kommt das »else« direkt nach der schließenden geschweiften Klammer oder erst nach einem Zeilenumbruch? Leerzeichen zwischen runden Klammern bei Funktionsaufrufen und deren Argumenten? Und – ganz wichtig – wie groß ist die maximale Zeilenlänge, ab wann soll der Formatierer lange Codezeilen umbrechen?
Die Manualseite von »perltidy« listet alle Optionen auf und beschreibt deren Wirkung. Listing 3 zeigt die Konfiguration für Perl-Listings im Linux-Magazin. Die Zeilenbreite beträgt 43 Zeichen, Zeilen in Blöcken rückt der Formatierer um zwei Zeichen ein »-i=2« . Bricht er eine Zeile um, rückt er den Zeilenrest auf der nächsten ebenfalls um zwei Zeichen ein »-ci=2« . Else-Anweisungen folgen direkt ohne Zeilenumbruch nach der schließenden geschweiften Klammer des If-Blocks (Cuddled Else, »-ce« ).
Listing 3
perltidyrc
01 # perltidy-Optionen für Perlskripts im Linux-Magazin 02 03 -l=43 # line width 04 -i=2 # 2 cols indent 05 -ci=2 # 2 cols continuation indent 06 -ce # cuddled else 07 -vt=2 # vertical tightness 08 -nbbc # no blank lines before whole-line comments
Und da Platz im Linux-Magazin stets Mangelware ist und die Redakteure gern damit geizen, steht die Vertical Tightness, also die vertikale Textdichte, auf dem höchsten Wert »-vt=2« . Bei dieser Option geizt wiederum der Formatierer mit Zeilenumbrüchen wie’s nur geht. Auch um Platz zu sparen, bestimmt »-nbbc« noch, dass vor ganzzeiligen Kommentaren keine Leerzeilen stehen.
