Hallo, On Tue, 07 Jan 2003, Thorsten Haude wrote:

...

Wenn ich in einer leeren Zeile TAB-TAB drücke, "droht" er mir mit "2233 possibilities", was ja nun wirklich normal ist.

Ätsch, ich habe mehr: yooden@eumel> zsh: do you wish to see all 2824 possibilities (942 lines)?

dh@slarty[3]:~ (0)$ Display all 3546 possibilities? (y or n) -dnh --

Ah. Roter Kringel in den Kalender, Felix hat gerade einen Fehler zugegeben. ? Wie, ich? Fehler zugeben? Das muß ein Mißverständnis sein ;) -- Uwe Ohse und fefe in dasr

Thorsten Haude wrote:

* David Haller [2003-01-07 04:21]:

...

dh@slarty[3]:~ (0)$ Display all 3546 possibilities? (y or n)

Pah, wär doch gelacht: yooden@eumel> perl -e 'foreach $i (1..1000){system("echo \"echo \\\"Hallo David\\\"\" > $i; chmod u+x $i")}' yooden@eumel> zsh: do you wish to see all 3776 possibilities (1259 lines)?

Was habt ihr da eigentlich fuer Probleme? $> TAB TAB Display all 4075 possibilities? (y or n) $> *grins* Th. PS: Frauen sagen jetzt: "Typisches Maennergehabe". Wie recht sie damit haben... ;-) -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)

Hallo, On Tue, 07 Jan 2003, Thomas Hertweck wrote:

Thorsten Haude wrote:

...

* David Haller [2003-01-07 04:21]:

...

dh@slarty[3]:~ (0)$ Display all 3546 possibilities? (y or n)

Pah, wär doch gelacht: yooden@eumel> perl -e 'foreach $i (1..1000){system("echo \"echo \\\"Hallo David\\\"\" > $i; chmod u+x $i")}' yooden@eumel> zsh: do you wish to see all 3776 possibilities (1259 lines)?

Was habt ihr da eigentlich fuer Probleme? $> TAB TAB Display all 4075 possibilities? (y or n) $>

*grins*

*g* Geh ich richtig in der Annahme, dass das bei dir auch "echte" Programme/Scripte sind?

PS: Frauen sagen jetzt: "Typisches Maennergehabe". Wie recht sie damit haben... ;-)

Ja. "Und weiter im Text...": $ df -i | awk '/^[^F]/{s+=$3}END{printf s"\n"}' 1210835 $ df | awk '/^[^F]/{s+=$3}END{printf s"\n"}' 74059256 *scnr* -dnh PS: fast interessanter[1] finde ich uebrigens, wie man an solche Infos herankommt... Gibt's dafuer unter Win* eigentlich nen Dialog oder so? ;) Oder muesste man sich die (vorhandenen) Daten einzeln von den "Eigenschaftenseiten" der (bei mir 9) Partitionen/Laufwerke einzeln abschreiben/-tippen und addieren? *harrupmf* [1] und deswegen mache ich in dem Thread noch weiter -- 17: Vollkompatibel zur Datenautobahn Gerät verfügt über eine serielle Schnittstelle. (Peter Berlich)

Am Dienstag, 7. Januar 2003 11:59 schrieb David Haller:

PS: fast interessanter[1] finde ich uebrigens, wie man an solche Infos herankommt... Gibt's dafuer unter Win* eigentlich nen Dialog oder so? ;) Oder muesste man sich die (vorhandenen) Daten einzeln von den "Eigenschaftenseiten" der (bei mir 9) Partitionen/Laufwerke einzeln abschreiben/-tippen und addieren? *harrupmf*

Hey, für sowas hat Gott (unter Win ist das IMHO Gates) die Tabellenkalkulationen (=Excel) erfunden (und mir kommt jetzt keiner und sage die Tabellenkalkulation, das Internet und der Computer an sich wären keine Erfindung Microsofts, na egal, mit Paladium werden Texte die sowas behaupten dann eh automatisch gelöscht). Da schreibt man dann die einzelnen ermittelten Werte rein und kann sich mit der Summen-Funktion die Gesamtzahl ausrechnen lassen. Dass nennt man dann Automatisierung und Arbeitszeitersparnis. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de

Christian Boltz wrote:

Am Dienstag, 7. Januar 2003 11:59 schrieb David Haller:

...

PS: fast interessanter[1] finde ich uebrigens, wie man an solche Infos herankommt... Gibt's dafuer unter Win* eigentlich nen Dialog oder so? ;) Oder muesste man sich die (vorhandenen) Daten einzeln von den "Eigenschaftenseiten" der (bei mir 9) Partitionen/Laufwerke einzeln abschreiben/-tippen und addieren? *harrupmf*

Nicht ganz, Du brauchst dazu wohl nur 3 Durchläufe [1]:

LogoKey+F

Suchen nach *.exe in Arbeitsplatz Suchen nach *.com in Arbeitsplatz Suchen nach *.bat in Arbeitsplatz und dann natürlich die Anzahl der Suchergebnisse zusammenzählen.

und noch ne ganze menge mehr Extensionen hinzufuegen und alles per Semikolon trennen, dann zaehlt auch der Explorer fuer dich die Ergebnisse zusammen. Peter

Tach, Christian Boltz schrieb:

Am Dienstag, 7. Januar 2003 11:59 schrieb David Haller:

...

PS: fast interessanter[1] finde ich uebrigens, wie man an solche Infos herankommt... Gibt's dafuer unter Win* eigentlich nen Dialog oder so? ;) Oder muesste man sich die (vorhandenen) Daten einzeln von den "Eigenschaftenseiten" der (bei mir 9) Partitionen/Laufwerke einzeln abschreiben/-tippen und addieren? *harrupmf*

Nicht ganz, Du brauchst dazu wohl nur 3 Durchläufe [1]: Suchen nach *.exe in Arbeitsplatz Suchen nach *.com in Arbeitsplatz Suchen nach *.bat in Arbeitsplatz

Hmm, man kann aber in einem Suchlauf eine ODER-Verknüpfung verwenden. Das habe ich vor langer Zeit mal gemacht, um mir in einem Suchlauf alle Schrott-Dateien (*.tmp, *.bak, *.sav usw) suchen zu lassen, damit ich die alle in einem Rutsch löschen kann. Fragt mich aber nicht mehr, wie das genau ging. Ich glaube, man verwendet als Trenner ein Semikolon: *.exe;*.com;*.bat Oder so ähnlich. Die Outlook-Schreiberlinge hier dürften das eher ausprobieren können, als ich (wann komme ich mal an eine Windows- Kiste) und uns ggf. schreiben, wie das richtig geht. Wie gesagt, ich habe das mit dem Semikolon im Hinterkopf... Gruß, Patrick

Hallo, On Tue, 07 Jan 2003, Thorsten Haude wrote:

* David Haller [2003-01-07 04:21]:

...

Hallo,

On Tue, 07 Jan 2003, Thorsten Haude wrote:

...

...

Wenn ich in einer leeren Zeile TAB-TAB drücke, "droht" er mir mit "2233 possibilities", was ja nun wirklich normal ist.

Ätsch, ich habe mehr: yooden@eumel> zsh: do you wish to see all 2824 possibilities (942 lines)?

dh@slarty[3]:~ (0)$ Display all 3546 possibilities? (y or n)

Pah, wär doch gelacht: yooden@eumel> perl -e 'foreach $i (1..1000){system("echo \"echo \\\"Hallo David\\\"\" > $i; chmod u+x $i")}' yooden@eumel> zsh: do you wish to see all 3776 possibilities (1259 lines)?

Poeh. Schwach. dh@slarty[0]:/tmp/test/awkloop (0)$ PATH=".:$PATH" dh@slarty[0]:/tmp/test/awkloop (0)$ time for i in `seq 0 1000`; do echo 'echo "Hallo Thorsten!"' > $i; done; chmod u+x * real 0m0.262s user 0m0.100s sys 0m0.150s dh@slarty[0]:/tmp/test/awkloop (0)$ ./666 Hallo Thorsten! dh@slarty[0]:/tmp/test/awkloop (0)$ <tab><tab> Display all 4546 possibilities? (y or n)<n> dh@slarty[0]:/tmp/test/awkloop (0)$ rm * dh@slarty[0]:/tmp/test/awkloop (0)$ time for i in `seq 0 10000`; do echo 'echo "Hallo Thorsten!"' > $i; done; chmod u+x * real 0m5.942s user 0m1.210s sys 0m4.700s dh@slarty[0]:/tmp/test/awkloop (0)$ <tab><tab> Display all 13547 possibilities? (y or n)<n> dh@slarty[0]:/tmp/test/awkloop (0)$ rm * dh@slarty[0]:/tmp/test/awkloop (0)$ time awk 'BEGIN{i=0;while(i<1000){ printf"echo \"Hallo Thorsten!\"\n">i;i+=1;}}'; chmod u+x * real 0m0.263s user 0m0.080s sys 0m0.180s dh@slarty[0]:/tmp/test/awkloop (0)$ rm * dh@slarty[0]:/tmp/test/awkloop (0)$ time awk 'BEGIN{i=0;while(i<10000){ printf"echo \"Hallo Thorsten!\"\n">i;i+=1;}}'; chmod u+x * real 0m28.433s user 0m21.240s sys 0m6.820s dh@slarty[0]:/tmp/test/awkloop (0)$ rm * dh@slarty[0]:/tmp/test/awkloop (0)$ time awk 'BEGIN{i=0;while(i<1000){ printf"echo \"Hallo Thorsten!\"\n">i;i+=1;}system("chmod u+x *");}' real 0m0.363s user 0m0.090s sys 0m0.260s dh@slarty[0]:/tmp/test/awkloop (0)$ rm * dh@slarty[0]:/tmp/test/awkloop (0)$ time awk 'BEGIN{i=0;while(i<10000){ printf"echo \"Hallo Thorsten!\"\n">i;i+=1;}system("chmod u+x *");}' real 0m29.157s user 0m22.010s sys 0m6.750s dh@slarty[0]:/tmp/test/awkloop (0)$ rm * dh@slarty[0]:/tmp/test/awkloop (0)$ time perl -e 'foreach(1..1000){ system("echo \"echo \\\"Hallo David\\\"\" > $_; chmod u+x $_")}' real 0m18.428s user 0m9.210s sys 0m9.150s dh@slarty[0]:/tmp/test/awkloop (0)$ rm * dh@slarty[0]:/tmp/test/awkloop (0)$ time perl -e 'foreach(1..10000){ system("echo \"echo \\\"Hallo David\\\"\" > $_; chmod u+x $_")}' real 3m8.901s user 1m34.230s sys 1m34.040s dh@slarty[0]:/tmp/test/awkloop (0)$ PATH="${PATH//#.:/}" dh@slarty[0]:/tmp/test/awkloop (0)$ <tab><tab> Display all 3546 possibilities? (y or n)<n> dh@slarty[0]:/tmp/test/awkloop (0)$ rm * dh@slarty[0]:/tmp/test/awkloop (0)$ *tsktsk* Da faellt mir doch glatt nur noch eine Signatur ein (s.u.)... -dn'*scnr*'h PS: man achte auf die "user"-Zeiten! -- Wenn man nur einen Hammer als Werkzeug hat, sieht jedes Problem aus wie ein Nagel.

Am Dienstag, 7. Januar 2003 04:21 schrieb David Haller:

Hallo,

On Tue, 07 Jan 2003, Thorsten Haude wrote:

...

...

Wenn ich in einer leeren Zeile TAB-TAB drücke, "droht" er mir mit "2233 possibilities", was ja nun wirklich normal ist.

Ätsch, ich habe mehr: yooden@eumel> zsh: do you wish to see all 2824 possibilities (942 lines)?

dh@slarty[3]:~ (0)$ Display all 3546 possibilities? (y or n)

-dnh [1125][Up: 29 min][Load: 2.36][lemmy@bombadil:~]$ Display all 3660 possibilities? (y or n)

