Hvorfor bruger vi ./filename til at udføre en fil i linux?

Hvorfor ikke bare indtast det som andre kommandoer gcc, ls osv …

Kommentarer

  • Ville ‘ t den første linje ville blive bedre skrevet som ” Hvorfor bruger vi ./command_name for at udføre en kommando i linux? ”
  • user15760, Nej, fordi vi gerne vil have spørgsmål der kan findes i søgemaskiner, og ikke alle, der har dette spørgsmål, er naturlige fødte ‘ nixsters (:

Svar

I Linux, UNIX og relaterede operativsystemer betegner . den aktuelle mappe. Da du vil køre en fil i din nuværende mappe og den mappe ikke er i din $PATH, skal du bruge ./ bit for at fortælle skallen, hvor den eksekverbare er. Så, ./foo betyder at køre den eksekverbare kaldet foo der er i denne mappe.

Du kan bruge type eller which for at få den fulde sti til alle kommandoer, der findes i dine $PATH.

Kommentarer

  • Det er meget almindeligt at udføre programmer i den aktuelle mappe. Hvorfor søger ikke ‘ også shell derinde? Den søger først ind. Derefter i $ PATH.
  • der er også alias es, der kan komme i vejen, ikke bare $PATH.
  • @Michael sikkerhed og sundhed: Hvis det søgte i . først, ville det være et sikkerhedsproblem, kunne du eller en anden erstatte ls for eksempel (en simpel virus / trojen: lav en zip-fil med en eksekverbar navn med navnet ls, som nogen søger igennem, de kører denne eksekverbare, at …). Hvis det sidst søgte ., kan du bruge lang tid på at blive skør uden at vide, hvorfor dit program ikke fungerer (f.eks. Laver du et program kaldet test, i stedet for at køre dit program kører det systemtestprogrammet. Hvilket producerer ingen output).
  • @jcubic at ‘ er en dårlig idé. Se kommentaren ovenfor. Tidligere søgte DOS i den aktuelle mappe, og denne adfærd blev transporteret til Windows cmd, der introducerer en masse sikkerhedsproblemer. MS løste det i PowerShell, og nu skal du bruge. \ Til at køre programmet i den aktuelle mappe
  • @ ctrl-alt-delor: Da jeg var på universitetet i slutningen af 80 ‘ s, dette var en almindelig (forbudt) taktik. Skrive et ” ls ” -program og lade det være i din hjemmemappe, hvis en anden kom snuende. Programmet blev kaldt en ” get shell ” IIRC. Det ville forsøge at få brugeroplysningerne til brugeren, der kører kommandoen – og derefter måske udskrive en falsk mappeliste for at lade dem være uvidende.

Svar

Det bogstavelige svar er som andre har givet: fordi den aktuelle mappe ikke er t i din $PATH.

Men hvorfor? Kort sagt er det for sikkerhed. Hvis du “kigger i en andens hjemmekatalog (eller / tmp) og bare skriver gcc eller ls, vil du ved, at du kører den rigtige, ikke en ondsindet version, som din prankster-ven har skrevet, som sletter alle dine filer. Et andet eksempel ville være test eller [, som muligvis tilsidesætter disse kommandoer i shell-scripts, hvis din shell ikke har dem som indbyggede.

At have . som sidste indgang i din sti er lidt mere sikker, men der er andre angreb, der gør brug af det. En let er at udnytte almindelige skrivefejl som sl eller ls-l. Eller find en almindelig kommando, der tilfældigvis ikke er installeret på dette system – vim, for eksempel, da sysadmins har en sandsynlighed for at skrive det over gennemsnittet.

Lyder dette for teoretisk? Det er stort set , men det kan bestemt ske i virkeligheden, især på flerbruger-systemer. Faktisk er her et eksempel fra dette websted , hvor en administrator skiftede til en brugeres “hjemmekatalog og fandt ps skal maskeres af en eksekverbar fil med dette navn.

Kommentarer

  • Bare have absolutte stier i PATH miljøvariabel.

Svar

Hvis du mener, hvorfor har du brug for det?/ i starten – det skyldes, at (i modsætning til i Windows), er den aktuelle mappe som standard ikke en del af din sti. Hvis du kører: 

$ ls

søger din shell efter ls i telefonbøgerne i din PATH-miljøvariabel (echo $PATH for at se det), og kører den første eksekverbare kaldet ls, som den finder. Hvis du skriver: 

$ a.out

vil skallen gøre det samme – men det vil sandsynligvis ikke finde en eksekverbar fil, der hedder a.out. Du skal fortælle skallen, hvor a.out er – det er det i den aktuelle mappe (.), så er stien ./a.out.

Hvis du spørger, hvorfor det kaldes “a.out”, det er bare standardoutputfilnavnet for gcc. Du kan ændre det med -o kommandolinjearg. For eksempel: 

$ gcc test.c -o test $ ./test

Kommentarer

  • Tak. Min tvivl er, hvorfor har du brug for ./ i starten …. Jeg fik brugt “.” (for at placere den aktuelle mappe) men hvorfor ” / ” efter det?
  • / er stiadskilleren i Linux, så du bruger den til at adskille biblioteket (.) fra filnavnet (a.out). Uden det har du .a.out, som er gyldigt filnavn i sig selv. (Prøv touch .a.out; ls -lA for at se dette.)
  • det er sådan, du specificerer sti i Unix, <dir>/<file> så du grundlæggende siger udføre en fil i den aktuelle mappe, som er angivet med ./test
  • Red Hat Linux 9? Tid til at opgradere!
  • På Windows 10 er PowerShell standard shell nu, og det kræver også ./ for at køre en eksekverbar i den aktuelle sti

Svar

Du kan prøve at føje :. til din $ PATH-variabel.

Prøv ALT + F2 og skriv: gksudo gedit /etc/environment hvis du kører Linux / GTK (dette er hvad du har, hvis du bruger Ubuntu).

MEN Jeg anbefaler dig stærkt IKKE at gøre det. Det er dårligt dårligt dårligt og dårligt.

Du ved, den slags ting fungerer som dette siden 1970. Der er en grund til, at den aktuelle mappe ikke er inkluderet i $ PATH.

. er den aktuelle mappe

.something ville være en skjult fil (skriv “ALT +” for at oprette dem vises i Nautilus, eller prøv “ls -la“.

./someProgram.sh er det, du skriver for at KØRE et eksekverbart program .sh i den aktuelle mappe.

.somethingElse ville betyde, at du har en skjult eksekverbar fil i den aktuelle mappe, hvilket er en dårlig idé.

Svar

Den mere komplette regel er faktisk: hvis nogen skråstreg / er i stien, søg ikke PATH

Før vi går ind begrundelsen, skal du først vide om denne kendsgerning: køre en af: 

bin/someprog

eller:

eller: 

cd bin ./myexec

udfør bin/someprog uden at søge i PATH variabel af nøjagtig samme årsag: alle bin/someprog, /bin/someprog og ./someprog har en skråstreg / i dem.

someprog alene har ikke en skråstreg /, og søger derfor kun i PATH.

POSIX 7 specificerer denne regel på: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01

PATH

[…] Hvis det søgenavn, der søges, indeholder en <slash>, skal søgningen gennem sti-præfikser ikke udføres .

Begrundelse for / POSIX PATH-reglen

Antag at kører: 

someprog

vil søge:

  • i forhold til CWD først
  • i forhold til PATH efter

Så hvis du vil køre /bin/someprog fra din distro, og du gjorde: 

someprog

det ville undertiden fungere, men andre ville det mislykkes, fordi du er muligvis i et bibliotek, der indeholder et andet ikke-relateret someprog -program.

Derfor vil du snart lære, at dette ikke er pålideligt, og du vil ende med altid at bruge absolutte stier, når du vil bruge PATH, og derfor besejrer formålet med PATH.

Dette er også grunden til at have relative stier i din PATH er en rigtig dårlig idé. Jeg “m ser på dig, node_modules/bin .

Omvendt, antag at kørsel: 

./someprog

Vil søge:

  • i forhold til PATH først
  • i forhold til CWD efter

Så hvis du lige har downloadet et script someprog fra et git-arkiv og vil køre det fra CWD, ville du aldrig være sikker på, at dette er det egentlige program, der ville køre, for måske har din distro et: 

/bin/someprog

som er i dig PATH fra en pakke, du installerede efter at have drukket for meget efter jul sidste år.

Derfor vil du igen blive tvunget til altid at køre lokale scripts i forhold til CWD med fulde stier for at vide, hvad du kører: 

"$(pwd)/someprog"

hvilket også ville være ekstremt irriterende.

En anden regel, som du måske bliver fristet til at komme med, er:

relative stier bruger kun PATH, kun absolutte stier CWD

men endnu en gang tvinger dette brugere til brug altid abso lute-stier til ikke-PATH-scripts med "$(pwd)/someprog".

/ stisøgningsreglen giver en let at huske løsning til om-problemet:

  • skråstreg: brug ikke PATH
  • ingen skråstreg: brug kun PATH

hvilket gør det super nemt at altid vide, hvad du kører, ved at stole på, at filer i den aktuelle mappe kan udtrykkes enten som ./somefile eller somefile, og det giver en af dem særlig betydning.

Nogle gange er det lidt irriterende, at du ikke kan søge for some/prog i forhold til PATH, men jeg kan ikke se en sundere løsning på dette.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *