Path-Var anpassen?

Joerg_H

Mitglied
Thread Starter
Registriert
05.08.2024
Beiträge
11
Reaktionspunkte
2
Hi,

ich habe 2 Python-Versionen vom Mac gelöscht und wollte nun die dazugehörigen Path-Variable-Einträge löschen.

Leider klappt das nicht gut, ich kenne mich schlecht aus auf dem Mac.

Ich habe mir das File "etc/paths" angesehen, da stehen folgende Einträge:
/usr/local/bin
/System/Cryptexes/App/usr/bin
/usr/bin
/bin
/usr/sbin
/sbin
Wenn ich im Terminal aber echo "$path" eingebe, kommt folgender Inhalt:
/Library/Frameworks/Python.framework/Versions/3.13/bin /Library/Frameworks/Python.framework/Versions/3.11/bin /usr/local/bin /System/Cryptexes/App/usr/bin /usr/bin /bin /usr/sbin /sbin /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin

Wie/wo kann ich denn die beiden ersten Python-Pfade weg bekommen?

Ich weiß, die stören ja nicht, aber ich wills ordentlich haben und dazu auch noch was lernen...:) Irgendwie muss das ja gehen...:)

Hat jemand einen Tipp für einen MacOS-Deppen wie mich?

Danke!
 
Ich komme aus der Linuxszene und dort ist es so, dass im Benutzerverzeichnis eine versteckte Datei (glaube .bash_rc) eingelesen wird, die aber unter MacOS sicherlich anders heißen wird. Wenn man ein Terminal oder Shell öffnet wird die dann eingelesen und dort dürfte die PATH-Variable dann für die Sitzung gesetzt werden.

Als Depp würde ich dich aber nicht bezeichnen wollen. Freue mich über jede/n der/die mal das Terminal aufmacht.
 
Danke dir!

Im User-Dir sind 2 Files (versteckt): .zprofile und noch irgendeine (schon gelöscht)...

Die beiden Files gelöscht (vorher natürlich rein geguckt) und jetzt ist alles korrekt.
Danke!
 
Für alle die mal selbst die PATH Variabel ändern wollen, und das auf die in macOS vorgesehene Art machen wollen:

Es gibt das Verzeichnis. /etc/paths.d

Wenn man darin eine Textdatei anlegen die je Zeile einen Pfad enthält, werden diese an die PATH-Variable aus /etc/paths angehängt. Die Dateien werden dabei nach ihrer sortierreihenfolge eingelesen.

Vorteil:

Benötigt irgendein Tool eigene PATH-Angaben, dann reicht eine Textdatei aus, die man dann am besten nach dem Tool benennt, ggf mit einer Zajl vorneweg. Beim Deinstallieren reicht es dann einfach diese Datei zu löschen.

Ein eiditieren irgendeiner rc- oder profile-Datei ist nicht nötig.

Es ist auch suboptimal, eine rc- oder profile Datei zu löschen, d darin regelmäßig andere Einstellungen, Varaiblen etc gesetzt sind. @Joerg_H Insoweit war das Löschen vielleicht nicht ganz so geschickt.
 
Für alle die mal selbst die PATH Variabel ändern wollen, und das auf die in macOS vorgesehene Art machen wollen:

Es gibt das Verzeichnis. /etc/paths.d

Wenn man darin eine Textdatei anlegen die je Zeile einen Pfad enthält, werden diese an die PATH-Variable aus /etc/paths angehängt. Die Dateien werden dabei nach ihrer sortierreihenfolge eingelesen.

Vorteil:

Benötigt irgendein Tool eigene PATH-Angaben, dann reicht eine Textdatei aus, die man dann am besten nach dem Tool benennt, ggf mit einer Zajl vorneweg. Beim Deinstallieren reicht es dann einfach diese Datei zu löschen.

Ein eiditieren irgendeiner rc- oder profile-Datei ist nicht nötig.

Es ist auch suboptimal, eine rc- oder profile Datei zu löschen, d darin regelmäßig andere Einstellungen, Varaiblen etc gesetzt sind. @Joerg_H Insoweit war das Löschen vielleicht nicht ganz so geschickt.
Sehr schöner Tip.
Hab ich gleich mal getestet und in mein schlaues Büchlein übernommen.
 
Für alle die mal selbst die PATH Variabel ändern wollen, und das auf die in macOS vorgesehene Art machen wollen:

Es gibt das Verzeichnis. /etc/paths.d

Wenn man darin eine Textdatei anlegen die je Zeile einen Pfad enthält, werden diese an die PATH-Variable aus /etc/paths angehängt. Die Dateien werden dabei nach ihrer sortierreihenfolge eingelesen.
Hail to the @lisanet - wirklich guter Hinweis. Kann man sowas irgendwie lernen oder nachlesen? Finde irgendwie den Unix-Unterbau viel spannender als wenn Apple jetzt beispielsweise ein neues Produkt präsentiert.

