Dlaczego muszę wpisać „./” zawsze przed plikiem wykonywalnym, aby wykonać go w systemie Linux?

Kiedy kompiluję egxc przez:

GCC x.c -o x

Aby wykonać wynik, muszę napisać:

./x

I tylko wpisując:

Nie działa z tą wiadomością:

x: polecenie nie znaleziono

Oznacza to, że Linux nie szuka go w bieżącym katalogu! Czy za tym zachowaniem kryje się (jestem pewien, że) jakiś rozsądny problem?

linux shell

— Yasser Zamani
źródło

Ponieważ to są zasady.

— Daniel R Hicks

@ DanH: Proszę wyjaśnić „zasady”.

— Torben Gundtofte-Bruun

Odpowiedzi:

Ponieważ domyślnie bieżącego katalogu roboczego nie ma w PATHzmiennej.

Jest to środek bezpieczeństwa / wygody. Jeśli masz pliki binarne / skrypty nazywane np cd, lsitp w bieżącym katalogu roboczym, byłoby to bardzo irytujące, jeśli były one uruchamiane domyślnie.

— Oliver Charlesworth
źródło

Odpowiedź jest tylko częściowo poprawna. Problem można rozwiązać, jeśli bieżący katalog był używany tylko jako ostatnia opcja. Wtedy standardowe narzędzia nadal byłyby pierwsze.

— użytkownik nieznany

Ponadto powłoka builtins wziąć precendence (czyli po wpisaniu cdw bash, wykonuje rutynowe wewnętrzny do bash i nie /bin/cd), chyba że poprzedzić z `.`

— LawrenceC

Jeden z oryginalnych środków bezpieczeństwa * nix, wymusza wykonanie skompilowanych plików binarnych w systemie lub przez administratora, które są w poleceniu ścieżki przypisanej do systemu. Nic tak złego, jak ktoś, kto zaloguje się jako root w pytaniu pomocy technicznej, przejdź do katalogu użytkownika, wpisz ls i przekonaj się, że załadował bombę pozostawioną przez użytkownika.

— Fiasco Labs

@userunknown: I przy pierwszej literówce slmasz ten sam problem. Powinny być w nim tylko zaufane katalogi, $PATHa ścieżki względne jak nigdy nie. są zaufanym katalogiem dla interaktywnej powłoki.

@Basic: Jeśli piszę, rm -r targetkiedy miałem na myśli, rm -f targetzwykle nie ma różnicy. Jeśli piszę, rm -f targetkiedy miałem na myśli rm -r target, albo nie ma różnicy, albo całkowite usunięcie kończy się niepowodzeniem. Co więcej, myślę, że za każdym razem, zanim piszę rm, szczególnie jeśli dodam -flub -rglob - to z natury niebezpieczne polecenie. Nikt nie myśli przed lsing.

Oznacza to, że bieżącego katalogu nie ma w zmiennej $ PATH.

— James
źródło

Możesz to naprawić, dodając bieżący katalog (reprezentowany pojedynczą kropką) do PATHzmiennej środowiskowej.
Sposób na zrobienie tego zależy od używanej powłoki.
jeśli używasz bash, możesz dodać linię export PATH=$PATH:.do .bashrcpliku w swoim katalogu domowym.
jeśli używasz csh lub tcsh, dodaj wiersz set PATH = ($PATH .)do pliku .cshrc w katalogu domowym.
IMHO, w przypadku domowego komputera stacjonarnego jest to do zaakceptowania - ze względów bezpieczeństwa.

— kroiz
źródło

Nie wiedziałem, że możemy dodać. do PATH, jednak zrobienie tego obniży bezpieczeństwo, prawda?

— Yasser Zamani