Jak dodać ścieżkę katalogu domowego, która ma zostać odkryta przez Unix, które polecenie?

Mam zainstalowany node.jsw niestandardowej lokalizacji i dodać lokalizację do $PATHw .profilepliku.

$ node --version
v0.6.2
$ which node
$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:~/Unix/homebrew/bin
$ cat ~/.profile
export  PATH="$PATH:~/Unix/homebrew/bin"

Sam Node.js działa dobrze. Problem polega na tym, że nie ma go na liście whichpoleceń. Więc nie mogę npmteraz zainstalować . Ponieważ npminstalacja nie może znaleźć lokalizacji node.js. Jak mogę nodeodkryć plik binarny which?

— Eonil
źródło

Odpowiedzi:

Dzieje się tak, ponieważ ~nie został rozwinięty. Twoja powłoka wie, jak sobie z tym poradzić, ale whichtego nie robi (podobnie jak większość innych programów). Zamiast tego wykonaj:

export "PATH+=:$HOME/Unix/homebrew/bin"

Alternatywnie, przestań używać whichi użyj (prawie zawsze lepszy) type -p.

Oto demonstracja problemu:

$ echo "$PATH"
/usr/local/bin:/usr/bin:/bin
$ export "PATH+=:~/git/yturl"
$ yturl
Usage: yturl id [itag ...]
$ which yturl
$ type -p yturl
/home/chris/git/yturl/yturl
$ export "PATH=/usr/local/bin:/usr/bin:/bin:$HOME/git/yturl"
$ which yturl
/home/chris/git/yturl/yturl

Pamiętaj, że niektóre inne programy, które na to patrzą, $PATHmogą nie rozumieć znaczenia ~któregoś z nich i traktować je jako część ścieżki względnej. Jest bardziej przenośny w użyciu $HOME.

— Chris Down
źródło

Chociaż proponowane rozwiązanie działa, wyjaśnienie jest błędne. whichnie jest tutaj winny; ~powinna zostać rozszerzona w definicji PATH. Jest takie kuriozum w bash, że rozszerza ~W każdym razie w PATH, więc dwie krzywdy zrobić prawo, rodzaj.

— Gilles 'SO - przestań być zły'

@Gilles Czym to się różni od tego, co powiedziałem?

— Chris Down

Fakt, że działa to w ogóle z cytowanym cytatem, ~jest dziwną dziwką. Mając to dosłowne ~in $PATHmoże powodować kłopoty w dół linii, ponieważ istnieją programy, które robią swoje rozszczepienie $PATHi nie traktują ~specjalnie.

— Gilles 'SO - przestań być zły'

@Gilles ... i czym to się różni od tego, co powiedziałem w ostatnim akapicie?

— Chris Down

Choć technicznie prawdą jest, że „jakiś inny program… może nie rozumieć znaczenia ~”, zdanie jest mylące. W kontekście $PATHjest to każdy program inny niż bash.

— Gilles „SO- przestań być zły”

Ta linia w twoim .profilepowinna być jedną z

export  PATH="$PATH:$HOME/Unix/homebrew/bin"
PATH="$PATH:$HOME/Unix/homebrew/bin"
PATH=$PATH:$HOME/Unix/homebrew/bin
PATH=$PATH:~/Unix/homebrew/bin

~Znak rozszerzony tylko do swojego katalogu domowego, gdy jest to pierwszy znak słowa i to nie notowanych. W tym, co napisałeś, ~jest pomiędzy podwójnymi cudzysłowami, a zatem nie jest rozwinięte. Nawet jeśli napisałeś export "PATH=$PATH:"~/Unix/homebrew/bin, ~nie zostanie rozwinięty, ponieważ nie ma go na początku słowa powłoki.

Istnieje specjalne dozowanie, które ma na celu zapisywanie wartości PATHi podobnych zmiennych. Jeśli ~jest tuż za znakiem równości, który oznacza przydział, lub jeśli ~jest tuż po znaku po :prawej stronie przydziału, to jest on rozwinięty. Tylko zwykłe przypisania mają tę dyspensację, export PATH=…nie liczą się (jest to wywołanie exportwbudowanego, które akurat ma argument zawierający =znak).

W tym przypadku nie trzeba eksportować, PATHponieważ jest już wyeksportowany. Nie musisz dzwonić, exportgdy zmieniasz wartość zmiennej (z wyjątkiem starych powłok Bourne'a, których nie znajdziesz w OSX lub Linux). Ponadto w zadaniu (znowu exportsię nie liczy) nie potrzebujesz podwójnych cudzysłowów po prawej stronie, więc PATH=$PATH:~/Unix/homebrew/binjest bezpieczny, nawet jeśli $PATHzawiera spacje.

— Gilles „SO- przestań być zły”
źródło