mensch183 schrieb:
... was man nicht möchte.
Was Du nicht möchtest! Mach ich seit über 30 Jahren so. Wenn man als Admin nicht weiß, was man da tut, klar, dann sollte man es lassen. Mich nervt es immer, extra ./ angeben zu müssen.
@Troublegum
~/bin würde ich nicht als PATH nehmen, immer lieber einen absoluten Pfad, und ab besten über eine Variable.
Code:
# set PATH so it includes user's private bin if it exists
if [ -d $HOME/.bin ] ; then
PATH=$HOME/.bin:"${PATH}":.
export PATH
fi
Code:
MYBIN=$HOME/bin
# set PATH so it includes user's private bin if it exists
if [ -d $MYBIN ] ; then
PATH=$MYBIN:"${PATH}":.
export PATH
fi
Ist aber alles letztlich geschmacks- und stilfrage. Genau so wie mit dem . am Ende. Wenn Du viel tippst und viele Befehle verwendest, dann mache in rein. Wenn Du Schiß hast, wie die anderen hier, laß es. Vorteil mit dem Punkt wäre, daß der Befehl dann bei bash mit TAB ergänzt wird, ohne daß Du jedesmal extra ./ tippen mußt.
@all
Und wer ganz paranoid ist, und sich über den . im Pfad aufregt, er sollte von allen das executable-flag entfernen, und alles nur mit
ausführen.
mensch183 schrieb:
Mach dir nicht so viele Sorgen um irgendwelche "Standards". Mach was funktioniert. Insbesondere ist alles in deinem Homeverzeichnis deine Sache. Nur füge bitte nicht "." (das aktuelle Verzeichnis) zur PATH-Variable hinzu, auch nicht am Ende.
Und warum nicht?
Es bringt kaum einen Sicherheitsnutzen, wenn man es wegläßt. Aber es bringt sehr viel Bequemlichkeit in das tägliche Arbeiten, wenn Du mit vielen verschiedenen Befehlspfaden arbeiten mußt (welche nicht im PATH sind). Wie gesagt, wer nicht weiß, was er da tut, sollte es dann lieber ganz lassen. Man kann auch viele Pfade im PATH unterbringen, daß ist dann genauso unsicher oder sicher wie :.