On Fri, 10 Jan 2003, Bernd Brodesser wrote:
* David Haller schrieb am 09.Jan.2003:
Interessanter ist wohl, was sich im aktuellen Verz. rumtreibt, besonders wenn (lass mich raten) du '.' im PATH drin hast! Falls ja, nimm das mal raus! ('.' gehoert IMHO sowieso nicht in $PATH ;)
Kleine Anmerkung dazu:
Der . ist Default. Das heißt, wenn in einem Feld kein Eintrag steht, so ist es so, als stände da . Wenn PATH etwa am Anfang so aussieht:
:/usr/local/bin:/usr/bin:/bin
Dann wird als erstest . gewählt, weil PATH mit einem : anfängt und somit hier nicht mit /usr/local/bin anfängt, sondern mit einem leeren Feld. [...]
Ich schaetz jetzt einfach mal, dass das so aehnlich ist wie z. B. mit find. Wenn ich ein find / -name "*e*" 2>/dev/null eingebe dauert das das erste Mal recht lang bis die Ergebnisse zurueckkommen. Geb ich kurz darauf nochmal das selbe ein sind die Ergebnisse sofort da. Also nehm ich an, dass sich das find einen sortierten Puffer, Ergebnispuffer oder weiss der Geier was zulegt, in dem dann erst einmal nochmal nachgeschaut wird, ob da vielleicht schon Ergebnisse vorhanden sind. Ja - der Puffer existiert aber nur eine bestimmte Zeit. Dannach wird er wieder geloescht. Kommt dann mal wieder ein find muss auch wieder die ganze Platte durchsucht werden. Und das dauert wieder. Ja und wenn jetzt bei Ratti tonnenweise Dateien im Pfad enthalten sind, dauert es auch entsprechend lang. Na ja, ist nur so eine Vermutung. Da muesste man halt wissen wie die Autocompletion arbeitet. Hein(wennDerWinterNurNichtSoFaulMachenWuerde)rich