Tilde im PATH: Ein gefährlicher Fehler, der zum Sicherheitsrisiko wird
Don't Put Tilde In Your Path
Viele Entwickler fügen ~/.local/bin zum PATH hinzu, ohne zu wissen, dass die Tilde in Anführungszeichen nicht expandiert wird. Statt des Home-Verzeichnisses landet ein wörtliches ~ im PATH, was dazu führt, dass ausführbare Dateien aus dem aktuellen Arbeitsverzeichnis geladen werden – ein Sicherheitsrisiko. Der Artikel erklärt das Problem, zeigt eine Demo und empfiehlt, $HOME zu verwenden. Ein Sandbox-Tool warnte den Autor.
If a word begins with an unquoted tilde character (‘~’), all of the characters up to the first unquoted slash (…) are considered a tilde-prefix.
- SoftTalker
Ich benutze Tilde nie in Skripten, nur als Annehmlichkeit beim interaktiven Tippen von Befehlen.
Ansonsten $HOME, was zwar auch Fallstricke hat, aber dieselben wie bei jeder anderen Umgebungsvariable.
- amarshall
Oder man kann einfach … die Tilde nicht quoten. Die Leute scheinen reflexartig „Strings“ in Bash zu quoten, ohne zu realisieren, dass (fast) alles ein String ist und die meisten Strings nicht gequotet werden und es seltsam wäre, es zu tun (z. B. macht niemand `"ls" "-a" "foo"`).
- thefilmore
Man kann einfach Folgendes tun:
PATH=~/.local/bin:$PATH
PATH ist bereits exportiert. Anführungszeichen sind bei Zuweisungen ebenfalls nicht nötig.
- FeepingCreature
Es scheint irgendwie, als hättest du das bemerken sollen, weil dein ~/.local/bin PATH nicht funktioniert?
- alexpotato
Nicht unbedingt über Tilden, sondern über den Wahnsinn, der mit Bash in großen Organisationen passieren kann:
Bei einem früheren Job versuchte ich herauszufinden, welcher Teil meiner bashrc eine bestimmte Umgebungsvariable setzte. Ich nahm an, dass es irgendeine Art von Standard sein müsste, der in meinem Benutzerprofil installiert ist und/oder von /etc/<irgendwas> geerbt wird.
Ich merkte ziemlich schnell, dass meine bashrc einige andere Dateien importierte. Wieder war die Annahme, dass dies eine Datei tief im Import sein würde.
Es stellte sich heraus, dass es 10+ Ebenen von Imports gab, beginnend bei einer „ur-bashrc“ und dann Schicht um Schicht immer mehr Imports, bis man schließlich zu einem Benutzerprofil gelangte.
Es war so verworren, dass ich fast wahnsinnig wurde, bis ich diesen Stack-Exchange-Beitrag fand: https://unix.stackexchange.com/questions/813/how-to-determin...
Er aktiviert „Tracing“ für Bash-Imports, sodass man dann eingrenzen kann, wo die Umgebungsvariable gesetzt wird.
- dspillett
Ich wollte gerade sagen: „Bei mir scheint es immer zu funktionieren“, dann sah ich „… funktioniert tatsächlich in Bash und Zsh, weil …“.
Wieder so ein Bash-ism, bei dem ich aufpassen muss, ihn nicht zu verwenden, wenn ich portabel sein will.
Es ist erwähnenswert, dass auf vielen Systemen /bin/sh nicht bash (oder zsh) ist. Wenn man sich also auf Bash-isms verlassen will (oder einfach keine Lust hat, nach ihnen zu suchen), sollte man spezifisch sein und „#!/bin/bash“ für den Hashbang verwenden. Auf Debian und ähnlichen Systemen ist es zum Beispiel normalerweise dash.
- the__alchemist
Ich wünschte, Linux-Distributionen würden ein „Terminal“/„CLI“-Programm usw. mitliefern, das von der Skriptsprache entkoppelt ist. Eine universelle Path-Umgebungsvariable haben, die nicht an eine bestimmte Shell gebunden ist. Damit kann man cd-Befehle ausführen, python/git/cargo/beliebige Anwendungen starten usw. und ein gutes Lesezeichen- und Autovervollständigungssystem haben. Es fühlt sich an, als ob die Vermischung von Skriptsprache und CLI-Anwendung die Wurzel dieser Komplikationen und Feinheiten ist.
Wenn man Shell-Skripting verwendet (und Bash usw. gegenüber Python bevorzugt), würde man weiterhin Bash/Fish/Zsh usw. verwenden. Wenn man die CLI zum Starten von Anwendungen ohne GUI, zum Navigieren in Verzeichnissen und zum Ausführen von Dateisystemoperationen verwendet, dann würde man das reine Terminal verwenden.
- ligarota
Erstelle einfach eine Datei ~, die ein Symlink zum Home-Verzeichnis ist :)
Big Brain Time hier