Hi Leute,

wenn ich einen Befehl eingebe in Terminal (s.u.), bekomme ich immer die selbe Antwort: "command not found".

"Last login: Wed Feb 24 23:35:22 on console

iMac:~ kix$ nano ~.bash_profile

-bash: nano: command not found

iMac:~ kix$"

Wo sucht denn die Shell, dass sie nix mehr findet?

gib mal
ein. Da siehst du die Pfade, in denen die Shell sucht. Da sollte /usr/bin drin stehen, da liegt nämlich nano.

Abgesehen davon was perestroika schon sagte, hieße es:

(Du hast den Slash vergessen fürs Heimatverzeichnis)

Darüberhinaus bekommst Du mit
sämtliche Umgebungsvariablen angezeigt, die Dir in der betreffenden Shell zur Verfügung stehen, u.a. auch $PATH.

was passier wenn du das hier eingiebst?

Ev. funktioniert es mit pico ~/.bash_profile

oder mit vi

senf dazugeben:

oder mit Emacs (/usr/bin/emacs)


Haben wir nun bald alle Haus- und Hof-Editoren durch?

ed und joe?
(edit: 1mio Editoren vorschlagen hilft vmtl. nicht weiter, wenn der path leer ist oder?)

Das ist richtig. Dann sollte der Fragesteller so langsam dazu übergehen nachzuforschen, warum denn $PATH möglicherweise leer ist.
Und wenn dem so sein sollte, dass $PATH leer ist, dann dürfte ein ziemlicher GAU vorliegen, dann dürfte im System so Einiges nicht mehr funktionieren, denn das System selber dürfte dann wichtige Unix-Programme nicht mehr finden, die es zum Betrieb und Selbsterhalt benötigt und schlicht und einfach finden muss.

Zu alledem, insbesondere ob $PATH denn nun tatsächlich leer ist oder nicht, hat sich der Fragesteller bisher nicht geäußert.

NB

nano gibt es bei Apple erst seit Tiger

pico

nano

Hi,
Danke für Eure Hinweise.

Ich habe (bis jetzt) die ersten drei vorgeschlagenen Befehle von perestroika, sierkb und onicon eingegeben (s.u.), die weiteren folgen noch:

"Last login: Thu Feb 25 10:43:25 on console
iMac:~ kix$ echo $PATH
usr/bin:/bin:/usr/sbin:/usr/local/bin:/usr/X11/bin:/Users/kix/Skripten
iMac:~ kix$ env
-bash: env: command not found
iMac:~ kix$ /usr/bin/nano [enter]
iMac:~ kix$"

Vor usr/bin fehlt ein "/". Solltest du ihn nicht nur beim Kopieren vergessen haben, erklärt das dein Problem.

dirac:

+1

kix:
Eigenartig.

Was sagt
?
Kommt da als Antwort nicht /usr/bin/env?
Kommst Du zu einem anderen Ergebnis, wenn Du /usr/bin/env eingibst?

Wenn dem so sein sollte, könnte es sein, dass es auf dem beruht, was dirac zuvor schon bemerkt hat ("/").

Dasselbe müsste Dir dann auch bzgl. nano passieren (bzw. ist es ja auch).

Deine $PATH-Variable ist offenbar also beschädigt bzw. unkorrekt. Normalerweise kannst Du sie an der Stelle gar nicht ändern, sondern nur root kann das.
Festgelegt ist dieser Bestandteil der $PATH-Variablen in der Datei /etc/paths.

Rechte:

Ihr Inhalt müsste so aussehen (less /etc/paths):


