Tab Completion in der Shell

S

Sloop

Well-Known Member
Hallo all,

mir ist aufgefallen, dass die standard csh die in meinem FreeBSD 9.0 Release-p3 steckt, nicht wirklich tolle Tab completion macht. Da kann es sein, dass Tab die Ordner bzw. Pfade erst dann weitervervollständigt wenn ich mit ein paar Buchstaben nachhelfe. Dann wieder gehts nicht mehr weiter, und ich müsste wieder erst was eingeben .Teilweise geht dann GAR KEINE Completion mehr, obwohl der Pfad in den ich mit "cd" wechseln wollte existiert. Ich kann also reinwechseln, und "pwd" zeigt mir ja deutlich an dass ich in dem Pfad stecke. Aber die Tab Completion macht mich irgendwie gar nicht glücklich. Was mir auch fehlt ist die Pfadanzeige in der Prompt.

Da müßte ich wohl die .cshrc anpassen, oder? Wie lautet denn eine 'gute' empfohlene Zeile für 'nen aussagekräftigen Prompt? Kann man hier denn eigentlich auch dircolors Aliase irgendwie definieren?

Oder würdet ihr mir empfehlen auf die csh vollkommen zu verzichten, sie zu deinstallieren und stattdessen z.B. zsh zu verwenden? Wenn ja, in welcher Reihenfolge sollte ich das eurer Meinung nach am besten tun? Will mich ja nicht aussperren oder so :)

Danke im Voraus.
 
@crest: was genau macht dieser Befehl? wenn ich 'man exec' eingebe, sehe ich dass dieses Kommando zu den builtin kommandos der csh und sh gehört. Aber nachdem ich ihn abgesetzt habe und anschließend ein "echo $SHELL" eingebe, krieg ich als Antwort immter noch /bin/csh.

Wenn ich jetzt aber mal mit der Tab-Taste rumspiele, scheint sich das Verhalten tatsächlich verändert zu haben. Hab ich nun tatsächlich die zsh oder wie?

@Kamikaze: tcsh ist der zsh zu bevorzugen? Oder ist das wirklich nuru Geschmackssache? Wenn ich diesen Eintrag in die .cshrc reinsetzen soll (was immer er auch tut), bedeutet es doch, dass die .cshrc definitiv vorher abgearbeitet wird nach dem Login, oder? Kann ich dem System nicht gleich beibringen er soll die csh GAR NICHT erst laden, sondern gleich eine andere Shell verwenden?

@metro: wenn ich deinen set prompt direkt in der Shell eingebe, scheint es nicht zu greifen. Auch echo $prompt zeigt mir noch %m%# an :(

PS: pkg_info | grep zsh zeigt mir dass die zsh-5.0.0 installiert ist. Ich glaube das hatte ich mal aus den Ports ganz am Anfang installiert gehabt. Jedoch nie irgendwas manuell angepasst, damit die verwendet wird. Das will ich ja jetzt nachholen :p
 
Welche Shell man verwendet, ist einzig und allein Geschmackssache. Viele FreeBSDler nutzen halt die tcsh (unter FreeBSD ist "csh" ein Hardlink auf "tcsh"), da sie die Standardshell des Systems ist und zum zur interaktiven Nutzung gut geeignet. Ich nutze sie und bin zufrieden, aber wenn ich noch einmal 15 wäre, würde ich eher eine modernere Shell mit einer Abart des Bourne-Syntax nutzen.

Die Shell kannst du mit chsh(8) umstellen. Allerdings solltest du nicht die Shell von root auf eine nicht im Basissystem enthaltene Shell ändern. Ansonsten killen dir zerschossene Ports den root-Account, was nicht so schön ist. Wenn du es unbedingt möchtest, solltest du in jedem Fall den zweiten Rootaccount "toor" aktivieren. D.h. ihm ein passwort zuweisen, sodass man sich mit ihm einloggen kann. :)

Als Beispiel:
Code: 
chsh /usr/local/bin/zsh
 
