/ usr / bin vs / usr / local / bin på Linux (Norsk)

1. /bin (og /sbin) var ment for programmer som trengte å være på en liten / partisjon før den større /usr osv. partisjoner ble montert. I disse dager fungerer det stort sett som en standardplassering for nøkkelprogrammer som /bin/sh, selv om den opprinnelige hensikten fremdeles kan være relevant for f.eks. installasjoner på små innebygde enheter.

2. /sbin, til forskjell fra /bin, er for systemadministrasjonsprogrammer (som normalt ikke brukes av vanlige brukere) som trengs før /usr er montert.

3. /usr/bin er for distribusjonsstyrte normale brukerprogrammer.

4. Det er en /usr/sbin med samme forhold til /usr/bin som /sbin må /bin.

5. /usr/local/bin er for vanlige brukerprogrammer ikke administrert av distribusjonspakkeforvalteren, f.eks. lokalt kompilerte pakker. Du bør ikke installere dem i /usr/bin fordi fremtidige distribusjonsoppgraderinger kan endre eller slette dem uten advarsel.

6. /usr/local/sbin, som du sikkert kan gjette på dette punktet, er å /usr/local/bin som /usr/sbin til /usr/bin.

I tillegg er det også /opt som er for monolitiske ikke-distribusjonspakker, selv om før de ble ordentlig integrert, plasserte forskjellige distribusjoner Gnome og KDE der. Generelt sett bør du reservere den for store, dårlig oppførte tredjepartspakker som Oracle.

Kommentarer

• Jeg synes dette svaret gjør en god jobb med å avklare. et vanlig sett med konvensjoner, men dette innlegget fra Rob Landley er en veldig flott lesning hvis du vil ha innsikt i tullet … lists.busybox.net/pipermail/busybox/2010 -Desember / 074114.html
• refspecs.linuxfoundation.org/fhs.shtml for den kanoniske gjeldende referansen. Linken til @kojiro er utdatert og har ikke ‘ den nye spesifikasjonen.
• Hvor setter jeg en søppel jeg har lastet ned fra internett? Fra beskrivelsen din høres det ut som om den skal gå i / usr / local / bin eller / usr / bin. Er / usr / bin noe jeg aldri skal berøre manuelt, og bare la pakkebehandleren leke med?
• @DidierA. legg den i ~/bin og legg til den katalogen i PATH som bruker … Takk for notatet, jeg slettet min alvorlig utdaterte kommentar.
• Jeg fant svar på den første delen av spørsmålet mitt her: superbruker.com/a/238993/425838 . Forrang er basert på rekkefølge i systemet PATH variabel, og echo $PATH for meg viser /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games , som betyr at kjørbare filer i /usr/local/bin har forrang over de i /usr/bin som går foran de i /bin.

Jeg anbefaler å ta en titt på man-siden for filsystemhierarkiet:

man hier 

som også er tilgjengelig online, for eksempel: http://linux.die.net/man/7/hier . Relevante deler er kopiert nedenfor. Avhengig av systemet ditt, kan det si noe annet.

Navn

hier – beskrivelse av filsystemhierarkiet

Beskrivelse

Et typisk Linux-system har blant annet følgende kataloger:

/bin

Denne katalogen inneholder kjørbare programmer som er nødvendige for en enkelt bruker modus og for å bringe systemet opp eller reparere det.

/sbin

Som /bin, denne katalogen inneholder kommandoer som trengs for å starte systemet, men som vanligvis ikke kjøres av vanlige brukere.

/usr/bin

Dette er den primære katalogen for kjørbare programmer. De fleste programmer utført av vanlige brukere som ikke er nødvendig for oppstart eller for reparasjon av systemet og som ikke er installert lokalt, bør plasseres i denne katalogen.

/usr/local/bin

Binarier for programmer lokale til nettstedet.

/usr/local/sbin

Lokalt installerte programmer for systemadministrasjon.

/usr/sbin

Denne katalogen inneholder programbinarier for systemadministrasjon som ikke er avgjørende for oppstartsprosessen, for montering /usr eller for systemreparasjon .

Kommentarer

• Dette ‘ t svar på brukeren ‘ spørsmål.
• Man-siden inneholder en oppføring for hver av papirkurven, og forklarer hva går inn i dem, som var et av spørsmålene.

Hierark for filsystem chy Standard -oppføring i Wikipedia hjalp meg med å svare på det samme spørsmålet når jeg hadde det, pluss at det har en veldig forklarende tabell.

Utdrag fra den siden ¹ :

/bin Essential command binaries that need to be available in single user mode; for all users, e.g., cat, ls, cp. /usr/bin Non-essential command binaries (not needed in single user mode); for all users. /usr/local Tertiary hierarchy for local data, specific to this host. Typically has further subdirectories, e.g., bin, lib, share /usr/sbin Non-essential system binaries, e.g., daemons for various network-services. /sbin Essential system binaries, e.g., fsck, init, route. 