bye [MH]

Moin, Am Die, 2003-01-07 um 12.35 schrieb Heinrich Kuespert:

On 7 Jan 2003, [ISO-8859-1] Jörg Roßdeutscher wrote:

...

Wenn ich in einer leeren Zeile TAB-TAB drücke, "droht" er mir mit "2233 possibilities", was ja nun wirklich normal ist.

Da ja nun alle viel Spaß an meinem Problem haben - wer toppt: " Do you wish to see all Overflow Error " :-) Im Ernst:

Gelegentlich ist, siehe Betreff, die Autocompletion in der bash bei mir

...

superlangsam. Sprich: ich tippe "mou", drücke TAB-TAB, und es dauert

Kenn ich auch. Manchmal dauert die Ausgabe eines Kommandos ewig (bis zu einer Minute oder so). Kommt mir fast so vor als ob da das System manchmal so vor sich hintraeumt und in Ruhe gelassen werden will! Ha ha. Der Effekt wuerde mich von daher auch interessieren. Ich verwende allerdings kein reiser sondern ext3.

Dann isses also wohl nicht reiserfs. Bleibt die wohl ungewöhnliche Anzahl von gut 2 Mio. Files im Dateisystem - liegt es vielleicht irgendwie daran, daß die autocompletion so schnarchig werden kann? Nervt irgendwie. Gruß, Ratti -- fontlinge Fontmanagement for Linux http://www.gesindel.de Schriftenverwaltung fuer Linux

* 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. Ebenso am Ende, wenn PATH etwa so aussieht: /opt/kde/bin:/opt/gnome/bin: so steht am Ende noch ein Feld, nach dem : Da es leer ist, wird hier ein . hingesetzt. Auch in der Mitte ist dies möglich: /usr/local/bin:/usr/bin::/usr/X11R6/bin:/bin Hier stehen zwei :: hintereinander. Das leere Feld dazwichen wird . gesetzt. Also besonders darauf achten, daß kein : am Anfang oder Ende steht, und auch keine zwei :: hintereinander. Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4

Hallo, On Fri, 10 Jan 2003, Heinrich Kuespert wrote:

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. [...]

Jep. Zu ueberpruefen mit: dh@slarty[0]:~ (0)$ echo "$PATH" | grep '^:\|:$\|::' dh@slarty[0]:~ (1)$ [in den () steht $?, also der Exitstatus des letzten Befehls ;)]

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,

AFAIK nein! Was sich da bemerkbar macht ist der Platten-Cache. Das gleiche findest du z.B. bei ls -U... -dnh -- Denn drinnen war noch ne Ente. Äh! Die Füllung ist aber Zusammengbraten. Macht nix! Wird auch veroputzt. (Mampf, Schlürf, Schmatz,) *umdrehundwegguck* BRÖÖÖÖÖÖHHHHH! Der musste Raus! [WoKo in dag°]

Hallo, On Fri, 10 Jan 2003, Heinrich Kuespert wrote:

On Fri, 10 Jan 2003, David Haller wrote:

...

On Fri, 10 Jan 2003, Heinrich Kuespert wrote:

...

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, ^^^^ ^^^^ ^^^^^^^^^^^^^^^^ AFAIK nein! Was sich da bemerkbar macht ist der Platten-Cache. Das gleiche findest du z.B. bei ls -U...

Ja ok, aber das ist ja eigentlich kupft wie gschprunga, ob $Speicher logischer Speicher auf Festplatte, Fesplattencache oder RAM ist. Also rein theoretisch ist das doch das selbe.

Nein ;)) Naja, Puffer der Festplattendaten im RAM, ja. Soweit richtig.

Feststehen tut doch, dass zwischengespeichert wird.

Jep.

Wenn ich das erste Mal auf TAB druecke, findet auf jeden Fall Festplattenaktivitaet statt. [..]

