Hvorfor bruker vi ./filename til å utføre en fil i linux?
Hvorfor ikke bare skriv det inn som andre kommandoer gcc, ls etc …
Kommentarer
- Ville ‘ t den første linjen ville være bedre skrevet som » Hvorfor bruker vi
./command_namefor å utføre en kommando i linux? » - bruker15760, Nei, fordi vi vil at spørsmål skal være oppdagelig i søkemotorer og ikke alle som har dette spørsmålet er naturlig født ‘ nixsters (:
Svar
I Linux, UNIX og relaterte operativsystemer, betegner . den aktuelle katalogen. Siden du vil kjøre en fil i din nåværende katalog og den katalogen ikke er i $PATH, trenger du ./ bit for å fortelle skallet hvor den kjørbare er. Så, ./foo betyr å kjøre den kjørbare filen som heter foo som er i denne katalogen.
Du kan bruke type eller which for å få fullstendig vei til alle kommandoene du finner i $PATH.
Kommentarer
Svar
Det bokstavelige svaret er som andre har gitt: fordi den nåværende katalogen ikke er «$PATH.
Men hvorfor? Kort fortalt er det for sikkerhet. Hvis du ser i noen andres hjemmekatalog (eller / tmp), og bare skriver gcc eller ls, vil du vet du at du kjører den virkelige, ikke en ondsinnet versjon som prankster-vennen din har skrevet som sletter alle filene dine. Et annet eksempel er test eller [, som kan overstyre disse kommandoene i skallskript, hvis skallet ditt ikke har de som innebygde.
Å ha . som siste oppføring i din vei er litt tryggere, men det er andre angrep som gjør bruk av det. En enkel er å utnytte vanlige skrivefeil, som sl eller ls-l. Eller finn en vanlig kommando som tilfeldigvis ikke er installert på dette systemet – vim, for eksempel, fordi sysadminer har sannsynlighet over gjennomsnittet for å skrive det.
Høres dette for teoretisk ut? Det er stort sett , men det kan definitivt skje i virkeligheten, spesielt på flerbruker-systemer. Faktisk er her et eksempel fra dette nettstedet der en administrator byttet til en brukeres hjemmekatalog og fant ps skal maskeres av en kjørbar fil med det navnet.
Kommentarer
- Bare ha absolutte baner i
PATHmiljøvariabel.
Svar
Hvis du mener, hvorfor trenger du det./ i starten – det er fordi (i motsetning til i Windows), den nåværende katalogen ikke er en del av banen din som standard. Hvis du kjører:
$ ls , ser skallet ditt etter ls i katalogene i PATH-miljøvariabelen (echo $PATH for å se det), og kjører den første kjørbare kalt ls som den finner. Hvis du skriver:
$ a.out vil skallet gjøre det samme – men det vil sannsynligvis ikke finne en kjørbar som heter a.out. Du må fortelle skallet hvor a.out er – det er i den nåværende katalogen (.), så er banen ./a.out.
Hvis du spør hvorfor det heter «a.out», det er bare standard utdatafilnavn for gcc. Du kan endre det med kommandolinjearg-arg. For eksempel:
$ gcc test.c -o test $ ./test Kommentarer
- Takk. Min tvil er hvorfor trenger du ./ i starten …. Jeg fikk bruk av «.» (for å vise den nåværende katalogen) men hvorfor » / » etter det?
- / er stiseparatoren i Linux, så du bruker den til å skille katalogen (.) fra filnavnet (a.out). Uten den har du .a.out som er gyldig filnavn i seg selv. (Prøv
touch .a.out; ls -lAfor å se dette.) - det er slik du spesifiserer sti i Unix,
<dir>/<file>så du sier i utgangspunktet utfør en fil i den gjeldende katalogen, som er indikert av./test - Red Hat Linux 9? Tid for oppgradering!
- På Windows 10 er PowerShell standard skallet nå, og det krever også
./for å kjøre en kjørbar i den nåværende banen
Svar
Du kan prøve å legge til :. til $ PATH-variabelen.
Prøv ALT + F2 og skriv: gksudo gedit /etc/environment hvis du kjører Linux / GTK (dette er hva du har hvis du bruker Ubuntu).
MEN, Jeg anbefaler deg på det sterkeste å IKKE gjøre det. Det er dårlig, dårlig, dårlig og dårlig.
Du vet, den slags ting fungerer som dette siden 1970. Det er en grunn til at den nåværende katalogen ikke er inkludert i $ PATH.
. er den nåværende katalogen
.something ville være en skjult fil (Type «ALT +» for å lage dem vises i Nautilus, eller prøv «ls -la«.
./someProgram.sh er det du skriver for å KJØRE et kjørbart program .sh i gjeldende katalog.
.somethingElse vil bety at du har en skjult kjørbar fil i den gjeldende katalogen, noe som er en dårlig ide.
Svar
Den mer komplette regelen er faktisk: hvis noen skråstrek / er i banen, ikke søk PATH
Før vi går inn på begrunnelsen, bør du først vite om dette faktum: kjører en av:
bin/someprog eller:
eller:
cd bin ./myexec kjør bin/someprog uten å søke i PATH av nøyaktig samme årsak: alle bin/someprog, /bin/someprog og ./someprog har en skråstrek / i seg.
someprog alene har ikke en skråstrek /, og søker derfor bare i PATH.
POSIX 7 spesifiserer denne regelen på: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01
PATH
[…] Hvis stienavnet som søkes inneholder en
<slash>, skal ikke søket gjennom sti-prefiksene utføres .
Begrunnelse for / POSIX PATH-regelen
Anta at kjører:
someprog vil søke:
- i forhold til CWD først
- i forhold til PATH etter
Hvis du vil kjøre /bin/someprog fra distro, og du gjorde:
someprog det ville noen ganger fungere, men andre ville det mislykkes, fordi du kan være i en katalog som inneholder et annet ikke-relatert someprog -program.
Derfor vil du snart lære at dette ikke er pålitelig, og du vil ende opp med å alltid bruke absolutte baner når du vil bruke PATH, og derfor beseire formålet med PATH.
Dette er også grunnen til at det å ha relative baner i PATH er en veldig dårlig idé. Jeg «m ser på deg, node_modules/bin .
Omvendt, anta at kjøring:
./someprog Vil søke:
- i forhold til PATH først
- i forhold til CWD etter
Så, hvis du nettopp lastet ned et skript someprog fra et git-arkiv og ønsket å kjøre det fra CWD, vil du aldri være sikker på at dette er det faktiske programmet som vil kjøre, fordi kanskje distro har din:
/bin/someprog som er i deg PATH fra noen pakker du installerte etter å ha drukket for mye etter jul i fjor.
Derfor vil du nok en gang bli tvunget til å alltid kjøre lokale skript i forhold til CWD med full stier for å vite hva du kjører:
"$(pwd)/someprog" som også vil være ekstremt irriterende.
En annen regel som du kan bli fristet til å komme på, er:
relative stier bruker bare PATH, bare absolutte stier CWD
men nok en gang tvinger dette brukerne til bruk alltid abso lute-baner for ikke-PATH-skript med "$(pwd)/someprog".
/ banesøkingsregelen tilbyr en enkel å huske løsning til om-problemet:
- skråstrek: ikke bruk
PATH - ingen skråstrek: bruk bare
PATH
som gjør det veldig enkelt å alltid vite hva du kjører, ved å stole på at filer i den aktuelle katalogen kan uttrykkes enten som ./somefile eller somefile, og det gir en av dem spesiell betydning.
Noen ganger er det litt irriterende at du ikke kan søke for some/prog i forhold til PATH, men jeg ser ikke en bedre løsning på dette.
aliases som kan komme i veien, ikke bare$PATH..først, ville det være et sikkerhetsproblem, du eller noen andre kan erstattelsfor eksempel (et enkelt virus / trojen: lag en zip-fil med en kjørbar som heterls, som noen leter gjennom, de kjører denne kjørbare filen, at …). Hvis det ble søkt.sist, kan du bruke lang tid på å bli gal uten å vite hvorfor programmet ikke fungerer (f.eks. Lager du et program som heter test, i stedet for å kjøre programmet det kjører systemtestprogrammet. Som ikke gir utdata.