Von Belehrsammer Bash Benutzer. am Do, 7. Mai 2009 um 12:25 #
Vieleiche mag jetzt auch nochmal jemand so nett sein, zu erklären wie man die gleiche Funktionalität in der Z-Shell erreicht. Und bitte nicht mit RTFM antworten.
Würde mich auch mal interessieren. Entgegen aller Behauptung aller Vorposter ist diese Funktion _nicht_ in ZSH integriert und muss demzufolge mit einem dem obigen Script ähnlichem Syntax in die .zshrc oder besser in die .zshenv geschrieben werden.
bei der Z-Shell muss man lediglich die variable CDPATH setzen; dann wird die Z-Shell bei einem "cd dir" zunaechst im aktuellen verzeichnis nach einem unterverzeichnis "dir" suchen; falls kein unterverzeichnis "dir" existiert, so durchsucht die Z-Shell die verzeichnisse im pfad $CDPATH der reihe nach. falls $CDPATH auch die angabe "." fuer das aktuelle verzeichnis enthaelt, so wird es erst dann durchsucht, wenn die vorhergehenden verzeichnisse bereits durchsucht wurden.
hierbei wird also zunaechst explizit das aktuelle verzeichnis (".") durchsucht, dann das darueberliegende verzeichnis (".."), so dass man leicht in "parallele verzeichnisse" wechseln kann:
zsh> mkdir /tmp/bar /tmp/foo zsh> cd /tmp/foo zsh> cd bar zsh> pwd /tmp/bar
danach kommt das $HOME verzeichnis dran ("~"), gefolgt vom mit den eigenen webseiten ("~/public_html") und dem projektverzeichnis fuer das zshbuch. als letztes dann das verzeichnis mit den installierten dokumentationen.
zsh> cd zsh zsh> pwd /usr/share/doc/zsh
bei der suche ist natuerlich auch die expansion eines verzeichnispraefix moeglich:
und wer nach /usr/share/doc/zsh wechseln moechte, der kann das auch mit einer moeglichst eindeutigen angabe der praefixe der einzelnen komponenten machen:
zsh> cd /u/s/d/zsh[TAB] zsh> cd /usr/share/doc/zsh
Muhahah, und da macht Ihr alle so ein Geschrei drum? "nimm die z-shell", "schon mal ZSH gesehen?"...
CDPATH existiert genauso in der bash, ebenso wie in der ksh (unter meinem geliebten HP-UX).
Ich habe noch nie mit zsh gearbeitet, nutze aber schon seit 12 Jahren die CDPATH-Variable (in ksh/HP-UX, in Suses bash, Sidux bash, Fedora, Debian, ArchLinux und Ubuntu bash). Worüber redet Ihr hier eigentlich?
Warum kommt niemand auf die Idee so etwas einfach mal zu MACHEN, anstatt immer nur darüber schlau zu schreiben? Was lernt Ihr heute eigentlich noch? Neee, neee, neee
Jau echt. Wenn die ZSH wirklich so gut ist, verstehe ich auch nicht, warum die Bash noch immer der ultimative Standard ist und warum sie Perl als Shellskriptersatz nicht obsolet gemacht hat.
cd [ -qsLP ] [ arg ] cd [ -qsLP ] old new cd [ -qsLP ] {+|-}n Change the current directory. In the first form, change the current directory to arg, or to the value of $HOME if arg is not specified. If arg is -, change to the value of $OLDPWD, the previous directory.
Otherwise, if arg begins with a slash, attempt to change to the directory given by arg.
If arg does not begin with a slash, the behaviour depends on whether the cur‐ rent directory . occurs in the list of directories contained in the shell parameter cdpath. If it does not, first attempt to change to the directory arg under the current directory, and if that fails but cdpath is set and contains at least one element attempt to change to the directory arg under each compo‐ nent of cdpath in turn until successful. If . occurs in cdpath, then cdpath is searched strictly in order so that . is only tried at the appropriate point.
If no directory is found, the option CDABLE_VARS is set, and a parameter named arg exists whose value begins with a slash, treat its value as the directory. In that case, the parameter is added to the named directory hash table.
The second form of cd substitutes the string new for the string old in the name of the current directory, and tries to change to this new directory.
The third form of cd extracts an entry from the directory stack, and changes to that directory. An argument of the form +n identifies a stack entry by counting from the left of the list shown by the dirs command, starting with zero. An argument of the form -n counts from the right. If the PUSHD_MINUS option is set, the meanings of + and - in this context are swapped.
If the -q (quiet) option is specified, the hook function chpwd and the func‐ tions in the array chpwd_functions are not called. This is useful for calls to cd that do not change the environment seen by an interactive user.
If the -s option is specified, cd refuses to change the current directory if the given pathname contains symlinks. If the -P option is given or the CHASE_LINKS option is set, symbolic links are resolved to their true values. If the -L option is given symbolic links are retained in the directory (and not resolved) regardless of the state of the CHASE_LINKS option.
Das erinnert mich an das seelige Norton-CD-Command.
Das fand ich damals so praktisch daß ich es in AmigaOS nachgebaut habe. Ob mans heute noch braucht? Mal schauen.
Praktisch war übrigens daß es einen grafischen Verzeichnisbaum anzeigte wenn man es ohne Parameter aufrief. Darin konnte man navigieren und letztlich ins ausgewählte Verzeichnis wechseln.
Okay Leute, wir haben jetzt oft genug gelesen, dass das die Z-Shell auch so kann. Danke für die Info, einmal hätte vollkommen genügt, oder machen Z-Shell-Nutzer immer alles doppelt, dreifach, vierfach usw.?
Von Von der Benutzung her am Fr, 4. September 2009 um 13:03 #
" * Eine frei programmierbare Wortvervollständigung (TAB-Completion) * Die Möglichkeit, die History aus anderen gleichzeitig laufenden Shells zu nutzen * Rechtschreibüberprüfung * Nahezu vollständige Kompatibilität zur bash, ksh und tcsh * Starke Veränderbarkeit des Prompts durch Themes, u. a. die Möglichkeit, den Prompt auf die rechte Seite des Terminals zu setzen * Erweiterte Globbing-Funktionalitäten"
Aja^^ Also History aus parallel laufenden Shells zu benutzen, Rechtschreibprüfung und erweiterte Globbing-Funktionalitäten sind die Vorteile der ZSH. Also bevor ich jetzt nachgoogle, was Globbingfunktionalitäten sind, bleibe ich lieber bei der Bash.
Mal ganz im Ernst: Ich wollte wirklich einmal die ZSH ausprobieren, nach all der Beweiräucherung, die man so an jeder Stelle liest. Wirkliche Vorteile konnte ich nicht sehen. Eher die Erkenntnis, dass ich so gut wie alles neu lernen müsste, u.a. nicht in der Lage bin vernünftige Skripte zu schreiben, und die ZSH dafür definitiv viel zu schlecht dokumentiert ist.
Mag zwar sein, dass alles ein bisschen moderner ist. Aber offenbar nicht so weit fortgeschritten, als dass es nennenswert viele Leute zum Umstieg bewegt. Ich bezweifle außerdem ernsthaft, dass hier im Forum jemand in der Lage ist darzulegen, warum die ZSH im täglichen arbeiten besser ist. (Vielleicht weil kein Mensch sie hier wirklich benutzt vielleicht?!)
Ich bleibe jedenfalls bei der Bash, Skripten geht sowieso mit Perl, Ruby und Konsorten besser, da brauch ich auch keine ZSH für.
Mit der Zsh steht man direkt mit Gott in Kontakt. Alles was die Zsh anzeigt hat den Stellenwert der Lade. Die Zsh hat eine eigene Intelligenz unterwirft sich aber dem Guru vor dem Bildschirm. Das in der Zsh enthaltene Zen macht sehr glücklich. Jede Eingabe in die Zsh kann mit einem Ton bestätigt werden - umso schneller man tippt, desto mehr redet sie mit dir.
Wie oft soll find denn noch per cron job über meine Harddisk rattern? Bie mir tun es jetzt schon slocate (dessen Datenbank man wohl auch für diesen Zwecke benutzen könnte) und chkrootkit. Find verursacht einen enormen Stress für die Platte, ein Durchlauf bedeutet bei mir schon ca. 20 Minuten intensive Kopfbewegungen und natürlich starke IO-Performance Einbußen in dieser Zeit.
Desweiteren haben es gerade bei der täglichen Arbeit neu angelegte Verzeichnisse und dort gerade temporäre, die man schnell wieder löscht, an sich, daß man schnell in diese und wieder hinaus wechseln will, diese erfaßt das Skript aber gerade nicht, da hilft ein einfache cd - (wechsel ins vorherige Verzeichnis) oft wesentlich mehr.
Außerdem sind doch gerade diverse Desktop Suchmaschinen in der Entwicklung, wie z.B. Nepomuk bei KDE 4 oder Beagle oder andere bei Gnome, die solche Datenbanken ebenfalls produzieren und z.B. über inotify auch im laufenden Betrieb aktuell halten können. Ich würde denken, daß ein kleines Consolenprogramm im Umfeld dieser Projekte diese Funktionalität bsser zur Verfügung stellen könnte.
Des weiteren weiderholt dieses Skript den Sicherheitsfehler von locate, daß ebenfalls mit root-Rechten eine Datei aller Verzeichnisse anlegte, die für alle Nutzer lesbar ist: Das hebelt das Unix Sicherheitskonzept aus!
Angefangen davon, daß es wohl eine großes Hallo bei der Freundin geben wird, wenn der Ordenr p0rn/DickeTitten aus Deinem Homeverzeichnis ihr vorgeschlagen wird, bis hin zu fieseren Angriffen auf die Rechnersicherheit oder gar das Erlangen von Rootrechten z.B. durch symlink Angriffe, und damit der vollkommene Kompromittierung des Rechners.
Ich würde also soagen, daß das eine nette Idee ist, in der praktischen Umsetzung jedoch erhebliche ernste Probleme hat, die mich zumindest vom Einsatz abraten lassen.
Auch slocate hat immer noch mit Sicherheitsproblemen, wie Pufferüberläufen, ... zu kämpfen und muß diese reparieren.
Um ein Programm zu schreiben, das eben in so sicherheitsrelevaten Bereichen arbeitet (Lesen von beliebigen Verzeichnissen, Anlegen einen Datenbank mit entsprechenden Schutzvorkehrungen, Auslesen und nicht root Benutzer die Ergebnisse zur Verfügung stellen) ist schon einiges an Erfahrung und ein bisschen Aufwand nötig um nicht in die nächste Falle zu laufen.
Ich fürchte so ein Projekt elegant und sicher zu implementieren übersteigt einfach den Rahmen eines pro-linux Kurztipps.
ch würde also soagen, daß das eine nette Idee ist, in der praktischen Umsetzung jedoch erhebliche ernste Probleme hat, die mich zumindest vom Einsatz abraten lassen.
Die Idee ist erstmal gut. Vielleicht hat der Autor ja lust das Skript etwas zu verbessern: 1. Verzeichnisse in /home die nicht dem User (außer man ist root) gehören werden ignoriert. 2. Sollte ein Verzeichnis mehrfach gefunden werden, wird eine Auswahl angeboten die mittels eines Zeichens akzeptiert wird.
Mit diesen beiden Veränderungen könnte der Autor es packen und sich Ruhm erwerben!
Das löst ja nicht das Problem, daß immer noch ein Angriff via symlinks möglich ist. Dateien die root gehören in öffentlich beschreibbare und lesbare Verzeichnisse zu schreiben ist generell eine sehr schlechte Idee, insbeondere wenn deren Name leicht zu erraten oder gar festverdrahtet im Source ist.
Weiterhin sehe ich bei dem Ansatz find per cronjob aufzurufen eben immer noch das Problem, daß die aktuell erzeugten Verzeichnisse nicht berücksichtigt werden und find eine wirklich enorme IO Last verursacht. Solche Probleme haben viele Datei oder Verzeichnisindexer und ich denke nicht, daß einen weiteren hinzufügen dieses Problem entschärft.
Das Skript ist so eine nette aber naive Idee, deren sichere und elegante Umsetzung so viel Mehraufwand erfordert, daß es dann eben etwas ziemlich anderes wäre und IMHO nicht mehr in den Rahmen eine Kurztipps auf pro-linux passt.
So wie vorgeschlagen sollte das Skript nicht auf Mehrbenutzersystemen eingesetzt werden. Es wurde nur für die Arbeit eines einzelnen Benutzers konzipiert. Außerdem ist ein regelmäßiges "find" über den gesamten Verzeichnisbaum nicht effizient und, wenn es von root ausgeführt wird, sogar gefährlich.
Man sollte das find-Kommando nur als normaler Benutzer ausführen und auf sein eigenes Home-Verzeichnis beschränken. Eine Verbesserung wäre es auch, das Ergebnis von find im Home-Verzeichnis abzulegen.
Im Endeffekt bleibt es jedem Benutzer überlassen, welche Kommandos er verwendet, aber es ist jetzt hoffentlich klarer, was für Konsequenzen auftreten können.
Für diejenigen, die sich so wie ich auf ihren Servern oft nur kurz einloggen, um bestimmte häufig benötigte Verzeichnispfade anzuspringen, könnte "cdbm" auch interessant sein.
Man definiert einfach seine "Favoriten" und springt mit "c Pfad-Teilstring" dorthin:
~$ c sa /etc/samba$ _
~$ c ww /var/www$ _
Gibt es zu einem Suchbegriff mehrere Treffer, wird interaktiv gefragt:
Für alle, die die gleichen Befehle immer wieder mal wiederholen müssen, bietet sich an, die ersten Buchstaben des Befehls einzugeben und dann mit Bild_aufwärts durch gleichlautende Befehle zu scrollen...
Danke für den kurzen und hilfreichen Artikel. Ich hatte mir in den letzten Jahren eigentlich angewöhnt, möglichst wenig selbst herumzubasteln und soweit als möglich mit den üblicherweise auf _jedem_ Linux-Rechner vorhandenen Möglichkeiten zu arbeiten ohne stets etwas nach meinem Geschmack herumbasteln zu müssen. Habe daher den vorliegenden Artikel erst mal nur kurz überflogen und erst probiert als ich gerade ein bisschen zu viel Zeit hatte. Das fcd-Kommando ist aber eine Kleinigkeit bei der die Gewichtung zwischen Aufwand und Nutzen so eindeutig ist, dass sich die Minute Einrichtungsaufwand tatsächlich für jeden Rechner den man bedient lohnt.
-bash: zsh: command not found
[root@pc ~]# apt-get zsh
[...]
[root@pc ~]# zsh
[root@pc]~#
Die Z-Shell kann ein bisschen mehr.
Siehe auch man zsh.
Schau mal hier:
http://www.fixmbr.de/unix-tipp-die-z-shell-zsh/
Man kann sie selbstverständlich unter Bash aufrufen. Wenn man sie ständig nutzen will, sollte man sie allerdings in /etc/passwd verewigen.
aptitude install zsh
Gruß, ein anderer ZSH-Nutzer.
dann wird die Z-Shell bei einem "cd dir" zunaechst im aktuellen
verzeichnis nach einem unterverzeichnis "dir" suchen;
falls kein unterverzeichnis "dir" existiert, so durchsucht
die Z-Shell die verzeichnisse im pfad $CDPATH der reihe nach.
falls $CDPATH auch die angabe "." fuer das aktuelle verzeichnis
enthaelt, so wird es erst dann durchsucht, wenn die
vorhergehenden verzeichnisse bereits durchsucht wurden.
beispiel:
zsh> CDPATH=.:..:~:~/public_html:~/zshbuch.org:/usr/share/docs
hierbei wird also zunaechst explizit das
aktuelle verzeichnis (".") durchsucht,
dann das darueberliegende verzeichnis (".."), so dass
man leicht in "parallele verzeichnisse" wechseln kann:
zsh> mkdir /tmp/bar /tmp/foo
zsh> cd /tmp/foo
zsh> cd bar
zsh> pwd
/tmp/bar
danach kommt das $HOME verzeichnis dran ("~"), gefolgt
vom mit den eigenen webseiten ("~/public_html")
und dem projektverzeichnis fuer das zshbuch.
als letztes dann das verzeichnis mit
den installierten dokumentationen.
zsh> cd zsh
zsh> pwd
/usr/share/doc/zsh
bei der suche ist natuerlich auch die expansion
eines verzeichnispraefix moeglich:
zsh> CDPATH=.:~/public_html:~/talks:/etc:/usr/lib:/usr/share/doc
zsh> cd z[TAB]
~/zsh
~/zshbuch.org
~/public_html/zsh
~/talks/zsh/
/etc/zsh
/usr/lib/zsh
/usr/share/doc/zsh
/usr/share/doc/zip
/usr/share/locale/zh_CN/
/usr/share/man/zh_CN/
/usr/share/zoneinfo/
/usr/share/zsh
und wer nach /usr/share/doc/zsh wechseln moechte,
der kann das auch mit einer moeglichst eindeutigen
angabe der praefixe der einzelnen komponenten machen:
zsh> cd /u/s/d/zsh[TAB]
zsh> cd /usr/share/doc/zsh
enjoy! :)
--Sven
CDPATH existiert genauso in der bash, ebenso wie in der ksh (unter meinem geliebten HP-UX).
Ich habe noch nie mit zsh gearbeitet, nutze aber schon seit 12 Jahren die CDPATH-Variable (in ksh/HP-UX, in Suses bash, Sidux bash, Fedora, Debian, ArchLinux und Ubuntu bash). Worüber redet Ihr hier eigentlich?
Warum kommt niemand auf die Idee so etwas einfach mal zu MACHEN, anstatt immer nur darüber schlau zu schreiben? Was lernt Ihr heute eigentlich noch?
Neee, neee, neee
cd [ -qsLP ] old new
cd [ -qsLP ] {+|-}n
Change the current directory. In the first form, change the current directory
to arg, or to the value of $HOME if arg is not specified. If arg is -,
change to the value of $OLDPWD, the previous directory.
Otherwise, if arg begins with a slash, attempt to change to the directory given
by arg.
If arg does not begin with a slash, the behaviour depends on whether the cur‐
rent directory . occurs in the list of directories contained in the shell
parameter cdpath. If it does not, first attempt to change to the directory arg
under the current directory, and if that fails but cdpath is set and contains
at least one element attempt to change to the directory arg under each compo‐
nent of cdpath in turn until successful. If . occurs in cdpath, then cdpath
is searched strictly in order so that . is only tried at the appropriate
point.
If no directory is found, the option CDABLE_VARS is set, and a parameter named
arg exists whose value begins with a slash, treat its value as the directory.
In that case, the parameter is added to the named directory hash table.
The second form of cd substitutes the string new for the string old in the name
of the current directory, and tries to change to this new directory.
The third form of cd extracts an entry from the directory stack, and changes to
that directory. An argument of the form +n identifies a stack entry by
counting from the left of the list shown by the dirs command, starting with
zero. An argument of the form -n counts from the right. If the PUSHD_MINUS
option is set, the meanings of + and - in this context are swapped.
If the -q (quiet) option is specified, the hook function chpwd and the func‐
tions in the array chpwd_functions are not called. This is useful for calls to
cd that do not change the environment seen by an interactive user.
If the -s option is specified, cd refuses to change the current directory if
the given pathname contains symlinks. If the -P option is given or the
CHASE_LINKS option is set, symbolic links are resolved to their true values.
If the -L option is given symbolic links are retained in the directory (and not
resolved) regardless of the state of the CHASE_LINKS option.
Das fand ich damals so praktisch daß ich es in AmigaOS nachgebaut habe. Ob mans heute noch braucht? Mal schauen.
Praktisch war übrigens daß es einen grafischen Verzeichnisbaum anzeigte wenn man es ohne Parameter aufrief. Darin konnte man navigieren und letztlich ins ausgewählte Verzeichnis wechseln.
Bin isch rustikal, wie Opa auf der Alm... reicht mir heute Taste von TAB...
Aber jedem das Seine... Hauptsache ich muß das nicht benutzen...
lg
Erik
so kann. Danke für die Info, einmal hätte vollkommen genügt, oder machen
Z-Shell-Nutzer immer alles doppelt, dreifach, vierfach usw.?
Sehr treffender O-Post übrigens
Jopp, Datenbanken fetzen. XD
http://de.wikipedia.org/wiki/Zsh#Die_Z-Shell
* Die Möglichkeit, die History aus anderen gleichzeitig laufenden Shells zu nutzen
* Rechtschreibüberprüfung
* Nahezu vollständige Kompatibilität zur bash, ksh und tcsh
* Starke Veränderbarkeit des Prompts durch Themes, u. a. die Möglichkeit, den Prompt auf die rechte Seite des Terminals zu setzen
* Erweiterte Globbing-Funktionalitäten"
Aja^^ Also History aus parallel laufenden Shells zu benutzen, Rechtschreibprüfung und erweiterte Globbing-Funktionalitäten sind die Vorteile der ZSH. Also bevor ich jetzt nachgoogle, was Globbingfunktionalitäten sind, bleibe ich lieber bei der Bash.
Mal ganz im Ernst: Ich wollte wirklich einmal die ZSH ausprobieren, nach all der Beweiräucherung, die man so an jeder Stelle liest. Wirkliche Vorteile konnte ich nicht sehen. Eher die Erkenntnis, dass ich so gut wie alles neu lernen müsste, u.a. nicht in der Lage bin vernünftige Skripte zu schreiben, und die ZSH dafür definitiv viel zu schlecht dokumentiert ist.
Mag zwar sein, dass alles ein bisschen moderner ist. Aber offenbar nicht so weit fortgeschritten, als dass es nennenswert viele Leute zum Umstieg bewegt. Ich bezweifle außerdem ernsthaft, dass hier im Forum jemand in der Lage ist darzulegen, warum die ZSH im täglichen arbeiten besser ist. (Vielleicht weil kein Mensch sie hier wirklich benutzt vielleicht?!)
Ich bleibe jedenfalls bei der Bash, Skripten geht sowieso mit Perl, Ruby und Konsorten besser, da brauch ich auch keine ZSH für.
Alles was die Zsh anzeigt hat den Stellenwert der Lade.
Die Zsh hat eine eigene Intelligenz unterwirft sich aber dem Guru vor dem Bildschirm.
Das in der Zsh enthaltene Zen macht sehr glücklich.
Jede Eingabe in die Zsh kann mit einem Ton bestätigt werden - umso schneller man tippt, desto mehr redet sie mit dir.
Danke dafür.
cdspell, CDPATH und TAB:menu-complete hinweisen
Desweiteren haben es gerade bei der täglichen Arbeit neu angelegte Verzeichnisse und dort gerade temporäre, die man schnell wieder löscht, an sich, daß man schnell in diese und wieder hinaus wechseln will, diese erfaßt das Skript aber gerade nicht, da hilft ein einfache cd - (wechsel ins vorherige Verzeichnis) oft wesentlich mehr.
Außerdem sind doch gerade diverse Desktop Suchmaschinen in der Entwicklung, wie z.B. Nepomuk bei KDE 4 oder Beagle oder andere bei Gnome, die solche Datenbanken ebenfalls produzieren und z.B. über inotify auch im laufenden Betrieb aktuell halten können. Ich würde denken, daß ein kleines Consolenprogramm im Umfeld dieser Projekte diese Funktionalität bsser zur Verfügung stellen könnte.
Des weiteren weiderholt dieses Skript den Sicherheitsfehler von locate, daß ebenfalls mit root-Rechten eine Datei aller Verzeichnisse anlegte, die für alle Nutzer lesbar ist: Das hebelt das Unix Sicherheitskonzept aus!
Angefangen davon, daß es wohl eine großes Hallo bei der Freundin geben wird, wenn der Ordenr p0rn/DickeTitten aus Deinem Homeverzeichnis ihr vorgeschlagen wird, bis hin zu fieseren Angriffen auf die Rechnersicherheit oder gar das Erlangen von Rootrechten z.B. durch symlink Angriffe, und damit der vollkommene Kompromittierung des Rechners.
Ich würde also soagen, daß das eine nette Idee ist, in der praktischen Umsetzung jedoch erhebliche ernste Probleme hat, die mich zumindest vom Einsatz abraten lassen.
slocate existiert.
Sprich: Nur weil ein Tool aus Sicherheitsgründen erstezt wurde, bau ich ein neues unsicheres?
Um ein Programm zu schreiben, das eben in so sicherheitsrelevaten Bereichen arbeitet (Lesen von beliebigen Verzeichnissen, Anlegen einen Datenbank mit entsprechenden Schutzvorkehrungen, Auslesen und nicht root Benutzer die Ergebnisse zur Verfügung stellen) ist schon einiges an Erfahrung und ein bisschen Aufwand nötig um nicht in die nächste Falle zu laufen.
Ich fürchte so ein Projekt elegant und sicher zu implementieren übersteigt einfach den Rahmen eines pro-linux Kurztipps.
Die Idee ist erstmal gut. Vielleicht hat der Autor ja lust das Skript etwas zu verbessern:
1. Verzeichnisse in /home die nicht dem User (außer man ist root) gehören werden ignoriert.
2. Sollte ein Verzeichnis mehrfach gefunden werden, wird eine Auswahl angeboten die mittels eines Zeichens akzeptiert wird.
Mit diesen beiden Veränderungen könnte der Autor es packen und sich Ruhm erwerben!
Weiterhin sehe ich bei dem Ansatz find per cronjob aufzurufen eben immer noch das Problem, daß die aktuell erzeugten Verzeichnisse nicht berücksichtigt werden und find eine wirklich enorme IO Last verursacht. Solche Probleme haben viele Datei oder Verzeichnisindexer und ich denke nicht, daß einen weiteren hinzufügen dieses Problem entschärft.
Das Skript ist so eine nette aber naive Idee, deren sichere und elegante Umsetzung so viel Mehraufwand erfordert, daß es dann eben etwas ziemlich anderes wäre und IMHO nicht mehr in den Rahmen eine Kurztipps auf pro-linux passt.
Man sollte das find-Kommando nur als normaler Benutzer ausführen und auf sein eigenes Home-Verzeichnis beschränken. Eine Verbesserung wäre es auch, das Ergebnis von find im Home-Verzeichnis abzulegen.
Im Endeffekt bleibt es jedem Benutzer überlassen, welche Kommandos er verwendet, aber es ist jetzt hoffentlich klarer, was für Konsequenzen auftreten können.
grandioses beispiel
Man definiert einfach seine "Favoriten" und springt mit "c Pfad-Teilstring" dorthin:
~$ c sa
/etc/samba$ _
~$ c ww
/var/www$ _
Gibt es zu einem Suchbegriff mehrere Treffer, wird interaktiv gefragt:
~$ c log
[1] /var/log/samba
[2] /var/log/exim
[1-2]> 2
/var/log/exim$ _
Download: http://www.heise.de/ix/artikel/2001/01/179/
Geht natürlich auch mit cd /irgend/wo/hin
"\e[5~": history-search-backward
"\e[6~": history-search-forward
Ansonsten Ctrl+R
..im vi-mode. Anschliessend `n' für next und `N' für previous.
Funktioniert auch in älteren Korn-Shells.
Ich hatte mir in den letzten Jahren eigentlich angewöhnt, möglichst wenig selbst herumzubasteln und soweit als möglich mit den üblicherweise auf _jedem_ Linux-Rechner vorhandenen Möglichkeiten zu arbeiten ohne stets etwas nach meinem Geschmack herumbasteln zu müssen. Habe daher den vorliegenden Artikel erst mal nur kurz überflogen und erst probiert als ich gerade ein bisschen zu viel Zeit hatte.
Das fcd-Kommando ist aber eine Kleinigkeit bei der die Gewichtung zwischen Aufwand und Nutzen so eindeutig ist, dass sich die Minute Einrichtungsaufwand tatsächlich für jeden Rechner den man bedient lohnt.
Danke!