Jep. Es ist aber ein Unterschied, ob "nur" vom Kernel (generell) Festplatten/FS-Daten im (freien) RAM zwischengespeichert werden (was der Fall ist), oder ob find eine (sortierten) eigenen Puffer vorhaelt. Klar, von der Geschwindigkeit ist RAM-Puffer gleich RAM-Puffer, und in den meisten Faellen schnell genug, zumindeest mit dem "sortiert" hast du aber zuviel impliziert ;) -dnh, meist 150-200MB im HDD-Cache habend *g* -- "But you've got to hand it to IBM, they know how to design hardware. The servers all had handles to pick them up and throw them out of the window...." --Juergen Nieveler in the Monastery

* Heinrich Kuespert schrieb am 10.Jan.2003:

On Fri, 10 Jan 2003, David Haller wrote:

...

AFAIK nein! Was sich da bemerkbar macht ist der Platten-Cache. Das gleiche findest du z.B. bei ls -U...

Ja ok, aber das ist ja eigentlich kupft wie gschprunga, ob $Speicher logischer Speicher auf Festplatte, Fesplattencache oder RAM ist. Also rein theoretisch ist das doch das selbe.

Nicht ganz. Die Zugriffszeit auf Hauptspeicher ist Millionenfach schneller aus die mittlere Zugriffszeit auf Festplatte.

Feststehen tut doch, dass zwischengespeichert wird.

Das macht aber der Kernel. Und ihm ist es vollkommen egal, was für Daten das sind. Das macht er immer und bei jeder Anwendung. Ob Du eine Datei liest, ein Lied abspielst, oder was auch sonst, es wird Zwichengespeichert. Die Anwendung gibt da keinen Speziellen Befehl heraus, und weiß auch nichts davon. Wenn der Cache eng wird, wird halt nicht Zwichengespeichert, die Anwendung läuft haargenauso ab, als würde abgespeichert, es dauert nur länger.

Wenn ich das erste Mal auf TAB druecke, findet auf jeden Fall Festplattenaktivitaet statt. Also heisst das fuer mich, dass alle moeglichen Kommandos im Pfad ausfindig gemacht werden und irgendwohin eingelagert werden. Drueck ich dann nochmal auf TAB findet keine Plattenaktivitaet mehr statt und mir werden gleich alle moeglichen possibilities angeboten.

Das macht der Kernel ganz selbstständig, ohne das man ihm was sagt. Nicht vergessen Linux ist ein Mehrbenutzersystem. Da ist es immer von Vorteil, wenn viele User irgendwas gleichzeitig machen, die Dateien, die immer wieder gebraucht werden zwichenzuspeiechern. So richtig zur Geltung kommt das alles erst, wenn tatsächlich mehere User gleichzeitig an einem Rechner arbeiten. Aber auch wenn man alleine ist, hat es schon Vorteile.

Ja und ob jetzt nach einer halben Stunde oder so nach einem erneutem Druecken auf TAB (oder nach Eingabe von mou und TAB TAB) wieder die Platte durchsucht wird, hab ich jetzt noch nicht getestet.

Kommt darauf an, ob der Cache zwichenzeitlich anderswertig gebraucht wurde. Sei es als Cache für andere Dateien, sei es als Speicher für Anwendungen. Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12

* Heinrich Kuespert schrieb am 11.Jan.2003:

On Sat, 11 Jan 2003, Bernd Brodesser wrote:

...

Das macht aber der Kernel. Und ihm ist es vollkommen egal, was für Daten das sind. Das macht er immer und bei jeder Anwendung. Ob Du eine Datei liest, ein Lied abspielst, oder was auch sonst, es wird Zwichengespeichert. Die Anwendung gibt da keinen Speziellen Befehl heraus, und weiß auch nichts davon. Wenn der Cache eng wird, wird halt nicht Zwichengespeichert,

sondern?

Verworfen.

...

die Anwendung läuft haargenauso ab, als würde abgespeichert, es dauert nur länger.

Wie, was jetzt? Zwischengespeichert oder abgespeichert. Also wir sind jetzt bei dem Fall lesen, abspielen, suchen oder so, aber nicht Datei abspeichern - oder?

