Rezepte | ![]() |
Prompt soll das aktuelle Verzeichnis anzeigen:
Unter DosWindows ist man gewohnt, dass die Kommandozeile das aktuelle Verzeichnis anzeigt. Ähnlich dem Befehl "prompt=$p$g" in autoexec.bat gibt es in den UNIX Shells Mechanismen um den Prompt zu verändern:
Für die bash kann man folgendes Fragment in das .bashrc einfügen:
![]() |
|
Diesen Abschnitt (und alle anderen UI-Änderungen) sollte man durch ein
![]() |
|
schützen, damit bei nicht-interaktiven Aufrufen der Shell keine ungewünschten Interferenzen passieren.
Vielleicht sollte man das nach /Rezepte/Shell? verschieben? --DS
Einsteigererfahrungen | ![]() |
Prompt soll das aktuelle Verzeichnis anzeigen:
Andere Shell-Varianten können ganz andere Lösungen erfordern. Mit tcsh habe ich z.B. folgende Befehle in .cshrc:
alias setprompt 'set prompt="$USER ${cwd}% "' setprompt alias cd 'chdir \!* && setprompt'die etwa das gleiche bewirken.
Huh? Das geht doch viel einfacher! Ich habe einfach
set prompt = "< %m:%~ > "im .tcshrc. Naja, nicht ganz. Eigentlich heissts:
set prompt = "%{\e[0;39m%}%{\e[1;41m%}< %m:%~ >%{\e[m%} "Da kann man beim Zurückscrollen das letzte Kommando leicht finden.
export PATH=.:$PATH(hs:Nach Kenntnis loeschen:)
Syntax : aaa:bbb:ccc WD vorne : :aaa:bbb:ccc WD hinten: aaa:bbb:ccc: WD mitte : aaa:bbb::cccMerken: Redundanz des ':'. Den . braucht man nicht!
Fortgeschrittenenkommentare | ![]() |
Es ist unter Unix sogar verpönt, das aktuelle *überhaupt* in den PATH aufzunehmen! Ich mache es hinten:
Ein redundanter(!) : vorne oder hinten reicht aus, um es als erstes oder letztes in den PATH aufzunehmen. --hs
Demonstration | ![]() |
Sämtliche ausführbaren Programme/Scripts, die direkt oder indirekt /(von daemon) gestartet werden und nicht mit vollen Pfaden arbeiten, führen blind alles passende aus im jeweiligen aktuellen Verzeichnis, in dem man gerade steht.--hs
![]() |
|
"Aha, unter anderem ein ausführbares ls, das die Passwörter irgendwohin mailt, das root-Passwort ändert und mich ausloggt..."
Pro und Con wd im Path | ![]() |
Hmm; schauen wir mal was sich da zusammenfassen läßt:
Ausführbare Programme sollen zuerst im aktuellen Verzeichnis gesucht werden:
Pro:
Ausführbare Programme sollen zuletzt im aktuellen Verzeichnis gesucht werden:
Pro:
Expertenkommentare | ![]() |
Alternative: ein ~/bin Verzeichnis als erstes in den Pfad aufnehmen und dort alles notwendige verstauen/verlinken. Dadurch hat man eine wesentlich bessere Kontrolle und verringert die Chancen für Unbefugte dort Dateien einzuspielen. Ausserdem ist es besser überschaubar.
Programme, die sich öfters ändern, können z.B. über SymbolischeVerweise eingebunden werden.
Working Directory im PATH:
Die beste Loesung ist eindeutig, es durch ...aaa:bbb:ccc:eee: als letztes aufzunehmen.
Im Anlieferzustand oder nach Erzeugung eines neuen Users sollte es (zunächst) gar nicht aufgenommen sein.
Wer es später aufnimmt, ist in aller Regel kein Anfänger, sondern jemand, der weiss, was er da tut.
Wer es vorne hat, um Systemtools zu entwickeln und ohne ./ aufrufen zu können, muß ja dauernd /usr/sbin/xyz, /usr/bin/xyz, /bin/xyz, /sbin/xyz aufrufen, um das jeweilige Original (beispw. zum Vergleich) aufzurufen - das ist dumm.
Wer eigene, gleichnamige Systemtools entwickelt (wer entwickelt denn überhaupt ls, test, tr, sed, awk, dd, cp, mv, rm, uniq, paste, head, tail, sh, etc. nochmals selbst?!) sollte diesen eben nicht den gleichen Namen geben! - Keinesfalls!
Man sollte niemals in solcher Weise das System verändern!
Denn diese Tools werden in vielen der beispw. tausenden mitgelieferten Scripts verwendet, wobei man damit rechnen muss, daß feinste Details eine Rolle spielen.
Wer eigene Systemtools entwickelt, sollte sie beispielsweise -andersnamig- tr. dd. cp. nennen, auch in einem eigenen ~/bin.
Eigenes bin/ vorne: zu gefährlich! Eigenes bin/ hinten: gleichnamige darin werden nicht aufgerufen. --hs
Annahme: Man hat eine perfekte Kopie eines Standardtools programmiert: