Miért használjuk a ./filename -t egy fájl linuxos futtatásához?
Miért ne? csak írja be, mint a többi parancsot gcc, ls stb …
Megjegyzések
- Nem lenne ‘ t az első sor jobban beírva ” Miért használjuk a
./command_nameegy parancs végrehajtásához a linuxban? ” - user15760, Nem, mert szeretjük a kérdéseket felfedezhető a keresőmotorokban, és nem mindenki, akinek ez a kérdése van, természetes születésű ‘ nixsters (:
Válasz
Linux, UNIX és kapcsolódó operációs rendszerekben a . az aktuális könyvtárat jelöli. Mivel egy fájlt szeretne futtatni az aktuális könyvtárban és abban a könyvtárban nincs a $PATH fájlban, a ./ bitre van szüksége, hogy megmondja a héjnak a futtatható. Tehát a ./foo azt jelenti, hogy futtassa az ebben a könyvtárban található foo nevű futtatható fájlt.
Használhatja a type vagy which a $PATH fájlban található parancsok teljes elérési útjának megszerzéséhez.
Megjegyzések
Válasz
A szó szerinti válasz olyan, amilyet mások megadtak: mert az aktuális könyvtár nem “t” van a $PATH könyvtárban.
De miért? Röviden: a biztonság kedvéért. Ha valaki más saját könyvtárát keresi (vagy / tmp), és csak a következőt írja be: gcc vagy ls, akkor tudom, hogy a valódi verziót futtatod, nem pedig egy rosszindulatú verziót, amelyet a tréfás barátod írt, és amely törli az összes fájlt. Egy másik példa erre a következő lehet: test vagy [, amely felülírhatja ezeket a parancsokat a shell parancsfájlokban, ha a shell nem rendelkezik beépített fájlokkal.
Ha . van utad utolsó bejegyzése egy kicsit biztonságosabb, de vannak más támadások is, amelyek ezt felhasználják. Könnyű kihasználni a gyakori elírási hibákat, például sl vagy ls-l. Vagy keressen egy közös parancsot, amely véletlenül nincs telepítve erre a rendszerre – például vim, mivel a sysadminek átlagosan nagyobb valószínűséggel írják be ezt.
Ez túl elméletinek hangzik? nagyrészt az, de mindenképpen megtörténhet a valóságban is, különösen a többfelhasználós rendszereken. Valójában itt van egy példa erről a webhelyről , ahol egy rendszergazda átváltott a felhasználók “otthoni könyvtárába, és megtalálta a ps hogy elfedje ezt a nevet futtatható fájl.
Megjegyzések
- Csak abszolút útvonalak legyenek a
PATHkörnyezeti változó.
Válasz
Ha komolyan gondolja, miért van szüksége rá./ az elején – ez azért van, mert (a Windows-tól eltérően) az aktuális könyvtár alapértelmezés szerint nem része az útvonalnak. Ha fut:
$ ls a shell megkeresi a ls parancsot a PATH környezeti változó könyvtáraiban (echo $PATH hogy megtekinthesse), és futtatja az első megtalált ls nevű futtatható fájlt. Ha beírja:
$ a.out a shell ugyanígy fog cselekedni – de valószínűleg nem fog találni egy a.out nevű futtatható fájlt. El kell mondania a shellnek, hogy hol a.out is – ez az aktuális könyvtárban (.), akkor az útvonal ./a.out.
Ha azt kérdezi, miért hívják “a.out”, ez csak a gcc alapértelmezett kimeneti fájlneve. Megváltoztathatja az arg parancs-sorával. Például:
$ gcc test.c -o test $ ./test Megjegyzések
- Köszönöm. Kétségem, hogy miért van szükséged a ./ gombra az elején … A “.” (az aktuális könyvtár bontásához), de miért ” / ” utána?
- / az útvonal elválasztó a Linuxban, ezért arra használja, hogy elválassza a (.) könyvtárat a fájlnévtől (a.out). Enélkül érvényes .a.out van, amely érvényes fájlnév. (Próbálkozzon
touch .a.out; ls -lA, hogy lássa ezt.) - így adja meg a elérési út a Unixban,
<dir>/<file>, tehát alapvetően azt mondod, hogy futtass egy fájlt az aktuális könyvtárban, amelyet./test - Red Hat Linux 9? Ideje frissíteni!
- Windows 10 rendszeren a PowerShell az alapértelmezett shell, és ehhez a
./fájlra is szükség van egy futtatható fájl futtatásához az aktuális elérési útvonalon
Válasz
Megpróbálhatja hozzáadni a (z) :. -t a $ PATH változójához.
Próbálja ki az ALT + F2 billentyűkombinációt, és írja be a következőt: gksudo gedit /etc/environment, ha Linux / GTK-t futtat (ez van akkor, ha Ubuntut használ).
HOGYAN, Határozottan azt tanácsolom, hogy NE tegye ezt. Ez rossz, rossz és rossz.
Tudod, hogy az ilyen dolgok 1970 óta működnek. Van egy oka annak, hogy a jelenlegi könyvtár nem szerepel a $ PATH-ban.
. az aktuális könyvtár
.something rejtett fájl lenne (a készítéshez írja be az “ALT +” szót ezek megjelennek a Nautilusban, vagy próbálkozzon a “ls -la” paranccsal.
./someProgram.sh az, amit beír, hogy futtatható someProgramot futtasson .sh az aktuális könyvtárban.
.somethingElse azt jelentené, hogy van egy rejtett futtatható fájlja az aktuális könyvtárban, ami rossz ötlet.
Válasz
A teljesebb szabály valójában: ha bármilyen perjel / az útvonalon van, ne keressen PATH
Mielőtt belemennénk az indoklást, először tudnia kell erről a tényről: a következők egyikének futtatása:
bin/someprog vagy:
vagy:
cd bin ./myexec a bin/someprog végrehajtása a PATH változó pontosan ugyanezen okból: az összes bin/someprog, /bin/someprog és ./someprog van egy perjel /.
someprog önmagában nincs perjel /, ezért csak a PATH fájlban keres.
POSIX 7 ezt a szabályt adja meg itt: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01
PATH
[…] Ha a keresett útnév
<slash>-t tartalmaz, akkor az útvonal előtagokon keresztül történő keresést nem kell végrehajtani .
A / POSIX PATH-szabály indoklása
Tegyük fel, hogy fut:
someprog a következőre keresne:
- a CWD-hez képest először
- a PATH-hoz viszonyítva utána
Ezután, ha futni szeretne /bin/someprog a terjesztésedből, és meg is tetted:
someprog ez néha működne, mások viszont kudarcot vallanának, mert előfordulhat, hogy egy könyvtárban található, amely egy másik, nem kapcsolódó someprog programot tartalmaz.
Ezért hamarosan megtudhatja, hogy ez nem megbízható, és végül mindig a abszolút utak, amikor a PATH-t akarja használni, és ezzel leküzdi a PATH célját.
Ezért is nagyon rossz ötlet, ha relatív utak vannak a PATH-ban. “M rád nézek, node_modules/bin .
Ezzel szemben tegyük fel, hogy fut:
./someprog Keres:
- a PATH-hoz képest először
- a CWD-hez képest
Ezután, ha éppen egy szkriptet someprog töltött le egy git-tárból, és futtatni akarta a CWD-ből, soha nem lehet biztos abban, hogy ez a tényleges program, amely futni fog, mert lehet, hogy a disztrójának van egy:
/bin/someprog amely benned van PATH néhány csomagot, amelyet tavaly karácsony után túl sokat ivott.
Ezért ismét arra kényszerül, hogy a CWD-hez képest mindig teljes szkripteket futtasson teljes elérési utakkal, hogy tudja, mit futtat:
"$(pwd)/someprog" ami szintén nagyon idegesítő lenne.
Egy másik szabály, amellyel kísértésbe eshetsz, a következő lenne:
a relatív útvonalak csak PATH-ot, az abszolút utak csak CWD-t használnak
de ez ismét arra kényszeríti a felhasználókat, hogy mindig használja az abso-t lant útvonalak nem PATH szkriptekhez "$(pwd)/someprog" -vel.
A / elérési útvonal egyszerűen megjegyezhető megoldást kínál a kb problémára:
- perjel: ne használja a
PATH - nincs perjel: csak a
ami rendkívül egyszerűvé teszi mindig a futás megismerését, arra támaszkodva, hogy az aktuális könyvtárban található fájlok akár ./somefile vagy somefile, és ezért különleges jelentést ad egyiküknek.
Néha kissé bosszantó, hogy nem lehet keresni a some/prog esetében a PATH -hez képest, de erre nem látok józanabb megoldást.
aliasesek is, amelyek akadályozhatják az utat, nemcsak ..fájlban keresgél, akkor biztonsági kérdés lenne, Ön vagy valaki más helyettesítheti Példáulls(egyszerű vírus / trojen: készítsen egy zip fájlt, amelybenlsnevű futtatható fájl található, miközben valaki keres, futtatják ezt a futtatható fájlt, azt…). Ha a.fájlban keresett utoljára, akkor sokáig őrülhet, és nem tudja, miért nem működik a programja (pl. A teszt nevű programot hajtja végre, a futtatott program helyett a rendszer tesztprogram. Ami nem eredményez kimenetet).