Gibt es da irgendwelche Entwickler-Communities, die sich speziell mit Unix beschäftigen. Oder vielleicht einen Literaturtipp? Ein paar Kenntnisse kann ich bestimmt von Linux übertragen und die Angst vor der Kommandozeile habe ich damals schon überwunden, dass ich meinen Amiga verkauft und mir einen MS-DOS PC angeschafft habe. MS-DOS ist aber kein wirklicher Vergleich.

Wie gesagt, ich finde sowas total spannend und es war mit ein Grund warum ich mir letztendlich auch einen kleinen Mac Mini M2 angeschafft habe. Bin auch sehr zufrieden damit.
 
Es ist auch suboptimal, eine rc- oder profile Datei zu löschen, d darin regelmäßig andere Einstellungen, Varaiblen etc gesetzt sind. @Joerg_H Insoweit war das Löschen vielleicht nicht ganz so geschickt.
Ich habe natürlich beide Files geprüft... Inhalt:
# Setting PATH for Python 3.11
# The original version is saved in .zprofile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.11/bin:${PATH}"
export PATH

# Setting PATH for Python 3.13
# The original version is saved in .zprofile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.13/bin:${PATH}"
export PATH
In der anderen Datei:
# Setting PATH for Python 3.11
# The original version is saved in .zprofile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.11/bin:${PATH}"
export PATH
Es steht also nix anderes drin als der Python-Kram...

Zur Sicherheit habe ich die beiden Files wieder hergestellt und einfach # vor die Zeilen gemacht... so kann eine andere Software noch was dazu schreiben wenn es das will...
 
Wenn ich schon bei den Tipps bin

in .zprofile sollte zumindest stehen

Bash:
#include .zshrc if exists
if [ -f ~/.zshrc ]; then
    . ~/.zshrc
fi

Dadurch ist gewährleistet, dass login und non-login shells identisch mit .zshrc konfiguriert werden.

In .zshrc bietet es sich an ein paar Dinge zu konfigurieren, zum einen das sourcen einer alias Datei und zum anderen etwas mehr Farbe für manpages. Das macht es IMO etwas besser zu lesen, wenn man als Terminal ein Profil verwendet, dass einen schwarzen Hintergrund hat

Der Prompt ist die Variable PS1, wie ich ihn habe. Er stellt Host und user in grün dar und anschließend den vollen Pfad in welchem man sich befindet. Das alles in einer eigenen Zeile, da dann die anschließende Befehlseingabe "sauber" ganz links steht und man so bei scrollen besser erkennt, wo Prompt und wo Befehle sind.

Bash:
# include aliases
if [ -f ~/.zsh_aliases ]; then
        . ~/.zsh_aliases
fi

export PS1="%10F%m:%n%f - %d"$'\n'">"

export EDITOR=nano

# less colored
export LESS_TERMCAP_mb=$'\e[1;31m'
export LESS_TERMCAP_md=$'\e[1;31m'
export LESS_TERMCAP_me=$'\e[0m'
export LESS_TERMCAP_se=$'\e[0m'
export LESS_TERMCAP_so=$'\e[01;44;33m'
export LESS_TERMCAP_ue=$'\e[0m'
export LESS_TERMCAP_us=$'\e[01;32m'

export PAGER='less -r'

Wer nun noch als Editor nano nutzt und zwar in einer aktuellen Version, der hat hat dann auch mit nano ein tolles syntax-highlightning von allen möglichen Texten, Codes, Scripten etc, wenn man die in Terminal.app bearbeitet.

Ich muss mal sehen, ob ich da irgendwo ein einfache cript habe, das nano ohne irgendwelchen overhead und mögliche Unverträglichkeiten von Paketmanagern kompiliert. Das aber in einem anderen Posting, sofern überhaupt Interesse besteht.

Die Datei .zsh_aliases entält dann eineie aliase für Befehle, weil ich es deutlcih praktische findet ll statt ls -l einzugeben, wenn ich ein tabellarisches Listing von Dateien/Ordnern will. Ebenso ist la statt ls -a praktischer um die unsichtbaren dot-Datien/Verzeichnis anzuzeigen. Man kann das natürlich kombinieren, also ll -a für ein tabellarisches Lisung incl. Dot-Dateien. Natürlich ist die Ausgabe von ls auch farbig. Zudme habe ich gleich noch die Ausgabe von grep farbig gestaltet, was das lesen deutlich erleichert.

rm wird so als alias gesetzt, dass immer eine Nachfrage bei Löschen kommt, und mkdir fand ich schon immer zu lange und habe es mit md abgekürzt

Bash:
alias ls='ls -G'
alias ll='ls -l'
alias la='ls -a'
alias md='mkdir'
alias rm='rm -i'
alias grep='grep --color=auto'
 
Ich zitiere mich kurz selbst

