Archiv verlassen und diese Seite im Standarddesign anzeigen : Autovervollständigen mit TAB Taste - Wie?
redfalcon
2010-11-26, 14:03:45
Das sollte eigentlich dort auch funktionieren. Guck mal in deiner ~/.bashrc ob da folgendes drin steht:
# enable programmable completion features
if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
. /etc/bash_completion
fi
Sonst reinkopieren und im Terminal source ~/.bashrc ausführen oder den Terminal neustarten.
iltis2k
2010-11-26, 14:17:12
Vielleicht hast du auch einfach nur mehrere Dateien oder Ordner die z.B. mit "3D" anfangen. Dann kannst du noch ein zweites mal die TAB Taste drückst und dir wird alles angezeigt was so anfängt.
iltis2k
2010-11-26, 14:35:51
Also ich bin in der Linux Welt auch noch recht neu, daher weiß ich jetzt auch nicht weiter. Du kannst es aber mal bei http://ubuntuusers.de/ probieren, falls du die Seite noch nicht kennst.
Tesseract
2010-11-26, 16:12:59
es funktioniert immer dann (bzw. sollte immer dann funktionieren), wenn es sinn macht.
mit cd ... gehen beispielsweise nur ordner weil du in eine datei nicht reinchangen kannst.
wenn allerdings ein programm einen dateipfad braucht, sollte das funzen.
wenn es mehrere mögliche treffer gibt kannst du 2x tab drücken um die möglichkeiten zu sehen.
Ist das Package bash-completion installiert?
redfalcon
2010-11-26, 19:29:56
Wie finde ich das heraus?
dpkg -s bash-completion | grep Status
sudo apt-get install bash-completion
redfalcon
2010-11-26, 20:36:53
Und nun?
bash-completion ist installiert.
Bist du dir sicher, dass du die Vervollständigung (wie Tesseract schon gesagt hat) im richtigen Kontext verwendest? Ohne Befehl voran kannst du keine Dateinamen vervollständigen. Wenn du aber z.B. mit nano oder vim eine Datei öffnen willst, sollte vim 3d[Tab] zu vim 3dcenterlogo.txt vervollständigt werden. Wenn mehrere Dateien mit 3d beginnen, musst du zweimal Tab drücken.
Dateinamen direkt kann man nur vervollständigen, wenn man ./ voranstellt (damit startet man ausführbare Dateien aus dem Terminal heraus, macht bei einem Bild natürlich keinen Sinn). Also ./3d sollte zur ./3dcenterlogo.jpg vervollständigt werden.
Und wenn du zweimal hintereinander TAB drückst (so wie doppelklick quasi)?
Was machen folgende Befehle:
$ ls -al
$ li<TAB><TAB>
Avalox
2010-11-26, 21:07:51
Ja, es funktioniert nicht.
Mal ein Beispiel:
Ich habe einen Ordner namens HalloOrdner und eine Datei machsgut.txt:
rm H[TAB] --> rm HalloOrdner/ (funktioniert perfekt)
rm m[TAB] --> nix passiert
rm ma[TAB] --> nix passiert
rm machs[TAB] --> nix passiert
Da stimmt was nicht.
Erstmal entfernt rm nur Ordner, wenn zumindest der Parameter -r angegeben ist.
Befindest du dich im unpassenden Verzeichnis, oder nutzt du eine alternative Shell?
Poste doch mal die Ausgaben von
l
und
echo $0
Tesseract
2010-11-27, 02:28:03
Erstmal entfernt rm nur Ordner, wenn zumindest der Parameter -r angegeben ist.
die autovervollständigung funktioniert aber trotzdem, rm spuckt dann nur einen fehler aus.
es geht sogar wenn man für die datei keine schreibrechte hat.
keine ahnung, eigentlich müsste es gehen. ich hab noch nie eine ubuntu-installation gesehen die so ein problem hatte.
ist das wirklich das offizielle ubuntu oder irgendein derivat? war das installationsmedium garantiert fehlerfrei? auf welchem dateisystem liegen die files?
was sagt "ls -l"?
geht es z.B. bei nano auch nicht?
Leider geht es bei mir nicht, oder zumindest nur bei Ordnern. Bei Dateien passiert absolut garnichts.
Also die Angaben, die du machst sind irgendwie nicht zu 100% nachvollziehbar :D Ich dachte nämlich auch erst an das, was Tesseract schrieb...
Mach bitte einfach mal folgendes:
#1: Wechsle mit dem "cd"-Kommando in das Verzeichnis mit der 3dcenterlogoneu.jpg
#2: Gib einmal "ls" (list directory contents) ein und in der nun ausgegebenen Liste sollte die 3dcenterlogo.jpg zu finden sein. Poste am besten hier die Ausgabe von "ls"
#3: Jetzt gib mal "head 3d<TAB>" ein und sag was passiert.
Wenn es jetzt nicht funktioniert, stimmt tatsächlich etwas nicht!
("head" gibt die ersten paar Zeilen einer Datei aus und verlangt daher auch nach einer Datei als Parameter und nicht nach einem Ordner)
Es funktioniert vielleicht nicht mit Dateien, wenn Du diese am Anfang setzt und diese als Kommando ausgeführt werden sollen, und diese nicht im Befehlspfad sind. Du muß u.U. in der profile-Datei der jeweiligen Shell (.profile ksh/bash, .login .cshrc in csh und tcsh, .bash_profile für bash)
PATH=/usr/bin:/usr/sbin:.
den :. setzen, damit alle aktuellen Dateien unter ./ angesprochen werden können.
Es funktioniert vielleicht nicht mit Dateien, wenn Du diese am Anfang setzt und diese als Kommando ausgeführt werden sollen, und diese nicht im Befehlspfad sind. Du muß u.U. in der profile-Datei der jeweiligen Shell (.profile ksh/bash, .login .cshrc in csh und tcsh, .bash_profile für bash)
PATH=/usr/bin:/usr/sbin:.
den :. setzen, damit alle aktuellen Dateien unter ./ angesprochen werden können.
Autsch. Es hat schon einen Grund warum . nicht im PATH ist....
Autsch. Es hat schon einen Grund warum . nicht im PATH ist....
Warum autsch? Blödsinn!!! :down: So sehen sollte man dann auch auf das Komfort einer bash oder tcsh verzichten, man könnte ja auch aus Versehen was falsch tabben, oder eine falschen Befehl durch die Cursortasten herholen. :rolleyes: Oder ja kein rm -rf setzten, am besten noch ein alias rm=`rm -i` ! :rolleyes: Die Hardcorefreaks setzten -x und immer schön ein
sh befehl
setzen.
Gehts noch? :rolleyes: Wenn Komfort, dann richtig, und dann gehört . sehr wohl in den Befehlspfad. Oder wer ist schon so scharf drauf, immer ./ davor zu setzen? Ich nicht.
BTW arbeite ich schon seit fast 18 Jahren so, und viele Admin-Kollegen auch, was soll daran falsch sein? Oder gehörst Du etwa auch zu den -x und sh-Leuten? Viel Spaß!
Sorry, wer nicht weiß, was er unter dem System tut, sollte eh ganz die Finger von lassen. Das was Du da ankreidest, ist nur eine Arbeitsverhinderung, keine Verbesserung. Höhere Sicherheit schafft das nicht!
Xanthomryr
2010-11-28, 23:19:40
Warum autsch? Blödsinn!!! :down: So sehen sollte man dann auch auf das Komfort einer bash oder tcsh verzichten, man könnte ja auch aus Versehen was falsch tabben, oder eine falschen Befehl durch die Cursortasten herholen. :rolleyes: Oder ja kein rm -rf setzten, am besten noch ein alias rm=`rm -i` ! :rolleyes: Die Hardcorefreaks setzten -x und immer schön ein
sh befehl
setzen.
Gehts noch? :rolleyes: Wenn Komfort, dann richtig, und dann gehört . sehr wohl in den Befehlspfad. Oder wer ist schon so scharf drauf, immer ./ davor zu setzen? Ich nicht.
BTW arbeite ich schon seit fast 18 Jahren so, und viele Admin-Kollegen auch, was soll daran falsch sein? Oder gehörst Du etwa auch zu den -x und sh-Leuten? Viel Spaß!
Sorry, wer nicht weiß, was er unter dem System tut, sollte eh ganz die Finger von lassen. Das was Du da ankreidest, ist nur eine Arbeitsverhinderung, keine Verbesserung. Höhere Sicherheit schafft das nicht!
Dass das keine höhere Sicherheit schafft ist schlicht und ergreifend falsch!
Man hat sich schon was dabei gedacht dass das aktuelle Verzeichnis beim root Account nicht im Path ist.
http://de.linwiki.org/wiki/Linuxfibel_-_Sicherheit_-_Systemsicherheit#Vorsicht_mit_.C2.BB..2F.C2.AB.21
Aber muß halt jeder selber entscheiden.
Dass das keine höhere Sicherheit schafft ist schlicht und ergreifend falsch!
Man hat sich schon was dabei gedacht dass das aktuelle Verzeichnis beim root Account nicht im Path ist.
http://de.linwiki.org/wiki/Linuxfibel_-_Sicherheit_-_Systemsicherheit#Vorsicht_mit_.C2.BB..2F.C2.AB.21
Aber muß halt jeder selber entscheiden.
Bei root mag es u.U. angebracht sein. Nur wer root ist, kann mit ./befehl genauso Mist bauen als mit nur befehl. Das macht so erst mal keinen Unterschied. Achtsamkeit und Aufmerksamkeit kann so ein Konstrukt nicht verhindern oder ermöglichen.
Dass das [Anm: . ist nicht in PATH] keine höhere Sicherheit schafft ist schlicht und ergreifend falsch!
Danke, besser hätt ichs auch nicht ausdrücken können :)
Aber muß halt jeder selber entscheiden.
Rischtisch.
@PHuV: Wenn du höheren Komfort (??? meinst du jetzt echt diese 2 Zeichen zusätzlich machens aus?) über höhere Sicherheit stellst ist das deine Sache. Aber bitte empfiehl sowas nicht an Anfänger weiter. Wie schon erwähnt gibt es gute Gründe warum . nicht im PATH ist.
Danke, besser hätt ichs auch nicht ausdrücken können :)
Trotzdem ist es nicht richtig oder besser! Einmal mit autovervollständigen oder eine cursurtaste zuviel bei der Befehlswiederholung, und schon hat man genau den gleichen Salat.
@PHuV: Wenn du höheren Komfort (??? meinst du jetzt echt diese 2 Zeichen zusätzlich machens aus?) über höhere Sicherheit stellst ist das deine Sache. Aber bitte empfiehl sowas nicht an Anfänger weiter. Wie schon erwähnt gibt es gute Gründe warum . nicht im PATH ist.
Klar, und autovervollständigen birgt überhaupt kein Risiko? :rolleyes: Zu was dann überhaupt bash? Wie gesagt, wer es ganz sicher haben will (haha), macht das Executable-Flag weg und führt nur mit sh ... aus!
hast du überhaupt die bash gestartet? mach mal ein terminal window auf:
> bash
> ls <tab><tab>
Trotzdem ist es nicht richtig oder besser! Einmal mit autovervollständigen oder eine cursurtaste zuviel bei der Befehlswiederholung, und schon hat man genau den gleichen Salat.
Nein, der Post von Xanthomryr (hast du den Link überhaupt gelesen?) beschreibt tatsächlich ein systemimmanentes Sicherheitsrisiko, du redest immer nur davon dass man durch schlampige Benutzung ("Einmal Autovervollständigen zuviel...") was kaputt macht. Das sind zwei grundlegend verschiedene Dinge. . in PATH ändert grundlegend das Systemverhalten. Z.b. übernehmen bash-scripte die PATH Variable, d.h. dass du sobald . in PATH ist unvorhersehbares Verhalten bekommst abhängig davon in welchem Verzeichnis das script gestartet wird, und das ist nur ein einfaches Beispiel. Willst du das ernsthaft mit dem "Risiko" der Autovervollständigung vergleichen?
Ob diese Dinge für den Privatbenutzer relevant sind muss jeder selber entscheiden, Fakt ist, es ändert das System in einer Weise die potentiell mehr Angiffsfläche bietet. Daher ist
Höhere Sicherheit schafft das nicht!
und
Trotzdem ist es nicht richtig oder besser!
einfach falsch.
Klar, und autovervollständigen birgt überhaupt kein Risiko? :rolleyes: Zu was dann überhaupt bash? Wie gesagt, wer es ganz sicher haben will (haha), macht das Executable-Flag weg und führt nur mit sh ... aus!
Die Polemik kannst du dir sparen.
Hier ist noch ein bisschen Lektüre für dich:
http://serverfault.com/questions/98587/adding-current-directory-to-path
http://www.faqs.org/docs/Linux-mini/Path.html#s12
http://it-support-servicestatus.web.cern.ch/it-support-servicestatus/ServiceChangeArchive/PATH-060607.htm
http://stray-notes.blogspot.com/2010/11/adding-current-directory-to-path.html
Aber muß halt jeder selber entscheiden.
Ganz genau.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.