Sloop schrieb:
@metro: wenn ich deinen set prompt direkt in der Shell eingebe, scheint es nicht zu greifen. Auch echo $prompt zeigt mir noch %m%# an :(
Zum Vergrößern anklicken....

?:confused:
Code: 
me@work<~>501*csh
me@work#set prompt = "Weite \@ Welt#"
Weite @ Welt#set prompt = "nix#"
nix#set prompt = "Weite \@ Welt#"
Weite @ Welt#set prompt = "leer"
leer#set prompt = "%N@%m<%~>*"
me@work<~>*
me@work<~>*cd /usr/local/share/
me@work</usr/local/share>*
wobei 'me' = user und 'work' = hostname'
Verfügbare variablen:
man csh(1)
 
genau das meinte ich ja, ich kann eingeben
Code: 
set prompt=irgendwas
aber das wird nicht übernommen. UNd echo $prompt bestätigt mir das. Warum?

Zur Shell noch: ps | head zeigt mir dass als zweiter Prozess definitiv die zsh läuft. Aber wieso spuckt mir selbst nach "rehash" der Befehl "echo $SHELL" immer noch /bin/csh aus ?
 
Sloop schrieb:
Zur Shell noch: ps | head zeigt mir dass als zweiter Prozess definitiv die zsh läuft. Aber wieso spuckt mir selbst nach "rehash" der Befehl "echo $SHELL" immer noch /bin/csh aus ?
Zum Vergrößern anklicken....
Weil die Umgebungsvariable nicht geändert wurde, sondern der Befehl zum Ausführen der Shell gegeben wurde. Also ist $SHELL immer noch das, was der User halt hat.

Soviel ich weiß ist die zsh kein Bestandteil des Basisystems, d.h. sie müsste installiert worden sein. Hast du das ? Wenn ja, gut.
Anscheinend bist du aber in der csh, die wie schon gesagt ein hardlink auf die tcsh ist.
Der Standardprompt kann mit Variablen und allem möglichen geändert werden.
Das geht entweder direkt in der csh ( die ' " ' nicht vergessen), oder wie schon gesagt, mittels entsprecheder Einträge in der .cshrc im Userhome.
Diese wird als Standardvorgabe (eigentlich) bei der Einrichtung des Users in sein home gelegt.
Wenn dem nicht so ist, schau mal unter '/.cshrc' oder '/root/.cshrc" und kopiere diese in dein home.
Dort ist eine Zeile 'set prompt=...' die du nach Belieben verändern kannst und die das gewünschte dann beim nächsten Aufruf anzeigt.
All das und noch viel mehr gibts noch viel weiter erklärt in man csh(1).
 
Zur Prompt:
Danke dir, ich hatte zwischenzeitlich rebootet und dann wurde das mit "set prompt=blabla" auch möglich. Mittlerweile habe ich auch schon meine Wunschprompt zusammengestellt, sogar mir farbiger Hervorhebung im Username, hurra :)
Code: 
set prompt="[%l] %B%{\033[31;40m%}%n%{\033[0m%}%b@%m:%/%#"

Was mich aber ein wenig noch wundert --> schau ich mir die /root/.cshrc an, dann steht dort
if ($?prompt) then
set prompt = "`/bin/hostname -s`# "
...
Zum Vergrößern anklicken....
Wieso geht FreeBSD hier diesen Weg, dass Sie für den Hostnamen das Programm /bin/hostname ausführt? Könnte hier nicht einfach %m verwendet werden? Wieso macht das der default Eintrag so kompliziert?

Und ich wollte eigentlich die globale /etc/csh.cshrc anpassen, damit meine prompt für alle User gilt. Also habe ich das dort reingeschrieben. Jedoch wird nach dem Einloggen von root oder einem User der Prompt nicht übernommen. Da ist wohl die lokale Userpromptdatei /root/.cshrc schuld. Denn wenn ich dort die Zeile "set prompt = ..." auskommentiere, dann greift meine globale Konfiguration. Wieso aber verstehe ich nicht? Da heißt es doch "if ($?prompt) then ..." Ich hatte das so verstanden, dass wenn die Variable PROMPT nicht konfiguriert ist, dann würde der default Eintrag set prompt = "`/bin/hostname -s`# " ausgeführt werden. Aber anscheinend irre ich mich da, und die Zeile in der lokalen rc greift trotzdem (deswegen hatte ich sie auch auskommentiert, damits überhaupt geht). Kann mir das jemand erläutern?

Wenn ich in /home/max/.cshrc reinschaue, dann steht bei dem User gar keine set prompt = Zeile drin. Dann müsste doch die globale config bei dem greifen, tuts aber nicht? Stattdessen kriegt der als Prompt ein hässliches Dollarzeichen zu Gesicht. Why?


Zur Shell:
Nachdem ich natürlich rebootet habe sehe ich durch "ps |head" (zweiter Prozess) dass csh verwendet wird (und somit eben genaugesagt die tcsh weil das eben hardlinked in *BSD ist). Ich vergess jetzt erstmal die zsh, denn eigentlich sollte ich ja tab completion auch mit der tcsh machen können. Sofern ich mich recht erinnere, kann die tcsh tab completion, genau deswegen wurde sie ja quasi auch ins Leben gerufen, um die übliche csh zu erweitern, oder nicht (korrigiert mich falls ich falsch liege) ? Es heißt doch, dass FreeBSD hardlinked auf tcsh, also müsste ich ja defaultmässig die tcsh verwenden, aber wieso funzt dann tab completion so schlecht?
 
Zuletzt bearbeitet:
Moment, um das aufzuklären muss ich mal ein wenig ausholen. Denn sonst wird es kaum klar werden: Die csh ist die Shell, die ursprüngliche mal von Bill Joy für BSD geschrieben wurde. Über die Jahre hinweg ist die ursprüngliche csh in diverse Zweige divergiert, jedes BSD-Derivat hatte seine eigene Inkarnation. In einen dieser Zweige wurden Funktionen aus TENEX (aka TOPS-20) eingebaut. Die sich ergebende Shell nannte man dann "tcsh". Die tcsh hatte immer nur einen Hauptentwicklungszweig, es gibt also nur diese eine Inkarnation der tcsh.

Da die tcsh als Verbesserung der csh gedacht war, musste sie zu dieser möglichst kompatibel bleiben. Scripte sollten weiter laufen, unbedarfte Nutzer sollten sich nicht umstellen müssen und so weiter. Daher hat die tcsh einen Emulationsmodus: Wenn die tcsh als "csh" aufgerufen wird, ist sie mit csh-Implementierung aus 4BSD kompatibel. Das kostet allerdings einige Features. Wird sie als "tcsh" aufgerufen, hat man die vollen Features, aber ist eben nicht mehr komplett zur csh kompatibel. In der Praxis ist das schon seit vielen Jahren kein Beinbruch mehr, man sollte daher tunlichst "/bin/tcsh" statt "/bin/csh" als Shell eintragen.

Der Drang mit der csh kompatibel zu bleiben, zeigt sich auch in den Konfigurationsdateien. Welche Datei an welchem Punkt im Startprozess aufgerufen wird, ist vom System abhängig. Eine Liste findet sich in der Manpage. Ein weiterer Faktor ist, ob es sich um eine Loginshell oder eine andere Shell handelt... Daher sollte man tunlichst seine eigene Konfiguration in ~/.tcshrc schreiben und nicht in ~/.cshrc. Bei ersterer Datei kann man sich sicher sein, dass unabhängig des Systems rauskommt, was man sich vorstellt.

Unter FreeBSD ist die Reihenfolge:
1. /etc/csh.cshrc
2. /etc/csh.login (nur Login-Shells)
3. ~/.tcshrc
4. ~/.cshrc (nur wenn ~/.tcshrc nicht existiert)

