source du script bash: aucun fichier ou répertoire de ce type

J'ai un script qui commence comme ça

#!/bin/bash
VALKYRIE=~/myProjects/valkyrie
source $VALKYRIE/cluster.conf

mais quand je l'exécute, il revient line 2: ~/myProjects/valkyrie/cluster.conf: No such file or directory

mais le fichier existe et lorsque je l'exécute, source ~/myProjects/valkyrie/cluster.confil fonctionne très bien. Une idée? J'ai défini une VALKYRIEvariable ailleurs, donc le code en dur dans le chemin n'est pas une option.

bash scripts source

— Khoi
source

Je ne suis pas sûr à 100% si cela vous aidera, mais vous pouvez essayer de citer complètement la variable, au cas où il y aurait des espaces dans ~. Par conséquent, source "${VALKYRIE}/cluster.conf".

— Sparhawk

non, ça n'aide pas.

— Khoi

Je pense que c'est quelque chose à voir avec ~une mauvaise expansion. Lorsque j'exécute votre script avec un chemin intentionnellement faux, l'erreur ne dit pas ~, mais étend le chemin. Pouvez-vous essayer de remplacer le ~dans votre script par le chemin absolu? Essayez également d'exécuter ce qui suit dans un script echo ~.

— Sparhawk

Vous pouvez également essayer $HOMEau lieu de ~.

— Sparhawk

@Khoi Cela explique cela. ~/.pam_environmentn'est pas un script shell, donc il ne fait pas les choses courantes que vous attendez d'un shell, comme l'expansion tilde et l'expansion des paramètres, donc ni ~ni $HOMEne sera remplacé. Si vous déplacez cette ligne à la ~/.profileplace et que vous l'ajoutez export devant, cela devrait fonctionner.

— geirha

~ne semble pas se développer correctement. Lorsque j'exécute votre script avec un chemin intentionnellement faux, l'erreur ne dit pas ~, mais étend le chemin (c'est-à-dire /home/sparhawk/fakepathnon ~/fakepath. Vous pouvez essayer d'utiliser à la $HOMEplace de ~ou d'utiliser le chemin complet dans le script à la place.

(Je ne sais pas pourquoi ~ne fonctionne pas sur votre système, car votre script fonctionne bien pour moi.)

— Sparhawk
source

Lorsque vous regardez l'ordre dans lequel bash effectue les extensions ( gnu.org/software/bash/manual/bashref.html#Shell-Expansions ), vous verrez que l'expansion du tilde se produit avant l' expansion des variables. C'est pourquoi $HOMEc'est mieux que ~dans une variable

— Glenn Jackman

@glennjackman Je ne suis pas sûr de comprendre. Pourquoi la priorité aurait-elle une importance pour les variables par rapport à ~?

— Sparhawk

ce n'est pas exactement «prioritaire», c'est simplement ce qui vient en premier. Considérez x="~/.bashrc"; ls $x- dans l'ordre des extensions pour la commande "ls", bash recherche un tilde et n'en trouve pas; finalement bash voit une variable et la développe. bash ne revient pas en arrière et ne cherche plus de tildes, à ce stade, c'est juste un personnage ordinaire. et il n'y a aucun fichier dans le répertoire courant qui commence par un tilde.

— glenn jackman

Ah ok. Je pense que je comprends. Je me suis toujours demandé pourquoi cette commande échoue et x=~/".bashrc"; ls $xfonctionne. Merci pour l'info.

— Sparhawk