Rdzeń pytania:
Pytanie pojawiło się, gdy nie mogłem zainstalować oprogramowania, więc szczerze pytam o ./, ponieważ nie wiedziałem o tym, a wyjściowe polecenie „nie znaleziono polecenia” myliło mnie co do tego, czym właściwie było to polecenie.
Kontekst:
Chciałbym zainstalować plik truecrypt-7.2-setup-x86
.
Instrukcje mówią, aby użyć polecenia:
sudo ./truecrypt-7.2-setup-x86
Ale wynik jest następujący:
sudo: ./truecrypt-7.2-setup-x86: command not found
AKTUALIZACJA: dla kompletności, w teście byłem w folderze plików, ale jeszcze nie uczyniłem pliku wykonywalnym (chmod + x).
./
Część komendy mówi „Spójrz w bieżącym katalogu i wykonać polecenia«truecrypt-7.2-setup-x86»stąd”. Musisz uruchomić to polecenie z katalogu, w którym rozpakowałeś plik.chmod +x
,chmod -x
wręcz przeciwnie - usuwa uprawnienia do wykonywaniaOdpowiedzi:
./
nie jest rozkazem. Poleceniem jest./truecrypt-7.2-setup-x86
.Twoja powłoka i programy
sudo
będą traktować polecenie jako nazwę ścieżki, jeśli zawiera co najmniej jeden/
znak. Ponieważ.
reprezentuje katalog, w którym aktualnie się znajdujesz,./truecrypt-7.2-setup-x86
nazwa plikutruecrypt-7.2-setup-x86
w bieżącym katalogu. Jeśli nie ma takiego pliku lub plik istnieje, ale nie można go uruchomić, pojawi się komunikat o błędzie.Kiedy polecenie nie zawiera ukośnika,
$PATH
wyszukiwane są katalogi wymienione w , jak mówi Sergiy Kolodyazhnyy . Bieżący katalog nie jest automatycznie przeszukiwane - i to nie zaleca się umieścić.
w$PATH
. W ten sposób nie uruchamiasz przypadkowo rzeczy, których nie spodziewałeś się uruchomić, ponieważ zdarzyło się, że maszcd
d do katalogu, który je zawiera.Zapisywanie
./
przed nazwą pliku wykonywalnego w bieżącym katalogu jest powszechnym sposobem jego uruchomienia, ale tak naprawdę nie jest to specjalna składnia. Na przykład, jeśli coś pomieszałeś$PATH
i musisz uruchomić poleceniels
, możesz napisać/bin/ls
..
W takim przypadku lub ogólnie nie jest to konieczne; potrzebujemy/
gdzieś w nazwie ścieżki, co oznacza, że masz na myśli, że jest to ścieżka.Ponieważ
.
zawsze jest to katalog bieżący i/
jest tylko separatorem katalogu, pierwszą rzeczą do zrobienia jest sprawdzenie, czy plik, który podałeś, naprawdę istnieje w bieżącym katalogu. (Jeśli tak, sprawdź jego uprawnienia , jak wyjaśnia Charles Green . Ale jeśli wyodrębniłeś plik z archiwum, zwykle będzie on miał uprawnienia do wykonywania, jeśli ma być uruchomiony).źródło
Część polecenia ./ mówi „Szukaj w bieżącym katalogu i wykonaj polecenie„ truecrypt-7.2-setup-x86 ”stąd”. Musisz uruchomić to polecenie z katalogu, w którym rozpakowałeś plik.
Można to przetestować: W tym samym oknie terminala, w którym próbujesz wykonać polecenie, wpisz polecenie
ls -l true*
- jeśli plik jest obecny w bieżącym katalogu roboczym, zostanie wyświetlona lista pokazująca plik (i kilka dodatkowych informacji).Jak zauważyła Zanna w komentarzach, twój plik może nie mieć uprawnień do wykonywania - można to łatwo naprawić. Jako przypadek testowy pokazuje mój katalog
a plik „rFullBack” wymienia „-rw-” jako moje uprawnienie do odczytu i zapisu pliku. Mogę wykonać polecenie,
chmod +x rFullBack
a lista katalogów zmieni się naTam moje uprawnienia są teraz „-rwx”, co oznacza, że mogę wykonać plik.
Krótko mówiąc, jeśli plik istnieje w twoim katalogu
uruchom polecenie
a następnie polecenie
źródło
rw-
jako twoje pozwolenie --
przed ustawieniem [gu] id i lepkich bitów.Jak działa wywoływanie poleceń w powłoce
Nie, to nie jest polecenie. Sposób, w jaki działają powłoki, polega na wpisaniu wiersza tekstu. Pierwsze słowo będzie traktowane jako polecenie, a jeśli polecenie nie jest jednym z poleceń wbudowanych w powłokę, powłoka sprawdzi wszystkie lokalizacje wymienione w
PATH
zmiennej środowiskowej .Co się stanie, jeśli polecenie, które chcesz uruchomić, znajduje się w tym samym katalogu, w którym aktualnie się znajdujesz, ale ten katalog nie znajduje się na liście
PATH
katalogów? Właśnie wtedy musisz użyć./
. Jest to dokładnie to samo co robisz/bin/bash
- mówisz powłoce, gdzie znajduje się żądane polecenie, pełną ścieżkę do niego. A w przypadku ./ mówisz do powłoki „zajrzyj do tego katalogu”. Tak ważną częścią jest to, że musisz znajdować się w tym samym katalogu, w którym znajduje się plik.Oczywiście, aby faktycznie uruchomić plik wykonywalny, musi on mieć ustawiony bit pliku wykonywalnego, więc musisz to zrobić
chmod +x ./my_file
.Więc ważne kroki:
cd
gdzie zapisałeś plik; jeśli jest w~/Downloads
środku, tocd ~/Downloads
chmod +x ./truecrypt-7.2-setup-x86
, mówi „zrób plik truecrypt-7.2-setup-x86, który jest w tym katalogu wykonywalny”sudo ./truecrypt-7.2-setup-x86
Zauważ, że użycie
./
nie jest przypadkowym zachowaniem, ale w rzeczywistości jest standardem określonym przez standard Przenośnego Systemu Operacyjnego (znany również jako POSIX) , w szczególności zobacz sekcję „Wyszukiwanie i wykonywanie poleceń”.Odtworzenie błędu
UWAGA : podany przez komunikat o błędzie
sudo
jest oczywiście mylący, więc należy o tym pamiętać; należy jednak pamiętać, że nie było to sedno pytania zadawanego przez OP.Dokumentacja i referencje
Z
bash
podręcznika 4.3 sekcja „WYKONYWANIE POLECEŃ”:Od Dlaczego potrzebujesz ./ (kropka-ukośnik) przed nazwą skryptu, aby uruchomić go w bash? :
źródło
sudo
wyniki są mylące. Jeśli spróbujesz to samo bezsudo
dostaniesz kolejny błąd zbash
:Permission denied
. I słusznie, ponieważ nie dałeś skryptowi pozwolenia na wykonanie (przezchmod +x
).sudo
dane wyjściowe wprowadzają w błąd, jest prawdą, ale taki właśnie błąd się pojawia. Może to być coś, co należy zgłosić programistom i pozwolić im to naprawić. Nie jest to jednak sedno dyskusji - musieliśmy ustalić, co PO zrobił, aby spowodować taki błąd, i poprowadzić ich właściwą ścieżką. Niezależnie od tego, czy jest to wprowadzające w błąd - nie o to tutaj chodzi./bin/bash
: nie pozwala na wykonanie skryptu, na który nie masz uprawnień do wykonywania. Kiedy poprzedzasz nazwę skryptu, liczy/bin/bash
się fakt, że/bin/bash
można go wykonać , ponieważ jest to wykonywane polecenie. Gdy tego nie zrobisz, sam skrypt jest wykonywany, co z kolei prowadzi do#!
wywołania twojej bieżącej powłoki lub wywołania czegokolwiek w górnym wierszu/bin/bash
jest tutaj tylko przykładem. Fakt, że dzwonimy/bin/bash
i./script.sh
podając ścieżkę do wykonywanej rzeczy - to samo. Wstępne wykonywanie skryptu zbash script.sh
lub/bin/bash script.sh
jest zupełnie innym tematem, w którym uruchamiasz plik wykonywalny i przekazujesz mu skrypt jako argument - który, nawiasem mówiąc, może się zepsuć, jeśli składnia jest napisana dla czegoś innego niż wywoływana powłoka, powiedzmycsh
./bin/bash
jest wykonywalny w porządku, ale faktem jest, że nadal określasz pełną ścieżkę do niego./bin/bash
a nawet po prostu,bash
jest również częstym sposobem rozwiązania problemu braku uprawnień do wykonywania skryptu. Określenie pełnej ścieżki skryptu nie rozwiązuje tego problemu. Tak/bin/bash
jest szczególnie zły przykład w tym konkretnym przypadku.