it-swarm-eu.dev

Proč používáme "./" (tečka lomítka) k provedení souboru v systému Linux / UNIX?

Proč používáme ./filename k provedení souboru v Linuxu?

Proč to nejen zadat jako jiné příkazy gcc, ls atd ...

89
Renjith G

V systémech Linux, UNIX a souvisejících operačních systémech . označuje aktuální adresář. Protože chcete spustit soubor v aktuálním adresáři a tento adresář není ve vašem $PATH, potřebujete ./ bit říct Shell, kde je spustitelný soubor. Tak, ./foo znamená spustit spustitelný soubor s názvem foo, který je v tomto adresáři.

Můžete použít type nebo which získat úplnou cestu k jakýmkoli příkazům nalezeným ve vašem $PATH.

80
badp

Doslovná odpověď je, jak dali ostatní: protože aktuální adresář není ve vašem $PATH.

Ale proč? Stručně řečeno, jde o bezpečnost. Pokud hledáte domovský adresář někoho jiného (nebo/tmp) a zadáte pouze gcc nebo ls, chcete vědět, že používáte skutečnou, nikoli nebezpečnou verzi vaší prankster friend napsal, který vymaže všechny vaše soubory. Dalším příkladem by bylo test nebo [, které by mohlo přepsat tyto příkazy ve skriptech Shell, pokud vaše Shell nemá tyto vestavěné.

Mít . jako položka poslední ve vaší cestě je o něco bezpečnější, ale existují i ​​další útoky, které ji využívají. Snadné je využít běžné překlepy, například sl nebo ls-l. Nebo najděte běžný příkaz, který se v tomto systému nenainstaluje - například vim, protože sysadminové mají nadprůměrnou pravděpodobnost, že jej zadají.

103
mattdm

Pokud máte na mysli, proč potřebujete ./ na začátku - je to proto, že (na rozdíl od Windows) není aktuální adresář ve výchozím nastavení součástí vaší cesty. Pokud spustíte:

$ ls

shell hledá ls v adresářích v proměnné prostředí PATH (echo $PATH vidět) a spustí první spustitelný soubor s názvem ls, který najde. Zadáte-li:

$ a.out

shell to udělá stejně - ale pravděpodobně nenajde spustitelný soubor nazvaný a.out. Musíte říct Shell, kde a.out je - je to v aktuálním adresáři (.), Pak cesta je ./a.out.

Pokud se ptáte, proč se nazývá „a.out“, jedná se pouze o výchozí název výstupního souboru pro gcc. Můžete to změnit pomocí příkazového řádku arg. Například:

$ gcc test.c -o test
$ ./test
45
Simon Whitaker

Můžete zkusit přidat :. do vaší proměnné $ PATH.

Zkuste ALT + F2 a napište: gksudo gedit /etc/environment pokud používáte Linux/GTK (to je to, co máte, pokud používáte Ubuntu).

Nicméně důrazně doporučujeme, abyste to neudělali. Je to špatné špatné špatné a špatné.

Víte, že takové věci fungují od roku 1970. Existuje důvod, proč aktuální adresář není součástí $ PATH.

. je aktuální adresář

.something by byl skrytý soubor (napište "ALT +", aby se objevily v Nautilus, nebo zkuste "ls -la ".

./someProgram.sh je to, co píšete, abyste spustili spustitelný soubor someProgram.sh v aktuálním adresáři.

.somethingElse by znamenalo, že máte skrytý spustitelný soubor v aktuálním adresáři, což je špatný nápad.

4
tiktak

Úplnější pravidlo je ve skutečnosti: pokud je v cestě nějaké lomítko /, Nehledejte PATH

Než se pustíme do zdůvodnění, měli byste o této skutečnosti nejprve vědět: běží buď:

bin/someprog

nebo:

/bin/someprog

nebo:

cd bin
./myexec

spusťte bin/someprog bez vyhledávání proměnné PATH ze stejného důvodu: všechny bin/someprog, /bin/someprog a ./someprog mají lomítko / V nich.

Samotná someprog nemá lomítko /, a proto hledá pouze v PATH.

POSIX 7 určuje toto pravidlo na: http: //pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01

Odůvodnění pravidla / POSIX PATH

Předpokládejme, že běží:

someprog

hledal:

  • vzhledem k CWD jako první
  • vzhledem k PATH po

Pak, pokud jste chtěli spustit z vašeho distro /bin/someprog A udělali jste:

someprog

někdy by to fungovalo, ale jiné by selhalo, protože byste mohli být v adresáři, který obsahuje jiný nesouvisející program someprog.

Proto byste se brzy dozvěděli, že to není spolehlivé, a že byste vždy chtěli používat absolutní cesty, když chcete používat PATH, a tak porazit účel PATH.

To je také důvod, proč mít relativní cesty ve vaší cestě je opravdu špatný nápad. Jsem dívám se na tebe, node_modules/bin .

Naopak, předpokládejme, že běží:

./someprog

Hledal by:

  • vzhledem k PATH jako první
  • vzhledem k CWD po

Pokud jste si stáhli skript someprog z úložiště git a chtěli jste ho spustit z CWD, nikdy byste si nebyli jisti, že se jedná o skutečný program, který by se spustil, protože možná vaše distro obsahuje:

/bin/someprog

což je ve vás PATH z nějakého balíčku, který jste nainstalovali po přílišném pití po loňských Vánocích.

Proto byste znovu byli nuceni vždy spouštět místní skripty týkající se CWD s plnými cestami, abyste věděli, co právě používáte:

"$(pwd)/someprog"

což by bylo také velmi nepříjemné.

Dalším pravidlem, které byste mohli být v pokušení přijít, by bylo:

relativní cesty používají pouze PATH, absolutní cesty pouze CWD

ale znovu to nutí uživatele, aby vždy používali absolutní cesty pro ne-PATH skripty s "$(pwd)/someprog".

Pravidlo hledání cesty / Nabízí jednoduché řešení problému:

  • lomítko: nepoužívejte PATH
  • bez lomítka: použijte pouze PATH

což usnadňuje vždy vědět, co běží, spoléhajíc na skutečnost, že soubory v aktuálním adresáři lze vyjádřit buď jako ./somefile nebo somefile, a dává tedy zvláštní význam jeden z nich.

Někdy je trochu nepříjemné, že nemůžete hledat some/prog Vzhledem k PATH, ale nevidím rozumnější řešení.