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:

# Setze den Prompt auf 'user@hostname:verzeichnis$ ' PS1='\u@\h:\w\$ ' # Auf einem Xterm setze auch die Titelzeile # Funktioniert auch mit putty case $TERM in xterm*) PROMPT_COMMAND='echo -ne "\033<<Wie mache ich hier eine eckige Klammer?>>0;${USER}@${HOSTNAME}: ${PWD}\007"' ;; *) ;; esac

Diesen Abschnitt (und alle anderen UI-Änderungen) sollte man durch ein

if [ "$PS1" ]; then # ... fi

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'

Huh? Das geht doch viel einfacher! Ich habe einfach

   set prompt = "< %m:%~ > "

   set prompt = "%{\e[0;39m%}%{\e[1;41m%}< %m:%~ >%{\e[m%} " 

Besser nicht. Alternativen und Diskussion weiter unten.

    export PATH=.:$PATH

 Syntax   :  aaa:bbb:ccc
 WD vorne : :aaa:bbb:ccc
 WD hinten:  aaa:bbb:ccc:
 WD mitte :  aaa:bbb::ccc

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

Interessant. Warum ist es verpönt? --hl

Ich denke für einen Normalbenutzer=Nichtentwickler hat es wirklich wenig Sinn, das aktuelle Verzeichnis in den PATH zu geben. Für einen Entwickler hat es aber viel Sinn das pwd an den Anfang von PATH zu geben, weil er oft in den Entwicklungsverzeichnissen neue oder gleichnamige veränderte Versionen erzeugt und testet. -- hl

Hast du konkrete Links für mich, wo ich weitersuchen und diesen Bedenken auf den Grund gehen kann? -- hl

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

Was für root manchmal böse enden kann.

# cd /home/badboy # ls Login:

"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:

• Kein ./cmd mehr

• untransparentes Überschreiben der Funktionalität von Standardtools durch lokale Varianten
• Normalbenutzer sollten keine lokalen Kommandos brauchen

Ausführbare Programme sollen zuletzt im aktuellen Verzeichnis gesucht werden:

Pro:

• Kein ./cmd mehr

• Entspricht nicht den Erwartungen: Binary vorhanden => Binary wird ausgeführt
• Ein Entwickler, der lokal an einer neuen Version eines global installierten Tools (Standardtools, Applikation) arbeitet, spart sich das ./cmd nicht.

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:

• Es ist vorstellbar, dass mit mcs -p die .comment-Section der Exe gelesen wird, um festzustellen, ob es sich um ein Original-AT&T-Tool handelt - mit jeweils unterschiedlicher Reaktion!
• Man hat ein eigenes grep, das eine Kopie ist aber eine zusaetzliche Option kennt. Das wird woanders aufgerufen: grep -q '-Zi3f' datei .... Jedoch -Z ist diese zusaetzliche Option, die das Original nicht kennt!
• Man muss damit rechnen, dass Ausgaben von Kommandos an beliebiger Stelle analysiert, veraendert und teilweise gespeichert werden, wobei wiederum andere Kommandos Bezug auf das Gespeicherte nehmen. Wenn dabei die Ausgabe des eigenen Toolersatzes auch nur geringfuegig abweicht - kann man bereits 'den Eier-Salat' haben!

Wenn dieser User irgendein Systemkommando aufruft und dieses wiederum ein Standardtool aufruft, wird das gleichnamige Tool in diesem privaten ~/bin/ ausgefuehrt! Es sei denn, das Systemkommando verwendet volle Pfadnamen.--hs

... oder setzt seinen privaten Pfad korrekt. Generell hast Du recht, Usern die Schrott in ihrem ~/bin/ lagern, können schwer diagnostizierbare Probleme wiederfahren.

Ist mir mal passiert als ich in /usr/local/bin/ eine alte Version eines Tools herumliegen hatte und ein Update des offiziellen Pakets ums verrecken nicht die gewünschte Erfolge zeigen wollte. -- DavidSchmitt