[linux-l] Kommando für das Programm "Nach Dateien suchen" gesucht

[Steffen Dettmer]

Hi,

im Vorfeld mal zu:

* Katja:
> Linux auf einem Blatt
> www.helmbold.de/linux

wollte nur mal bemerken, dass da *überhaupt nichts* über Linux steht. 

Es werden gängige GNU Kommandozeilentools beschrieben. Die funktionieren
unter cygwin oder ähnlichem sicherlich ziemlich genauso 

:-)

oki.

* Norman Steinbach wrote on Tue, Dec 12, 2006 at 13:52 +0100:
> Detlef Lechner wrote:
> >Du machst Dich bei mir (und wahrscheinlich bei anderen auch) beliebter,
> >wenn Du beim Antworten zwischen Zitat und eigenem Text stets eine
> >Leerzeile läßt. (Mein Mailclient stellt Zitat und eigenen Text nicht in
> >unterschiedlichen Farben dar.)
> Ähm? Dafür gibts doch die "Quote-Zeichen" (>>) am Anfang jeder Zeile? 
> Mein Mailclient stellt da auch nix farbig dar - trotzdem ist eine 
> zusätzliche leerzeile zwischen Zitat und eigenem Text IMHO der 
> Übersichtlichkeit eher abträglich, weil man dann zwischen eigenem Text 
> und darauffolgendem Zitat mindestens *2* Leerzeilen einfügen müsste, 
> besser 3 - und irgendwann sieht die Mail dann einfach zerrupft aus.

Also, bei mir ist es sowohl im Mailprogramm (mutt) als auch im Editor
(vim) farbig, aber eine (1) Leerzeile zwischen Zitat und Text finde ich
auch besser. Warum man zwei oder drei Leerzeilen brauchen sollte, ist
mir aber unklar. Natürlich kann man in Ausnahmefällen drei oder zehn
machen, wenn man etwas noch mehr abgrenzen will, oder sowas:

=====8<----------------------------------------------------------
auch abgegrenzt
--------------------------------------------------------->8======

BTW, die Quote-Zeichen sind auch nicht ">>" sondern "> > ", weil ein
einzelnes Quote-Zeichen "> ", also mit Leerzeichen ist.

> Leerzeilen UNTER dem selbstgeschriebenen Text und dem darauffolgenden
> Zitat sind IMHO sinnvoller. 

Ja, da auch, klar.

> Zudem erkennt man dann auch, welcher Text zu welchem Zitat gehört,
> wenn diese jeweils an einem Block zusammenhängen.

Das erkennt man ja aber auch mit Leerzeile, weil der Text ja unter dem
Bezug steht :-)

> Wenn ich z.B. ls und grep oder find und grep für eine komplexe 
> Suchaktion verbinden möchte, so möchte ich in einem 
> Nachschlagewerk/Befehlsreferenz nach der Art der Suchaktion suchen 
> müssen, um zu finden, wie ich den Befehl (der ja aus mehreren einzelnen 
> Teil-Befehlen besteht) eingeben muss. 

Das Tolle ist doch, dass einfache, universelle Bausteine wie find und
grep so schön kombinierbar sind. Hat man nur je zehn find und grep
Optionen, könnte man bei einfacher Kombination schon 100 Kombinationen
haben. Nun kann man 10 Optionen in einer Manpage oder so erklären, aber
ja nicht alle möglichen Kombinationen!

Das einem diese Zusammenhänge nicht so klar sind, ist IMHO Schuld von
GUIs, wie diesem gnome-search-tool. Dieses Tool ist der Meinung, dass
nach regulären Dateien ab genau einem Pfad gesucht wird und dass auch in
der Datei nach einem Muster gesucht wird. So klar ist das aber nicht.
Werden nicht-reguläre Files gefunden? Werden sie auch durchsucht oder
nicht? Wann wird symlinks gefolgt und wann nicht?

Der Autor dieses Tools hat sich willkürlich irgendwas ausgesucht und
der Welt "erklärt", dass man halt so suche... Statt vieler, kleiner,
einfacher Bausteine hat man ein grosses Spezialtool. Das geht halt nur
nicht immer. Und ist schlecht automatisierbar. Wenn Du nun die mit
gnome-search-tool gewonnene Dateiliste ausdrucken willst?

Hier würde ein

$ find /path/ -iname 'filename' | print

funktionieren (print ist ein alias ;)). Bei gnome-search-tool müsste ich
wohl manuell scrollen und viele Screenshot-Grafiken drucken.

Es wird wohl kaum ein Buch geben, wo man unter "Wie man eine Dateiliste
ausdruckt" (falls das eine "Suchaktion" in Deinem Sinne ist) oder "Wie
man grosse, alte Dateien in ein "old" Verzeichnis verschiebt" oder
welche Anforderung man auch immer hat (na klar, kann das
gnome-search-tool auch alles nicht; wie man das mit Windows ohne cygwin
hinkriegen wollen würde, ist mir auch nicht klar).

Aber man kann beschreiben, wie man grosse und/oder alte Dateien findet
und wie man für eine Liste von Dateinamen ein Kommando ausführt und wie
man Datei(en) in ein "old" Verzeichnis verschiebt.

> Wenn ich nun etwas über die einzelnen Teilbefehle eher grundlegendes

Das sind keine "Teilbefehle". Es sind Befehle. Eigentlich ist auch nur
find der Befehl. Im Gegensatz zu vielen GUI-Suchen durchsucht das
natürlich nicht den Inhalt, weil das Blöd ist und nicht passt. Das
machen die GUIs ja auch nur, weil man kein "-exec grep" reinschreiben
kann. Genau diese Kombination ist aus irgendwelchen Gründen als GUI da,
die anderen Millionen nicht. Gut, kann man machen.

Was man IMHO aber nicht machen kann: daraus zu schliessen, das dies eine
logische "Einheit" wäre oder ein "atomarer Suchbefehl". Es ist nur eine
falsche Annahme einer GUI - Zufall. Das heisst nicht, dass das immer
schlecht sein muss oder so! Gibt Fälle, da sind GUIs prima, klar! Aber
man muss dran denken, dass das nur Standardfälle (Ausnahmen) abdeckt -
mehr nicht. Es hat keinen allgemeinen Character.

> Das geht mir deshalb so, weil ich oft, wenn ich mich frage, wie dies
> und jenes gemacht wird, und dann für so einen Fall ein fertiges
> Anwendungsbeispiel sehe, einige Bestandteile des Befehls, bzw. warum
> man es soundso machen muss, schon kenne/verstanden habe (und zudem
> anhand von Beispielen IMHO besser lerne) und daher nur selektiv dort
> nachhaken möchte, wo ich etwas noch nicht weiß/kenne. So kommt der
> "Aha"-Effekt meiner Meinung nach schneller zustande, wenn man sich nur
> das wissen aneignen/lesen muss, was man noch nicht weiß/kennt.

Na ja, das ist sicherlich alles richtig, normal und gängig, klar, aber
es gibt ja extrem viele Anwendungsbeispiele. Ein paar einfache sind
vielleicht häufig zu finden, aber es gibt auch sehr viele, die jeder nur
einemal im Jahr oder weniger oft benutzt :-) Da kann man kaum einen
Index machen, weil jeder ein bisschen was anderes macht. Das System
passt sich an den Benutzer an (im Gegensatz zu GUIs, wo sich der
Benutzer ans System anpassen muss, obwohl die GUIs genau das Gegenteil
behaupten :-)).

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.