Ok, hast ja Recht. Dann wird es halt einfach verworfen und der Speicherplatz im Hauptspeicher für was anderes verbraucht. Wenn es wieder gebraucht wird, dann wird halt wieder von Platte gelesen. Wichtig ist, daß das Anwendungsprogramm davon nichts mitbekommt. Es sagt, ich möchte die und die Datei lesen. Ob der Kernel dies nun von Festplatte macht, oder vom Hauptspeicher, weil es da zufälligerweise noch rumliegt, ist dem Anwendungsprogramm egal. Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4

Hallo, On Sun, 12 Jan 2003, Jörg Roßdeutscher wrote:

Am Don, 2003-01-09 um 23.40 schrieb David Haller:

...

On Thu, 09 Jan 2003, Jörg Roßdeutscher wrote:

...

Dann isses also wohl nicht reiserfs. Bleibt die wohl ungewöhnliche Anzahl von gut 2 Mio. Files im Dateisystem Naja... $ df -i | awk '{printf $3" "}END{printf"\n";}' IUsed 8684 79652 252352 204540 93500 8368 62736 45226 468124

Hmmm... Verstehe ich nicht, sagt bei mir IBenut. 0 35 0 0 0 0 1 0 0

Überhaupt finde ich die Ausgabe von df -i komisch:

ratti:/ # df -i Dateisystem INodes IBenut. IFrei IBen% Eingehängt auf /dev/hda3 4294967295 0 4294967295 0% / /dev/hda1 3280 35 3245 2% /boot /dev/hde3 4294967295 0 4294967295 0% /disk1 /dev/hdg1 4294967295 0 4294967295 0% /disk2 /dev/hdf1 0 0 0 - /windows/C /dev/hdf5 0 0 0 - /windows/D shmfs 48185 1 48184 1% /dev/shm server:/home/ratti 4294967295 0 4294967295 0% /home/ratti/server server:/home/suse/mount 0 0 0 - /suse

Da steht ja immer 4294967295, bei Frei und Vergeben, also ist nix vergeben?

Achso. Du verwendest (ausser auf /boot) reiserfs. Da kannst du das in die Tonne treten.

...

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 ;)

Ne, weil das ein rumdoktern an Symptomen wäre.

Nein. Das waere die Ursache (AFAIK)! Denn die bash muss ja alle ausfuehrbaren Dateien im Pfad "kennen", um zu ergaenzen. Und wenn "." im PATH ist und gerade ein "dickes" Verzeichnis ist, dann muss die bash "mal eben" _alle_ Dateien dort (10000e?) darauf testen, ob sie ausfuehrbar sind, und wenn ja, in die Liste der Befehle mit aufnehmen -- und da sich "." ja oft aendert laesst sich das auch nicht sinnvoll zwischenspeichern -- ausser im normalen HDD-Cache, der generell alle HDD-Inhalte zwischenspeichert. Und nach dem naechsten 'cd'+<tab><tab> muss die bash das Spielchen wiederholen... Du verstehst wo das Problem liegt? Sagen wir, du hast in allen Verz. ausser '.' 2000 ausfuehrbare Dateien -- die kann die bash, da statisch, gut zwischenspeichern... Aber mit den evtl. ein paar 10000 Dateien in '.' geht das eben nicht...

Diese Pause darf einfach nicht sein, und ich will wissen, wo die Macke im System ist.

s.o.

Ich habe mir zwar ./befehl angewöhnt, auch wenn . bei Suse bei "Normalusern" im Pfad ist, Trotzdem darf in einem normalen Verzeichnis keine mehrsekündige Verzögerung auftreten.

s.o.

Trotzdem ist die Idee gut. Ich werde jetzt mal drauf achten, ob die Pause bei Vervollständigung von Befehlen, die im Pfad liegen, auftritt, oder auch bei Dateinamen aus dem aktuellen Verzeichnis.

Nein, da verstehst du jetzt falsch, wie die Expansion/Completion der bash funktioniert... (s.o.) -dnh -- Früher durften nur Docktoren ins Usernetz. Als das Netz dann klüger wurde, sind die Docktoren nicht mehr so oft dort gesehen worden. [WoKo in dag°]