Ich muss mal sehen, ob ich da irgendwo ein einfache cript habe, das nano ohne irgendwelchen overhead und mögliche Unverträglichkeiten von Paketmanagern kompiliert. Das aber in einem anderen Posting, sofern überhaupt Interesse besteht.

Ich habe das script gefunden und gleich mal aktualisiert und dazu noch einen Artikel in meinem blog verfasst, wie ihr recht einfach eine aktuelle Version von nano erstellen könnt. In macOS Sequoia ist nano leider entfernt (war aber eh schon uralt) und durch pico ersetzt worden. Es wird also Zeit für einen aktuellen Editor.

Als kleines Goodie habe ich dann noch ergänzt, wie man dann auch in nano das schnelle Bewegen im Text mit Home/End zu Zeilenanfang und -ende, seitenweises scrollen mit PageUp/PageDown und und das wortweise springen mit ALT + Cursor rechts/links realisieren kann :cool:

Hier lest ihr wie es geht -> https://lisanet.de/nano-unter-macos-selbst-kompilieren/
 
Ich zitiere mich kurz selbst



Ich habe das script gefunden und gleich mal aktualisiert und dazu noch einen Artikel in meinem blog verfasst, wie ihr recht einfach eine aktuelle Version von nano erstellen könnt. In macOS Sequoia ist nano leider entfernt (war aber eh schon uralt) und durch pico ersetzt worden. Es wird also Zeit für einen aktuellen Editor.

Als kleines Goodie habe ich dann noch ergänzt, wie man dann auch in nano das schnelle Bewegen im Text mit Home/End zu Zeilenanfang und -ende, seitenweises scrollen mit PageUp/PageDown und und das wortweise springen mit ALT + Cursor rechts/links realisieren kann :cool:

Hier lest ihr wie es geht -> https://lisanet.de/nano-unter-macos-selbst-kompilieren/

BESTEN DANK!

nano ist nun selbstkompiliert und liegt in /usr/local/bin
und ein rnano als link auf nano

Eine Frage habe ich aber trotzdem:
In macos ist ja aktuell /usr/bin/nano ein link auf pico.
Dummerweise wird pico immer noch gestartet wenn ich im terminal nano eingebe, obwohl /usr/local/bin im Pfad vor /usr/bin steht

Bin ich zu blöd oder wie kann ich das ändern ohne den link zu löschen?
 
gib mal ein hash -r Das löscht den cache. Dann prüfe mit which nano was da raus kommt.
 
gib mal ein hash -r Das löscht den cache. Dann prüfe mit which nano was da raus kommt.
War was anderes:
ich hatte in zshrc die EDITOR variable auf nano gesetzt. Das hat wohl diesen Effekt.
Zeile auskommentiert: Problem gelöst
Code:
> which nano
/usr/local/bin/nano

Danke
 
An der Variablen kann es nicht liegen. Die steht bei mir auch auf nano.

... es liegt trotzdem am cache. Der löscht sich auch, wenn du das Terminal beendest und neu startest, nachdem du .zshrc geändert hast. Das ist immer dann der Fall, wenn du ein eigenes binary in /usr/local/bin legst, dass du zuvor aufgerufen hast in /usr/bin. Du siehst das auch daran, dass erst mal die Tab-completion nicht auf /usr/local/bin springt.

Alternativ kannst du beim ersten Aufruf auch den vollen Pfad zum binary in /usr/local/bin angeben, statt ein re-hashing zu machen.
 
Es gibt das Verzeichnis. /etc/paths.d

Wenn man darin eine Textdatei anlegen die je Zeile einen Pfad enthält, werden diese an die PATH-Variable aus /etc/paths angehängt. Die Dateien werden dabei nach ihrer sortierreihenfolge eingelesen.
Dazu noch als Ergänzung: Dort hinzugefügte Pfade gelten systemweit, also für alle Programme und alle User. Ich würde deshalb dort nur dann Pfade hinzufügen, wenn man genau das will. Das ganze hat auch einen Sicherheitsaspekt, weil man mit dem Mechanismus verändern kann, wo andere User Programme finden.
 
Dazu noch als Ergänzung: Dort hinzugefügte Pfade gelten systemweit, also für alle Programme und alle User. Ich würde deshalb dort nur dann Pfade hinzufügen, wenn man genau das will. Das ganze hat auch einen Sicherheitsaspekt, weil man mit dem Mechanismus verändern kann, wo andere User Programme finden.

Ja und?

Das Verzeichnis ist nur durch einen Admin beschreibbar. Und ein Admin darf und soll alles können. Daher ist das alles kein Problem.
 
Auf von einer Person genutzten Rechnern dürfte das egal sein. Auf von mehreren genutzten Rechnern sollte man zumindest kurz drüber nachdenken, ob das wirklich für alle sein soll (vrmtl. ist das auch hier meist egal).
 
Zurück
Oben Unten