Comment ajouter le chemin du répertoire personnel à découvrir par Unix quelle commande?

J'ai installé node.jsà l' emplacement personnalisé et a ajouté l'emplacement du $PATHau .profilefichier.

$ 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"

Node.js lui-même fonctionne bien. Le problème est qu'il n'est pas répertorié par whichcommande. Je ne peux donc pas installer npmmaintenant. Parce que l' npminstallation ne trouve pas l'emplacement de node.js. Comment puis-je faire nodedécouvrir le binaire par which?

— Eonil
source

Réponses:

Cela se produit car ~n'a pas été étendu. Votre shell sait comment gérer cela, mais whichne le fait pas (pas plus que la plupart des autres programmes). Au lieu de cela, faites:

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

Alternativement, arrêtez d'utiliser whichet utilisez le (presque toujours supérieur) type -p.

Voici une démonstration du problème:

$ 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

Gardez à l'esprit que certains autres programmes qui regardent $PATHpeuvent ne pas comprendre le sens de l' ~un et de l' autre et le considèrent comme faisant partie d'un chemin relatif. Il est plus portable à utiliser $HOME.

— Chris Down
source

Bien que la solution proposée fonctionne, l'explication est fausse. whichn'est pas en faute ici; le ~aurait dû être élargi dans la définition de PATH. Il y a une bizarrerie dans bash qui l'expansion de ~toute façon PATH, donc deux torts font un droit, en quelque sorte.

— Gilles 'SO- arrête d'être méchant'

@Gilles En quoi cela diffère-t-il de ce que j'ai dit?

— Chris Down

Le fait que cela fonctionne du tout avec la citation ~est une bizarrerie bash. Avoir ce littéral ~dans $PATHest susceptible de causer des problèmes sur toute la ligne , car il y a des programmes qui font leur propre division de $PATHet ils ne traitent pas ~spécialement.

— Gilles 'SO- arrête d'être méchant'

@Gilles ... et en quoi cela diffère-t-il de ce que j'ai dit dans mon dernier paragraphe?

— Chris Down

Bien qu'il soit techniquement vrai qu '«un autre programme… peut ne pas comprendre le sens de ~», votre phrase est trompeuse. Dans le contexte de $PATH, il s'agit de chaque programme autre que bash.

— Gilles 'SO- arrête d'être méchant'

Cette ligne dans votre .profiledevrait être l'un des

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

Le ~caractère n'est développé dans votre répertoire personnel que lorsqu'il s'agit du premier caractère d'un mot et qu'il n'est pas cité. Dans ce que vous avez écrit, le ~est entre guillemets doubles et donc pas développé. Même si vous écriviez export "PATH=$PATH:"~/Unix/homebrew/bin, le ~ne serait pas développé car il ne se trouve pas au début d'un mot shell.

Il existe une dispense spéciale, qui est destinée à écrire des valeurs pour PATHet des variables similaires. Si ~est juste après le signe égal qui marque une affectation, ou si ~est juste après un :dans le côté droit d'une affectation, il est développé. Seules les affectations simples ont cette dispense, export PATH=…ne compte pas (c'est un appel au exportbuiltin, qui se trouve avoir un argument qui contient un =caractère).

Ici, vous n'avez pas besoin d'exporter PATHcar il est déjà exporté. Vous n'avez pas besoin d'appeler exportlorsque vous modifiez la valeur d'une variable (sauf dans les anciens shells Bourne que vous ne trouverez pas sous OSX ou Linux). De plus, dans une affectation (encore une fois, exportne compte pas), vous n'avez pas besoin de guillemets doubles sur le côté droit, c'est donc PATH=$PATH:~/Unix/homebrew/binsûr même s'il $PATHcontient des espaces.

— Gilles 'SO- arrête d'être méchant'
source