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

[Sven Guckes]

* Detlef Lechner <Detlef.Lechner at gmx.net> [2006-12-12 12:25]:
> Am Dienstag, den 12.12.2006, 01:13 +0100 schrieb Sven Guckes:
> > > > 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.
>
> Manchmal braucht man aber Gewißheit.
> Ganz besonders in der digitalen Welt.
> Sonst funktioniert manches nicht.

"duh!"

> Z. B. einen Befehl nur ein ganz klein wenig anders
> eingeben bewirkt, daß er nicht mehr funktioniert.

warum sollten befehle nach einer aenderung auch
noch genauso funktionieren?  verstehe ich nicht.

ich glaube hier ist wieder einmal
das GIGO prinzip anwendbar:
http://catb.org/jargon/html/G/GIGO.html

> > > 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
>
> Ich sehe nur, daß manche Linuxer auf den 'File System Standard'
> hinweisen und trotzdem manche Distributionen Dateien mit ähnlicher
> Funktion in unterschiedlichen Verzeichnissen plazieren.
> Meines Erachtens können in diesem Fall die Linuxer
> die Schuld nicht auf Microsoft schieben.

nun, es gibt mehrere sichtweisen fuer ein "perfektes dateisystem" -
darum gibt es auch mehrere dateisysteme.  das ist offensichtlich.

das ist aber die technische seite der dateisysteme.
die einteilung in verzeichnisse und deren namen
sind bei allen systemen unterschiedlich verlaufen.
darum gibt es leider auch keinen brauchbaren konsens.

bisher hat M$ keine anderen dateisysteme benutzt oder
unterstuetzt.  und dafuer *verdienen* sie schelte!

> > > > 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.
>
> Na ja. Man benötigt schon manchmal die Gewißheit, daß das Programm
> xyz sich nicht oder doch auf dem eigenen System befindet.

bisher konnte ich mir bei den freien systemen immer recht
sicher sein, dass eine angabe zum dateisystem auch stimmt.
bei $windows ist das nicht immer der fall.  das uebersieht
die suche  gerne mal "versteckte" dateien..

> > > > 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!
>
> Ich suche mir keine aus. Debian und Ubuntu haben sich
> für bash als Default entschieden. Dabei bleibe ich.

"which" ist bei bash aber keine interne funktion,
dh es kann auch keine internen alias oder funktionen
der bash erkennen, obwohl nach eingabe einer zeile jene
zuerst die aliase bzw funktionen ueberprueft werden.

darum kann ein "which foo" dir ein "/usr/bin/foo" liefern - aber wenn
du "foo" eingibst, dann schlaegt ein alias bzw eine funktion zu. :-P

diese ueberraschung bin ich zwar bei der
bash "gewohnt", aber ich mag sie nicht.
da lobe ich mir das "whence" in der zsh, denn das
kann aliase und funktionen zur laufzeit erkennen.

> Vor diversen Jahren wollte/sollte ich aus dienstlichen Gründen mich
> in Unix vertiefen. Da wurde dauernd zwischen drei Shells hin-
> und hergesprungen. Das erschwerte den Lernerfolg ungemein.
> Standardisierung und Unifizierung hat ihre Vorteile.

nur lernt dann der eine den einen standard - und der andere den
anderen.  und beide sind dann der meinung *die* shell zu koennen.
"the one and only true shell".  fatal!

kein tool ist perfekt.  selbst bei einer "perfekten"
implementation eines referenz-modells eines standards
gibt es immer wieder wuensche fuer neues.

darum wird auch weiterhin entwickelt und geaendert.
natuerlich bewegt man sich dann vom standard weg.

gluecklich ist, wer die probleme versteht, die zu
neuen features und zu neuen loesungen fuehren.
denn entweder wird es schneller, weniger unsicher
(halte ich besser als die beschreibung "sicherer")
oder einfach besser zu verstehen und zu merken.

natuerlich kann man versuchen sine loesungen mit
den features aus dem letzten jahrtausend jeweils
neu zu erschaffen, damit man "kompatibel" bleibt.
das hat auch seine berechtigung.  allerdings muss
man sich auch fragen wie lange es dauert, bis
man auf diesem wege zu ergebnissen kommt.

> > und wenn man die richige shell nimmt, dann kann man nicht
> > nur dateien und verzechnisnamen mit tab vervollstaendigen..
>
> Die bash mit ihrem Funktionsangebot reicht mir fürs nächste Jahr aus.

eine woche crashkurs sollte ausreichen ;)

> > > > > > >Das geht bei mir unter Windows_XP schneller.
> > > > > Eine Größenordnung ist der Faktor 10.
> > > > > Bei mir ist der Faktor vielleicht 10..
> > > > faktor 10?  hast du das gemessen?  oder lediglich "gefuehlt"?
> > > Gefühlt.  .. lohnt sich nicht zu messen.
> > dabei koennte das so einfach sein: time kommando
>
> Ja, trotzdem lohnt es sich nicht. Man hat einen genauen Meßwert,
> aber die Umgebung ist wenig genau definiert und wandelt sich rasch.
> Man lernt wenig daraus für die Zukunft.

oh mann.. da gibt man dir ein tool an die hand, das geradezu *trivial*
in der anwendung ist - und du bist immer noch nicht zufrieden!

ich frage mich ernsthaft, ob du wirklich den dingen auf den grund gehen
willst, oder ob du lediglich versuchst dein "gefuehl" zu verteidigen.

wenn du lieber bei deinem gefuehl bleiben moechtest,
dann solltest du keine behauptungen aufstellen,
die du weder selber verifizieren willst,
noch von anderen widerlegt haben moechtest.

> > > Wie schränkst Du diesen Bereich auf den Bereich $PATH ein?
> > > > updb () { updatedb -U "$HOME" -o $HOME/.locatedb }
> > also mit "-U $HOME".
>
> Die Manpage für updatedb in meinem Debian listet keine Option '-U' auf.
> Hast Du ein anderes Programm updatedb als ich?

->  slocate

  $ slocate --help | grep -- -U
                           [-c <file>] <[-U <path>] [-u]>
     -U <dir>           - Create slocate database starting at path <dir>.
                          when using the -u or -U options.  If 'updatedb' is
                          using the -u or -U options.
                          when using the -u or -U options. (ie. NFS, etc).

tja.. *shrug*

Sven