"set prompt = "`/bin/hostname -s`# "" kommt nun eben dadurch zustande, dass die Prompt-Variablen ein tcsh-Feature sind, was in csh nicht vorhanden sein musst (unter FreeBSD aber ist).

Kommen wir nun zur Tab-Vervollständigung. Die ist sehr weit konfigurierbar, aber ein gutes Verhalten erhält man mit:
Code: 
# Use the history of commands to aid expansion
set autoexpand 

# Autolisting of options only when a new character is appended
set autolist=ambiguous

# Autocompletion
set complete

Recht praktisch (vervollständigt das bereits eingegebene Kommando aus der Historie):
Code: 
# History up and down
bindkey -k up history-search-backward
bindkey -k down history-search-forward

Die vollständige .tcshrc findest du unter: https://github.com/Yamagi/dotfiles/blob/master/tcsh/tcshrc
 
weniger zur TAB-Completion, die ich auch nicht immer so richtig verstehe, als zur Frage des Shell Wechsels:

Wenn sie installiert ist, kannst du sie einfach aufrufen und hast sie.
Mhm.
Wenn du sie immer als Default shell haben willst, wird sie bei adduser (oder heißt es nun useradd?) abgefragt. Hast du dich da falsch entschieden, kannst du das später korrigieren. Es wird in der Datei /etc/passwd festgeschrieben, welche shell ein User haben soll.
Diese Datei könnte einfach editiert werden, aber es gibt dazu speziell einen extra Befehl, weil nach Änderung auch ein Binary davon gebaut werden soll, was da in der passwd beschrieben ist. Der Befehl ist vipw(8). Damit kannst du das einfach editieren, ich zeige mal ein Beispiel für einen User test, den ich mit tcsh angelegt hatte und nun in bash ändere:
Code: 
 cat /etc/passwd
.....
test:*:1008:1009:test user:/home/test:/bin/tcsh

dann mit vipw geändert:
Code: 
test:*:1008:1009:test user:/home/test:/usr/local/bin/bash
Die Reaktion darauf:
Code: 
o-box@senyo ~:-> su test
Password:
[test@senyo /home/o-box]$ echo $SHELL
/usr/local/bin/bash
[test@senyo /home/o-box]$ csh
test@senyo /home/o-box:-> echo $SHELL
/usr/local/bin/bash
test@senyo /home/o-box:-> ex
exit
[test@senyo /home/o-box]$
Ich denke, das zeigt alles: Der Prompt und die Aliase folgen den Festlegungen in den cshrc, bzw profile Dateien. Die Variable SHELL bleibt auf der SHELL des Users.

Die Einstellungen in /etc sind global und werden von den lokalen (per User) Einstellungen in deren ~/.cshrc oder ~/.profile überschrieben oder in einem guten Falle ergänzt.

Shells sind kleine Programme gemessen an heutigen Standards und du kannst sie quasi alle installieren und Testweise ausführen, um deinen Liebling zu finden. Für die bash gibt es viele gute Beispiele im Netz und sie wird von Linux-Anhängern geliebt. Mir selbst ist es leichter gefallen, die csh zu dem zu bringen, was ich so wollte.
Die csh oder tcsh vervollständigt nicht bei Zweideutigkeit, soviel ich das sehe. Du musst wenigstens so viele Charaktere eingeben, bis Eindeutigkeit im Namen erreicht ist.

Die Gefahr, eine shell außerhalb des Basis-Systems zu wählen und sich damit vielleicht einmal auszusperren, darf nicht unterschätzt werden! Das wurde schon erwähnt, ich möchte das nochmal unterstreichen. Wenn /usr/local/bin unerreichbar ist, hast du keine Shell!
 
@pit234a: alles klar, da konnte ich zu 100% folgen. Danke

@yamagi: bitte nicht lachen oder hauen, aber ich hab's nicht vollkommen verstanden und bitte um Erklärung folgendes Sachverhaltes:

