[linux-l] Re: find -> updatedb+locate

[Sven Guckes]

* Detlef Lechner <Detlef.Lechner at gmx.net> [2006-12-11 22:39]:
> Am Montag, den 11.12.2006, 16:00 +0100 schrieb Sven Guckes:
> > du laesst "find" beim root verzeichnis beginnen -
> > und dann muss es das ganze dateisystem durchsuchen.
> > ist das nicht ein wenig zu viel?
>
> Ja, nach Möglichkeit schränkt man die Suche im Dateibaum
> gleich zu Beginn ein. Dann braucht das Programm
> nicht so viel zu suchen und wird schneller fertig.

genau das war mein vorschlag :-)

> Als Anfänger habe ich aber nicht denselben Überblick
> wie ein Fortgeschrittener. Der weiß eventuell schon:
> "Das kann sich nur in einem
>  Unterverzeichnis von /usr befinden."

genau - fortgeschrittene wissen mehr.
im wissen liegt der unterschied,
der "forgeschritten" impliziert.

> > wenn du aber nur ein programm suchst,
> > dann sollte es in $PATH zu finden sein,
>
> Ist das eine unumstößliche Regel?

nein.  programme koennen natuerlich *irgendwo* liegen.
so wie alle dateien irgendwo abgelegt sein koennen.
die meisten installationsprogramme werden jedoch programme
in einem der ueblichen verzeichnisse ablegen.

> Wie mir zu Ohren gekommen ist, halten sich die
> Linuxer ja nicht einmal an den File-System-Standard.

welchen der standards meinst du denn?  (achtung: trickfrage!) :-P

> > dh in einer liste von verzeichnissen.
> > wenn man "find" auf $PATH beschraenkt, dann
> > sollten hierbei auch schnellere ergebnisse
> > kommen als bei einer suche ueber "alles".
>
> Klar. Nur bin ich nicht immer sicher,
> daß die Datei sich im $PATH befinden muß.

sicherheit kannste eh nicht kaufen - mit *keinem* system.

> > fuer die suche nach ausfuehrbaren dateien
> > im $PATH gibt es ein eigenes programm: which
>
> Bei Debian und Ubuntu heißt es jedenfalls 'which'.

naja.. ob eine "which" zum ausfuehren gefinden wird,
das haengt halt von der shell ab, die du benutzt.
ash, bash, csh, dish, ksh, pdksh, rc,
sh, tcsh, zsh - such dir eine aus!

> > bei einigen shells ist dies sogar eine eigene, dh
> > interne funktion (heisst manchmal auch "whence").
> >
> > die namen im $PATH werden sogar ge-hash-t, so dass
> > praefixe mittels tab vervollstaendigt werden koennen.
> > also einfach zB mal "w" und danach ein TAB eingaben.
>
> Die Dateinamenvervollständigung mittels
> der Tab-Taste benutze ich zunehmend häufig.

und wenn man die richige shell nimmt, dann kann man nicht
nur dateien und verzechnisnamen mit tab vervollstendigen..

> > > > >Das geht bei mir unter Windows_XP schneller.
> > > > Ich möchte mal behaupten, dass in einer typischen Windows-Installation
> > > > um Größenordnungen weniger Files da sind
> > > Eine Größenordnung ist der Faktor 10. Bei mir ist der
> > > Faktor vielleicht 10, auch wenn mein Linux-System noch
> > > nicht so weit ausgebaut ist wie mein Windows-Rechner.
> >
> > faktor 10?  hast du das gemessen?  oder lediglich "gefuehlt"?
>
> Gefühlt.
> Unter den hier vorliegenden Umständen
> lohnt es sich nicht zu messen.

dabei koennte das so einfach sein:
    time kommando

aber wenn es die eingabe von "time" nicht lohnt,
warum ist dieser thread so lang?  hmm...  ;-)

> Bis jetzt gilt bei mir aber meist: Wenn ich unter Windows mit den
> windowseigenen Werkzeugen eine Datei suche und diese Werkzeuge mir
> melden, daß die Datei nicht da sei, dann ist sie nicht da. Wenn ich
> unter Linux mit linuxeigenen Werkzeugen eine Datei suche und die
> Werkzeuge melden mir, die Datei sei nicht da, dann bin ich nicht
> sicher, ob sie sich nicht irgendwo doch noch versteckt hat.

komisch - meiner erfahrung nach ist das genau umgekehrt.

> > meine loesung:
> > die dateien in meinem $HOME indiziere ich mit "updatedb"
> > und suche dann in diesem index mittels "locate".
> > die erstellung des index dauerte  16 sekunden,
> > die ermittlung aller eintraege ca 18 sekunden.
> > und das fuer 400,000+ eintraege in ca 4.1MB.
> > damit kann ich leben. :-)
>
> Damit könnte ich auch leben. Aber ich weiß noch nicht so richtig,
> welche Dateien mir außerhalb von $PATH durch die Lappen gehen.

nun, genau genommen gilt meine loesung ja auch
nicht fuer dateien ausserhalb meines $HOME.
aber natuerlich koenntest du auch eine dateiliste
mittels locate fuer das gesamte dateisystem anlegen.
und "cron" ist dein freund.

> Nach dem (schlechten) Debian-Buch, das ich habe, aktualisiert
> updatedb die Datenbank aller Dateien des Systems.
> Wie schränkst Du diesen Bereich auf den Bereich $PATH ein?

da steht es:

> > $ which updb
> > updb () { updatedb -U "$HOME" -o $HOME/.locatedb }

also mit "-U $HOME".  das "-U" steht
dabei vielleicht fuer "update path".
aber solche gedaechtnisstuetzen werden ja
in manuals aus tradition nicht eingebaut.

> Ich habe Deine Kommandos/Programme am Ende nicht verstanden.
> Ich habe die Syntax und Semantik davon noch zuwenig studiert.

dann werde ich es mal ein wenig erklaeren:

> > $ date; updb; date
> > Mon Dec 11 15:33:32 CET 2006
> > Mon Dec 11 15:33:48 CET 2006

mit "updb" mache ich den update.  und
diese funktion ist ja oben beschrieben.
das "date" davor bzw danach zeigt lediglich
die zeit vor dem aufruf bzw nach dem aufruf an.
natuerlich haette ich auch "time" benutzen koennen:

    time ( updb )

> > $ ls -l ~/.locatedb
> > -rw------- 1 guckes wwwuser 4.1M Dec 11 15:33 .locatedb

hier sieht man lediglich wie viele daten als index erzeugt wurden.

> > $ time ( locate -d ~/.locatedb . | wc -l )
> > 407002
> > (; locate -d ~/.locatedb . | wc -l; )  1.32s user 8.88s system 56% cpu 17.915 total

hierbei suche ich mit "locate" nach "." - also
nach eintraegen, die mindestens ein zeichen haben.
das sollte alle eintraege erwischen.  die ausgabe
kommt als eine menge von zeilen, die
dann mittels "wc -l" gezaehlt werden.
da dauert bei dieser menge ein bischen
so dass das "time" drumrum diese misst.

und diese konzepte erklaert dir sicherlich jemand:
alias + function
command1 ; command2
command1 | command2
time ( command )

eventuell steht auch in deinem "schlechten"
debian-buch etwas darueber drin, siehe "shell".

Sven