¹ _{Hentet 19. juni 2019; permalink .}

sbin kataloger inneholder programmer som vanligvis bare er systemadministrasjon. Programmer for vanlige brukere skal aldri gå i dem.

Noen få programmer er nødvendig under oppstart, og havner i /bin/ eller /sbin/. Disse må være tilgjengelige før filsystemer monteres. Ting som mount og fsck som kreves for å kontrollere og montere filsystemer, må være der.

Mest pakket programmer havner i /usr/bin/ og /usr/sbin/. Disse kan være på et annet filsystem enn rotfilsystemet. I noen tilfeller kan de være på en nettverksmontert stasjon.

Lokale programmer og skript hører hjemme i /usr/local/bin/ og /usr/local/sbin/ . Dette identifiserer dem som klart ikke-standardiserte, og muligens bare tilgjengelige på stedet.

For ytterligere forklaring, prøv å kjøre kommandoen man hier som skal gi en beskrivelse av det anbefalte filsystemhierarkiet for distribusjonen din. Det kan også være lurt å lese om Filsystemhierarki på Wikipedia

Kommentarer

• +1 En veldig kortfattet forklaring hvis toppen er litt for mye.
• » Lokale programmer og skript hører hjemme i / usr / local / bin / og / usr / local / sbin / » – Du mener lokale programmer som i » ikke i det hele tatt en del av operativsystemet, men jeg bestemte meg for å installere dem og vil bruke dem «?

På 1970-tallet hadde UNIX alle offisielle kjørbare filer i /bin og /usr/bin var et sted under brukernes hjemmekataloger (f.eks. /usr/dmr) som var tilgjengelig for alle brukere å lagre egne binærfiler som også hadde vært av interesse for andre.

Resultatet av dette åpne /usr/bin var et useriøst verksted med papirløs programvare, og så Stephen Bourne wro te et cron-skript som sjekket for nye binærfiler hver kveld og fjernet alle binærfiler som ikke hadde dokumentasjon eller som har blitt oppdatert uten å oppdatere dokumentasjonen også.

På slutten av 1970-tallet, /usr/bin ble integrert i OS-basedistribusjonen, og folk begynte å bruke /usr/local/bin i den forrige åpne /usr/bin .

Etter en stund brukte sysadmins /usr/local/bin til å lagre ikke-lokal programvare som ble importert fra nettverket (f.eks. USENET) og da UNIX-selskaper ikke likte å gjenta den samme feilen som med /usr/bin igjen, var det en filsystemhierarkikonferanse rundt 1987 hvor alle UNIX-selskaper ble enige om å gi opp /usr/local/bin og å bruke /opt/<vendor>/bin i stedet.

Dessverre fulgte Linux-distribusjoner ikke denne avgjørelsen ….

Kommentarer

• Selv om det er veldig interessant, er ingenting av dette prøver til og med å svare på spørsmålet som ikke handlet om /opt og ikke om UNIX, men om Linux. Dette er som å svare på » Hvorfor har biler 4 hjul? » med » Sykler har 2! Dessverre hjelper biler ikke ‘ t. » som ikke ‘ ikke hjelper OP å forstå hvorfor biler har 4.
• Hvis du ikke klarer å bruke den gitte forklaringen som en forklaring på bakgrunnen til Linux og det faktum at Linux liker å etterligne UNIX, kan du mangle den nødvendige bakgrunnen.
• Interessant, men noe jeg blir forvirret av og som kanskje også bare er historisk. I dag er nedlasting av en papirkurv online, og en firmakasse ikke ‘ t veldig forskjellig. Hvis Joe Blow lager et program, og jeg laster det ned, hvorfor ikke legge det i / opt / JowBlow / bin i stedet for / usr / local / bin. Er det et spørsmål om klarert leverandør kontra utro? ‘ ser ikke ut til å være fornuftig for meg.
• Jeg skulle ønske jeg hadde kjent dette ‘ eksakt ‘ historie for noen år tilbake. a) Jeg lurte på hvorfor AIX unngikk / usr / local, bruker / opt / IBM og / opt / ibm og bullfreeware bruker / opt / freeware – og hvorfor jeg BØR ha brukt en annen vei (ikke bare / opt / * sbin). Når det gjelder semi-relevans med Linux – bedre GNU-verktøy – er standard –prefix i autoverktøy / usr / local. Synd autotools (automake, autoconf, etc. følger ikke … Men vi overlever alle og lærer hvor distrub. || leverandører legger programmene sine.
• Kan vi ha en annen av disse konferansene? Akkurat denne gangen LYTTER ALLE!