(1) set autoexpand=ambiguous und autoexpand habe ich auch in der "man tcsh" gefunden, aber so richtig verstanden hab ich es nicht. Ich habs auch mal in der prompt eingegeben, damits gleich aktiv wird, aber ich konnte keinen Unterschied feststellen bei der tab-completion. Was ist da anders, besser oder schlechter? Außerdem meintest du man sollte noch "set complete" für autocompletion setzen. Ich dachte "set autolist" aktiviert dieses Feauture? irgendwie komm ich da ganz durcheinander.

(2) du sagtest, man sollte lieber /bin/tcsh starten, statt der /bin/csh (aus den bereits von dir erwähnten Gründen). Wie kann ich denn nachprüfen, welche shell bei mir gestartet wurde? Ich dachte wenn ich /bin/csh starte, würde damit automatisch die /bin/tcsh gestartet, weils hardlinked ist? ein ls -l in /bin zeigt mir ja auch die Zahl 2 ein vor csh oder tcsh also nehme ich an, dass die miteinander verlinkt sind, richtig? Wie kann ich aber trotzdem nachprüfen, welcher Befehl eigentlich gestartet wird, wenn ich mich einlogge? welcher Systemprozess startet die Shell, in welcher Datei steht das geschrieben?

(3) was ist der Unterschied zwischen einer Non-Login Shell und einer Loginshell? Ich lese in der man, dass bei login-shells folgende Reihenfolge abgearbeitet wird

/etc/csh.cshrc
/etc/csh.login
~/.tchshrc
~/.cshrc (falls .tchshrc nicht vorhanden war)
~/.history (oder die Werte der histfile Variable)
~/.login
~/.cshdirs (oder die Werte der dirsfile Variable)

Die Reihenfolge kann sich bei ~/.tcshrc oder ~/.cshrc und ~/.history ändern, je nachdem wie die Variable "shell" konfiguriert kompiliert wurde.

Non-login shells arbeiten sich logischerweise nur durch:
/etc/csh.cshrc
~/.tcshrc oder ~/.cshrc

Wie der Name schon sagt, wenn ich mich als root oder foo einlogge, dann wird -so nehme ich an- eine Login-Shell gestartet. Wann startet also eine Nicht-Login-Shell? :)

(4) und zuletzt noch: was genau macht denn der Eintrag, den ich in meinem Beitrag #10 weiter oben erwähnte? Ich meine den Eintrag der in meiner default ~/.cshrc steht, wofür steht $?prompt ?? Denn ich hatte das so verstanden: wenn die Variable prompt nicht definiert wurde, dann führe alle nachfolgenden Kommandos aus. Aber anscheinend ist es das nicht, denn mein globaler "set prompt = blabla" aus der /etc/csh.cshrc hat nicht gegriffen. Erst nachdem ich in der ~/.cshrc den "set prompt = blabla" aus der Bedingung einkommentiert habe.

EDIT:
Habs jetzt verstanden. Der Befehl sagt grad das Gegenteil: Wenn der zuletzt ausgegebene Errorlevel, also in dem Fall heißt es: wenn eine Variable namens prompt existiert, hat sie einen Wert ungleich 0, also greift der anschließende Block danach, und somit hat der Wert aus ~/.cshrc die Einstellung von /etc/csh.cshrc überschrieben da die Userconfig nach der Globalconfig greift. Das Kommentieren in der ~/.cshrc war also schon richtig, damit die globale Konfiguration Bestand haben kann. Bitte um Korrektur, falls ich das trotzdem falsch interpretiert habe. Aber IMHO macht es so Sinn :) In diesem Zuge habe ich noch etwas experimentiert und meine /etc/csh.cshrc modifiziert: wenn der User "root" angemeldet ist, erscheint root in roter Schrift, als Warnung dass man eben mit dem root-account eingeloggt ist. Alle anderen User haben dann die Farbe grün. Die /etc/csh.cshrc sieht bei mir momentan so aus und zu meiner Verwunderung hat's sogar auf Anhieb funktioniert *freu*:
Code: 
if ($uid) then
 set prompt="[%l] %B%{\033[32;40m%}%n%{\033[0m%}%b@%m:%/%#"
  else
 set prompt="[%l] %B%{\033[31;40m%}%n%{\033[0m%}%b@%m:%/%#"
