źródło skryptu bash: brak takiego pliku lub katalogu


9

Mam skrypt, który zaczyna się w ten sposób

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

ale kiedy go uruchomię, wraca line 2: ~/myProjects/valkyrie/cluster.conf: No such file or directory

ale plik istnieje i po uruchomieniu source ~/myProjects/valkyrie/cluster.confdziała poprawnie. Dowolny pomysł? Ustawiam VALKYRIEzmienną gdzie indziej, więc twardy kod na ścieżce nie jest opcją.


Nie jestem w 100% pewien, czy to pomoże, ale możesz spróbować w pełni zacytować zmienną, na wypadek, gdyby w ~ były spacje. Dlatego też source "${VALKYRIE}/cluster.conf".
Sparhawk

nie, to nie pomaga.
Khoi

1
Myślę, że ma to coś wspólnego z ~nieprawidłowym rozszerzaniem. Kiedy uruchamiam skrypt z celowo fałszywą ścieżką, błąd nie mówi ~, ale rozszerza ścieżkę. Czy możesz spróbować zastąpić ~w skrypcie ścieżkę bezwzględną? Spróbuj także uruchomić następujące polecenie w skrypcie echo ~.
Sparhawk

2
Możesz także spróbować $HOMEzamiast ~.
Sparhawk

3
@ Khoi To wyjaśnia. ~/.pam_environmentnie jest skryptem powłoki, więc nie wykonuje typowych rzeczy, których można oczekiwać od powłoki, takich jak interpretacja tyldy i interpretacja parametrów, więc ani ~nie $HOMEzostanie zastąpiona. Jeśli ~/.profilezamiast tego przeniesiesz tę linię i dodasz ją export z przodu, powinna ona działać.
geirha

Odpowiedzi:


8

~nie wydaje się prawidłowo rozwijać. Kiedy uruchomić skrypt z celowo fałszywe ścieżki, błąd nie mówi ~, lecz rozszerza ścieżkę (czyli /home/sparhawk/fakepathnie ~/fakepath. Można spróbować użyć $HOMEzamiast ~, albo stosując pełną ścieżkę w skrypcie zamiast.

(Nie jestem pewien, dlaczego ~nie działa w twoim systemie, ponieważ twój skrypt działa dla mnie dobrze).


Kiedy spojrzysz na kolejność, w której bash wykonuje rozwinięcia ( gnu.org/software/bash/manual/bashref.html#Shell-Expansions ), zobaczysz, że rozwinięcie tyldy następuje przed rozwinięciem zmiennej. Dlatego $HOMEjest lepszy niż ~w zmiennej
glenn jackman

@glennjackman Nie jestem pewien, czy rozumiem. Dlaczego miałby pierwszeństwo sprawą zmiennych vs ~?
Sparhawk

1
nie jest to dokładnie „priorytet”, to po prostu to, co pierwsze. Rozważ x="~/.bashrc"; ls $x- w kolejności rozszerzeń polecenia „ls” bash szuka tyldy i jej nie znajduje; w końcu bash widzi zmienną i rozwija ją. bash nie wraca i nie szuka tyldy, w tym momencie jest to zwykły znak. i nie ma żadnych plików w bieżącym katalogu, które zaczynają się od tyldy.
glenn jackman

Ah, dobrze. Myślę, że rozumiem. Zawsze zastanawiałem się, dlaczego to polecenie zawiedzie i x=~/".bashrc"; ls $xdziała. Dzięki za informację.
Sparhawk
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.