Wenn sie bei Dir anders aussehen sollte (aus welchen Gründen auch immer Du da möglicherweise dran herumgefummelt haben magst, da frag' ich lieber nicht nach ) -- also z.B. dort an erster Stelle usr/bin statt /usr/bin da an erster Stelle stehen sollte, so korrigiere das mit einem Editor Deiner Wahl und als Admin mit erlangten root-Rechten via su bzw. sudo.

Soeben habe ich die nächsten Tipps von _mäuschen, macdevil, void und sierkb eingegeben (s.u.):

"Last login: Thu Feb 25 13:36:18 on ttys000

iMac:~ kix$ pico ~/.bash_profile
-bash: pico: command not found

iMac:~ kix$ vi ~/.bash_profile
-bash: vi: command not found

iMac:~ kix$ open /Applications/TextEdit.app ~/.bash_profile
-bash: open: command not found

iMac:~ kix$ emacs ~/.bash_profile
-bash: emacs: command not found

iMac:~ kix$"

Das zeigt mir Terminal nur auf meinem Admin-Account an, denn im Benutzeraccount führt Terminal die Befehle aus. Ich arbeite mit einem iMac PPC G5 und 10.5.8.

kix:

Bitte beherzige mal diracs letzte Frage und auch mein letztes Posting, bevor Du irgendwas weiter versuchst.

Ergänzende Frage: wie genau hast Du den Pfad /Users/kix/Skripten ans Ende Deiner PATH-variablen hinzugefügt? Was hast Du dazu gemacht/verändert bzw. wo hast Du diese Information dafür abgelegt? Möglicherweise ist bei diesem Vorgang die Ursache zu suchen, bzw. Du hast bei diesem Vorgang durch Unvorsicht irgendwas falsch bzw. kaputtgemacht.

Geht viel einfacher

oh interessant^^ (braucht man aber eig beides nicht)

kix
führ doch bitte mal wie von dirac und sierkb beschrieben folgendes aus:

sollte die Ausgabe so aussehen:

...dann liegt der Fehler am fehlenden Slash am Anfang der ersten Zeile.
Sollte das der Fall sein, füge ihn hinzu, indem du als Administrator folgendes ausführst:

P.S.: Achtung! du kannst viel kaputt machen, wenn du hier fehlerhafte Werte einträgst. Wenn du dir unsicher bist, frag lieber nochmal nach

gebe mal das ein..... bei meinem weibe funktioniert es ganz gut. in verbindung mit neuen schuhen sogar sehr viel schneller...

open /bier/aufmachen/einschütten/austrinken/zisch ~/.bash_prost

void:

Und was hast Du nun Anderes gesagt als ich? Außer dass Du statt /usr/bin/less nun /bin/cat zum Anzeigen von /etc/paths genommen hast?


Dann sollte er das ändern. Denn dann hätte er an einer Datei herumgepfuscht, an der er gar nicht erst hätte herumpfuschen sollen/dürfen.
Erstens sollte er dann usr/bin den Slash wieder zurückgeben, also zu /usr/bin korrigieren, und zweitens gehört, sollte das an der Stelle wirklich so aussehen, weder der Pfad /usr/X11/bin dort hinein noch und am allerwenigsten der Pfad /Users/kix/Skripten.

Für Pfade, die systemweit ans Ende der $PATH-Variablen hinzugefügt werden sollen, gibt's extra ein Verzeichnis namens /etc/paths.d. Dort liegt dann z.B. eine Datei mit dem Namen X11, welche als einzige Zeile den Pfad /usr/X11/bin enthält.
Gleiches bzgl. des anderen Pfades. Diesbzgl. sollte dann eine Datei z.B. namens kix existieren, welche dann als einzige Zeile den Pfad /Users/kix/Skripten enthält (wenn letzterer Pfad überhaupt systemweit und für jeden Benutzer zur Verfügung gestellt werden soll und nicht allein nur für den Benutzer kix. In dem Falle wäre es dann nämlich sinnvoller, den Pfad in der ~/.bash_profile des Heimverzeichnisses mit an das Ende der PATH-Variable dranzuhängen).

Mit getconf PATH kann er sich den PATH genau so darstellen lassen, wie er in /etc/paths definiert ist, sie dazu auch die Manpage von getconf bzw. online: .

Das automatische Dranhängen der systemweit gültigen Pfade, welche sich ggf. im Verzeichnis /etc/paths.d befinden an die PATH-Umgebungsvariable, das erledigt das Programm path_helper (/usr/libexec/path_helper), manpage dazu: man path_helper bzw. online ). Initiiert wird das über die /etc/profile Datei.

Gleiches geschieht mit dem in der MANPATH-Umgebungsvariablen festgelegten Suchpfad für die Manpages via /etc/manpaths und /etc/manpaths.d.


Soweit waren wir bisher auch schon.

Das kann er machen und halten wie ein Dachdecker, mit welchem Editor er das letztlich ändert, Beispiele und Variationsmöglichkeiten sind oben ja genug genannt worden (er hat es ja, wenn dem so sein sollte, das wissen wir ja bisher nicht, auch geschafft, diese Datei vorher verändern zu können, also wird er bereits wissen, wie man sie editiert). Macht er's an den betreffenden Stellen systemweit, dann muss er das mit root-Rechten machen, die er sich z.B. via sudo beschafft (Voraussetzung dafür: er ist ein Benutzer mit Admin-Rechten, denn der darf standardmäßig unter MacOSX nur dieses sudo-Kommando absetzen, alle anderen Benutzer haben gar keine Berechtigung dazu, das su- bzw. sudo-Kommando überhaupt erfolgreich durchführen zu dürfen).

Das alles unter der Voraussetzung, dass /etc/paths tatsächlich vom Fragesteller verändert bzw. fehlerhaft verändert wurde und die Ursache genau dort zu suchen ist und nicht vielleicht doch woanders.

dirak:
Das "/" vor usr/bin fehlt tatsächlich auf den Befehl echo $PATH hin und ich habe anschließend die drei Tipps von sierkb eingegeben (s.u.).


"Last login: Thu Feb 25 19:44:37 on console
iMac:~ kix$ echo $PATH
usr/bin:/bin:/usr/sbin:/usr/local/bin:/usr/X11/bin:/Users/kix/Skripten

iMac:~ kix$ which env
-bash: which: command not found

iMac:~ kix$ /usr/bin/env
MANPATH=/usr/share/man:/usr/local/share/man:/usr/X11/share/man
TERM_PROGRAM=Apple_Terminal
TERM=xterm-color
SHELL=/bin/bash
TMPDIR=/var/folders/kf/kfwGkUbjH4WxhWRnYYrJsk+++TI/-Tmp-/
Apple_PubSub_Socket_Render=/tmp/launch-cS1V4w/Render
TERM_PROGRAM_VERSION=240.2
USER=kix
COMMAND_MODE=unix2003
SSH_AUTH_SOCK=/tmp/launch-EE28Xy/Listeners
__CF_USER_TEXT_ENCODING=0x1F5:0:3
PATH=usr/bin:/bin:/usr/sbin:/usr/local/bin:/usr/X11/bin:/Users/kix/Skripten
PWD=/Users/kix
LANG=de_DE.UTF-8
SHLVL=1
HOME=/Users/kix
LOGNAME=kix
DISPLAY=/tmp/launch-zwIKOD/:0
SECURITYSESSIONID=273e990
_=/usr/bin/env

iMac:~ kix$ ls -l /etc/paths
-rw-r--r-- 1 root wheel 45 25 Sep 2008 /etc/paths

iMac:~ kix$ less /etc/paths
-bash: less: command not found

iMac:~ kix$"

Er will Skripten und schafft nicht mal

_mäuschen:

+1

Jetzt habe ich im Terminal den Tipp von void ausführen lassen (s.u.).

"Last login: Thu Feb 25 21:38:56 on console

iMac:~ kix$ /bin/cat /etc/paths
/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin

iMac:~ kix$"

Hab ich ja nie behauptet, hab nur nochmal die Schritte idiotensicher (absolute Pfadangaben *hust*) zusammengefasst, da ja bisher noch keine Antwort kam. Dies könnte z.B. daran liegen, dass kix mit deiner Frage nach "which env" nicht klarkommt, da "which" selbst ja auch unter dem "vermissten Pfad" liegt.

Ok deine /etc/paths-Datei ist so wie sie sein sollte.

Hast du eventuell eine .profile oder .bash_profile Datei in deinem Benutzerverzeichnis? (Ja nach der .bash_profile Datei wurde schon mehrfach gefragt, ich weiß!)

Das das klappt, ist auch kein Wunder, wenn Du /bin/cat direkt eingegeben hast. Und wenn Du nur cat eingegeben hättest, dann hätte das sicher auch geklappt. Weil cat im /bin-Pfad liegt, und der /bin-Pfad in Deiner PATH-Variablen auch korrekt konfiguriert ist.

Mein Beispiel mit less hätte sicher ebenfalls geklappt, wenn Du den direkten Pfad /usr/bin/less angegeben hättest statt lediglich nur less. Mein Beispiel mit less hat bei Dir sicher deshalb so nicht geklappt, weil less im /usr/bin-Pfad liegt, genau dieser aber in Deiner PATH-Variablen nicht korrekt konfiguriert war und das System folglich von alleine auch nix in /usr/bin finden konnte, also konnte es auch nicht less finden.

Jetzt, wo Du den Fehler in /etc/paths offenbar korrigiert hast (oder etwa nicht?), müsstest eigentlich auch alle obigen Versuche und Beispiele, die bisher fehlgeschlagen sind, erfolgreich absolvieren können.

Jetzt ist sie, wie sie sein sollte. War sie das auch bisher und schon immer so? Oder hat er sie inzwischen korrigiert, und sie sah bisher ganz anders aus? Lag's daran? Oder nicht? Bisher hat er sich noch nicht dazu geäußert, sondern hat lediglich bestätigt, dass bei ihm wohl kein Tippfehler bzw. Copy&Paste-Fehler vorgelegen hat. Also wir guten Grund zur Annahme haben durften/dürfen, dass seine /etc/paths-Datei an der entspr. Stelle tatsächlich nicht das drinstehen hat(te), was drinstehen sollte.

Hat er nicht genau eine solche im Eingangsposting öffnen oder erstellen wollen?
Wenn er eine hat, und da steht dann fäschlicherweise drin, dass er usr/bin noch vor die systemseitige PATH-Variable setzen möchte, dann müsste in seinem Pfad dann aber wenigstens und trotzdem noch zusätzlich und kurz danach /usr/bin auftauchen. Erst recht, wenn er das hinter die bisherige PATH-variable gesetzt hätte. Völlig egal, in welcher Art von profile-Datei oder ~/.bashrc-Datei er das getätigt hätte: die systemseitig und zentral festgelegten Pfade hätte er damit höchstens ergänzt, aber nie überschrieben. Dass er das bisher offenbar nicht getan hat bzw. da offenbar was überschrieben worden ist, nährt ganz stark die Vermutung, dass er an zentraler Stelle, nämlich an /etc/paths geschraubt hat und dort zentral einen falschen Pfad (nämlich ohne das "/" für /usr/bin) eingetragen hatte.

Ich frage mich bei dem Ganzen, wen nes denn so gewesen sein sollte: wie hat er das bloß hinbekommen? Nur root kann /etc/paths ändern! Und um root zu werden, bedarfs der einen oder anderen Hürde. Und die muss man wissen und auch wissen, was man da tut. Und wenn er selbst das geschafft hat, warum er sich bislang so dämlich und begriffsstutzig anstellt, die Ursache zu finden und schnell zu fixen?

Wenn es denn alles mit /etc/paths und dort vorgenommenen Änderungen zusammenhängt.

Aber selbst darüber gibt er ja keine Auskunft. Ich vermisse ein ganz klares "Ja, ich habe da mal dran herumgeschraubt!" bzw. ein "Ja, daran hat es wohl gelegen". Oder auch ein klares "Nein, daran habe ich nie und zu keiner Zeit herumgeschraubt, daran kann es nicht liegen!"
Es ist immer noch ein völliges Tappen im Dunkeln nicht zuletzt auch für uns. Und so langsam wird's echt mühselig und unlustig für einen Helfenden, wenn derart unklare Antworten seitens des Fragestellers kommen.

Nicht ganz korrekt - su kannst du auch als Otto-Normalnutzer verwenden und dich damit in einen anderen Benutzer, auch einen mit Adminrechten, verwandeln, von wo aus du dann sudo-Befehle ausführen kannst.

Ja, Du hast damit vollkommen recht. Danke für die Korrektur. Als mir der Fehler auffiel, war das 5 Minuten-Zeitfenster schon um, um's korrigieren zu können. Ich bezog mich bei der von Dir herangezogenen Aussage bzgl. su allein auf su root.

Wäre es anders als Du sagst, wäre es einem normalen Standardnutzer auf der Shell ja nie möglich, z.B. in die Rolle und die Shell eines Nutzers zu schlüpfen, der mit mehr Rechten ausgestattet ist (z.B. die des Admin-Nutzers), um von dort aus dann in die Rolle des Superusers root zu schlüpfen.

Von daher: Danke für die Richtigstellung.

almdudi:

Ergänzung:
Ausnahme: der betreffende Benutzer steht in der /etc/sudoers extra drin, dann darf auch er ggf. ein sudo-Kommando bzw. su root absetzen. Wenn es dort drin konfiguriert ist. Und da steht der Standardnutzer bzw. normale Nutzer normalerweise aus gutem Grund nicht drin bzw. hat aus gutem Grund diese Rechte nicht erteilt bekommen. Diese Datei überhaupt nur lesen zu können, das ist alleiniges Recht von root bzw. der root-Gruppe wheel (fürs Ändern ist da mangels Schreibrechten selbst für root und wheel auch nochmal ein Riegel vorgeschoben bzw. root sollte/muss eine solche Änderung nur mit dem speziell dafür vorgesehenen visudo tun).

Aber nur wenn Otto-Normalnutzer das Passwort des anderen Benutzers kennt.

oder errät.

back to topic?

Und wie ohne weitere Beiträge des TE?
Da müssen wir schon warten, bis er wieder am Rechner sitzt.

oder raten.

void:
Gegen 0:39 vor einem Jahr wurde wohl was angelegt (im Zusammenhang mit der Compilierung vom App. Scribus 135 war das, aber die Version war nicht lauffähig auf dem ppc) (s.u.).

sierkb:
Ich habe bisher noch nichts korrigieren können und habe weiterhin Deine/Eure Tipps abgearbeitet (s.u.).

Und, nein, ich habe nirgendwo herumgeschraubt, weil Anfänger am Terminal.


"Last login: Fri Feb 26 14:53:12 on console

iMac:~ kix$ /bin/ls -1a ~ | /usr/bin/grep profile
.bash_profile
.profile
.profile.macports-saved_2009-04-27_at_00:39:14

iMac:~ kix$ echo $PATH
usr/bin:/bin:/usr/sbin:/usr/local/bin:/usr/X11/bin:/Users/kix/Skripten

iMac:~ kix$ env
-bash: env: command not found

iMac:~ kix$ /usr/bin/nano [enter]

iMac:~ kix$ pico ~/.bash_profile
-bash: pico: command not found

iMac:~ kix$ vi ~/.bash_profile
-bash: vi: command not found

iMac:~ kix$ open /Applications/TextEdit.app ~/.bash_profile
-bash: open: command not found

iMac:~ kix$ emacs ~/.bash_profile
-bash: emacs: command not found

iMac:~ kix$ which env
-bash: which: command not found

iMac:~ kix$ ls -l /etc/paths
-rw-r--r-- 1 root wheel 45 25 Sep 2008 /etc/paths

iMac:~ kix$ less /etc/paths
-bash: less: command not found

iMac:~ kix$ open -e ~/.bash_profile
-bash: open: command not found

iMac:~ kix$ /bin/cat /etc/paths
/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin

iMac:~ kix$ export PATH=$PATH:/Users/kix/Skripten

iMac:~ kix$"

Was steht denn in den drei profile-Dateien so drin?

kix:

Und was genau steht nun in Deiner ~/.profile Datei und in der ~/.bash_profile Datei drin (die andere ist eine Backup-Datei, angelegt von MacPorts)? Ist evtl. noch zusätzlich eine ~/.bashrc Datei vorhanden, wo was drinsteht?

Und da Du MacPorts installiert zu haben scheinst --
da kann dann ja wohl höchstens sowas drinstehen wie z.B.:

MacPorts setzt also seine Pfade vor den bisherigen System-Pfad, über den wir hier schon lang und breit gesprochen haben. Stände das, durch einen Doppelpunkt getrennt, hinter der bisherigen PATH-Variablen, so würde der MacPorts-Suchpfad ans Ende des bisherigen Suchpfades gehängt.

Aber keinesfalls wird dadurch der bisherige systemweit festgelegte Suchpfad überschrieben oder in seinen Bestandteilen verändert.

Das alles ist aber auch wunderschön in der MacPorts-Doku erläutert und erklärt. Bzw. steht auch in den Release-Notes zu MacPorts drin.

Was genau steht bei Dir denn in der ~/.profile Datei und in der ~/.bash_profile Datei denn eigentlich drin? Du weißt schon noch, das Du eigentlich nur eine von beiden benötigst? Die ~/.bash_profile ist die profile-Datei für die Bash, also die unter MacOSX für alle normalen Nutzer eingerichtete Standard-Shell. Die ~/.profile Datei ist eine allgemeine profile-Datei, die für jede Shell gültig ist, also nicht nur für die Bash, sondern z.B. auch für eine evtl. eingerichtete/konfigurierte andere Shell.
Die ~/.profile Datei ist deshalb immer und unter jeder Shell gültig. Die ~/.bash_profile Datei ist nur unter der Bash gültig.

Es gibt eine bestimmte Reihenfolge, in der diese Dateien von der Shell abgearbeitet werden:

Siehe auch dazu z.B. und (es gibt sicher bessere Quellen, die hier auf die Schnelle).

Die Datei ~/.profile ist somit ein Fallback. Sie wird dann abgearbeitet, wenn keine andere profile-Datei gefunden werden kann.

Stehen in Deinen beiden profile-Dateien vielleicht irgendwelche Infos, die sich ins Gehege kommen? Der Übersicht halber solltest Du Dich mal auf eine festlegen, also meinetwegen den Inhalt der ~/.profile reinkopieren in die ~/.bash_profile und dann meinetwegen die ~/.profile löschen. Wenn da nicht eh redundantes Zeug drinsteht.

Und wenn dort irgendwo z.B. ein fehlerhafter usr/bin-Pfad drinstehen sollte, dann solltest Du das korrigieren bzw. eigentlich kannst Du es ganz rausnehmen, weil /usr/bin eigentlich schon im System-Pfad richtig drinstehen sollte. Selbst wenn dort ein fehlerhafter usr/bin-Pfad stehen sollte, das System müsste eigentlich bei der Suche sich am kompletten Pfad entlanghangeln und spätestens dort auf Erfolg stoßen, wo /usr/bin systemseitig und korrekt im Pfad angegeben ist.

Ich schwimme also im Moment etwas, so langsam weiß ich nicht, wo und an welcher Stelle da bei Dir die Ursache verortet werden kann, wenn Du ausschließt, dass die systemweite Datei /etc/paths falsche Angaben enthält. Denn spätestens mit den Angaben in der Datei müsste das System auf einen korrekt in die PATH-Variable eingebrachten /usr/bin-Pfad treffen, egal was vorher und hinterher an den Pfad (z.B. durch MacPorts via ~/.profile oder ~/.bash_profile) noch vorne oder hinten drangehängt worden ist. Wenn dort an dieser zentralen Stelle (also /etc/paths) nichts verändert worden ist und diese Pfade, die da drinstehen, alle korrekt sind, dann weiß ich grad' auch nicht so richtig, wo man noch suchen sollte.

dirac und sierkb:
Ja, letztendlich habe ich soeben in der Datei "~/.bash_profile" die mal von mir eingegebene (und vergessene) Anweisung
"export PATH="/usr/bin:/bin:/usr/sbin:/usr/local/bin:/usr/X11/bin:/Users/kix/Skripten"
wiedergefunden und gelöscht.

Und danke an Alle für eure Hinweise. Jetzt findet die Shell wieder den Pfad zu den Ordnern, in denen die ausführbaren Dateien sind (s.u.).


"Last login: Fri Feb 26 19:48:09 on ttys000

iMac:~ kix$ export PATH="/usr/bin:/bin:/usr/sbin:/usr/local/bin:/usr/X11/bin:/Users/kix/Skripten"

iMac:~ kix$ export PATH="/usr/bin:/bin:/usr/sbin:/usr/local/bin:/usr/X11/bin"

iMac:~ kix$ ~/.bash_profile
-bash: /Users/kix/.bash_profile: Permission denied

iMac:~ kix$ ~/.profile
-bash: /Users/kix/.profile: Permission denied

iMac:~ kix$ sudo ~/.profile
Password:
sudo: /Users/kix/.profile: command not found

iMac:~ kix$ sudo ~/.bash_profile
sudo: /Users/kix/.bash_profile: command not found

iMac:~ kix$ ~/.bashrc
-bash: /Users/kix/.bashrc: No such file or directory

iMac:~ kix$ nano ~/.bash_profile

iMac:~ kix$ echo $PATH
/usr/bin:/bin:/usr/sbin:/usr/local/bin:/usr/X11/bin

iMac:~ kix$ Apple's Latest Creation
> env"

In Zukunft erweiter deinen Pfad nur noch in der von sierkb beschriebenen Art und Weise, indem du durch Doppelpunkt getrennt deinen eigenen Pfad an die PATH-Variable anhängst (ob du ihn vorne oder hinten anhängst entscheidet dann, welches Programm gestartet wird, wenn es eine gleichnamige Datei an verschiedenen Orten geben sollte).
.bash_profile:

_mäuschen: +1