endif
set autolist
set nobeep
set expand

Könnte ich mir die zwei langen Zeilen und die extra Abfrage sparen, indem ich das irgendwie in einer Zeile unterkriege, á-la:
Code: 
set prompt="[%l] %B%{\033[`if ($uid) echo 32 else echo 31`;40m%}%n%{\033[0m%}%b@%m:%/%#"
Geht das überhaupt und wenn ja wie wäre der richtige Syntax hierfür? So klappt das nicht, weil else nicht greift. Wenn ich `if !($uid) echo 31; if ($uid) echo 32;` verwende funktionierts, aber das muss doch kürzer gehen in einer Zeile mit If..Else..Endif, oder nicht?

PS: Für alle anderen, die sich für Prompt-Anpassung in diversen Shells interessieren, kann ich auch iesen übersichtlichen Link empfehlen
 
Zuletzt bearbeitet:
man-page Hilfe in der Konsole auf Knopfdruck ist auch sehr schön: :)
Code: 
#mit <F1> man page des Kommandos am Anfang der tcsh-Zeile oeffnen
#http://www.chruetertee.ch/blog/archive/2007/02/17/manpage-mittels-f1-aufrufen.html
alias helpcommand man
bindkey ^[OP run-help   # F1 xterm
bindkey ^[[M run-help   # F1 cons25
 
Guten Morgen :)

1: "set autolist=ambiguous" erkennt automatisch, wenn die Vervollständigung weitere Informationen geben soll und trägt den eindeutigen Teil ein. Ein Beispiel:
Code: 
$ cd ~
$ cd <tab>
# An dieser Stelle passiert ohne autolist nichts

$ set autolist=ambiguous
$ cd ~
$ cd <tab>
# Die Verzeichnisse im Home-Dir werden angezeigt
  und sofern es einen eindeutigen Teil gibt, wird
  dieser eingetragen. Beginnen z.b. alle Verzeichnisse
  mit "test_", wird "test_" eingetragen.

"set complete" schaltet die Autovervollständigung ein. Allerdings ist das Kommando oft unnütz, da bereits vorhergehende Kommandos es implizit aktivieren. Man kann dort noch Spezifizierungen vornehmen, ein "set complete=enhance" veranlasst tcsh z.B. die Groß- und Kleinschreibung zu ignorieren. "set autoexpand" lässt die tcsh die Historie einbeziehen, um die korrekte Vervollständigung zu wählen. Das fällt bei normaler Nutzung eigentlich nicht auf, ist aber im Zusammenspiel mit erweiterten Funktionen wie "magic-space" sehr hilfreich.

2. Naja, die Shell ist zwar hardlinked, aber der Aufrufname bestimmt ihr verhalten. Wird sie als "csh" aufgerufen, verhält sie sich wie eine csh. Wird sie als "tcsh" aufgerufen, wie eine tcsh... Die Shell wird beim Login von login(8) gestartet, er liest die zu startende Shell aus der Nutzerdatenbank (/etc/passwd, /etc/master.passwd und /etc/pwd.db. Diese Dateien niemals manuell editieren!). Du kannst den Inhalt der Dateien mit vipw(8) anschauen und editieren.

3. Eine Login-Shell ist die Shell, die von login(8) nach dem Login des Nutzers gestartet wird. Eine Nicht-Login-Shell ist jede andere Shell. Durch die Trennung erreicht man, dass gewisse Dinge beim Login einmal ausgeführt werden. Später werden die dadurch gewonnenen Einstellungen an Nicht-Login-Shells vererbt. Z.B. sollte das Loginscript ~/.login nur einmal laufen und nicht bei jedem Start einer Shell.

4. Was du beschreibst ist genau der Grund, weshalb man schon extrem masochistisch sein muss um die (t)csh zu scripten. Im Rahmen der Konfiguration kommt man nicht drum herum, aber später sollte man tunlichst die Finger davon lassen. Dir ist nun schon aufgefallen, dass die (t)csh keine echten Variablen hat. Das ist aber nur die Spitze des Eisbergs, hinzu kommt z.B. das Fehlen von Funktionen oder sich je nach Position im Script anders verhaltene Konstrukte. Der syntax für if-then-else ist:
Code: 
if (expr) then
...
else if (expr2) then
...
else
...
endif
 
@spaulding: Danke! Habe ich glecih eingebaut :)

@Yamagi:

1) "set autolist" macht doch schon das was du beschreibst. Deswegen war ja meine Frage, was der ambiguous Zusatz mehr macht.

Kann ich auf BSD eine Autocompletion einrichten, wenn ich (ohne sshfs) eine Datei von einem Rechner zum andren kopieren möchte mittels 'scp' ? er soll dann auch auf dem Remote-System schon im Voraus erkennen, welche Pfade/Dateien vorhanden sind. Dabei müsste er sich wohl der History bedienen, oder geht das sonstwie?


Was spricht denn also gegen die zsh? Irgendwie hab ich noch in Erinnerung, daß die mir NICHT empfohlen wurde. Auf der Linuxseite verwende ich meistens entweder bash oder zsh. Die zsh hat eine etwas bessere Tab-Funktionalität wie ich finde.

2.) hab ich verstanden

3.) ebenso verstanden jetzt. Sonst würde jedes Skript das ja eine (sub-)shell startet die ganze Loginprozeduren abarbeiten, gell?

4.) diese Syntax ist schon klar, aber wie hätte ich es in meinem Beispiel in einer Zeile wie bereits vorgeschrieben verwenden müssen? Ich bin ja trotzdem ncoh den Umweg gegangen
`if !($uid) echo 31; if ($uid) echo 32;`
Zum Vergrößern anklicken....
ich frag ja quasi zwei mal das gleiche ab, das muss doch auch kürzer gehen. Das meine ich :)
 
1. Genau das, was in der Manpage steht: "If autolist is set to `ambiguous', choices are listed only when completion fails and adds no new characters to the word being completed." Die Liste wird also nur dann angezeigt, wenn die Autovervollständigung nicht mehr weiter weiß, nichts mehr dem Teilausdruck hinzufügen kann. Ohne "ambiguous" wird die Liste immer angezeigt.

Man kann eine Autocompletion über scp per selbstdefinierter Vervollständigung einrichten. Das geht mit dem "complete" Befehl (nicht zu verwechseln mit der Einstellung). Es nun hier zu erklären würde viel zu weit führen, meine oben verlinkte tcshrc hat einige Beispiele.

Ich schrieb ja schon oben, dass ich heute die tcsh nicht mehr empfehlen würde. Ich nutze sie nur noch, da man fast 16 Jahre Gewohnheit nicht aus dem Kopf bekommt und es noch mal so lange dauern würde, bis eine andere Shell perfekt konfiguriert wäre. Die tcsh mag eine gute interaktive Shell sein, aber sie hat massive Nachteile:
- Sie ist keine Bourne-Shell. Das bedeutete anderer Syntax.
- Sie ist zum Scripten ungeeignet (aber das sind imo alle Shells).
- Der Code ist Murks, fast jedes Update haut ungewollt einige Features durch.
- Sie ist grottenlahm. Das fällt vor allem bei großen Historien auf und einem langen $PATH auf.
Andere, moderne Shell wie die zsh oder meinetwegen auch die bash sind da viel besser. Ich finde die fish auch sehr interessant, da sie aber nicht bournekompatibel ist, disqualifiziert sie sich leider selbst...

3. Genau.

4. So aus dem Kopf habe ich keine Ahnung, muss ich zugeben.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben