Gdzie należy umieścić lokalny plik wykonywalny?


62

Mam plik wykonywalny dla klienta kontroli wersji perforce ( p4). Nie mogę go umieścić, /opt/localponieważ nie mam uprawnień roota. Czy istnieje standardowa lokalizacja, w której należy ją umieścić $HOME?

Czy hierarchia systemu plików ma konwencję, która mówi, że należy umieścić lokalne pliki wykonywalne / pliki binarne $HOME/bin?

Nie mogłem znaleźć takiej konwencji wspomnianej w artykule Wikipedii dla FHS .

Ponadto, jeśli rzeczywiście istnieje konwencja, czy musiałbym wyraźnie podać ścieżkę do $HOME/binkatalogu lub jakąkolwiek lokalizację binkatalogu?

Odpowiedzi:


64

Ogólnie rzecz biorąc, jeśli niesystemowy zainstalowany i obsługiwany plik binarny musi być dostępny dla całego systemu dla wielu użytkowników, powinien zostać umieszczony przez administratora /usr/local/bin. Istnieje pełna hierarchia, w ramach /usr/localktórej zwykle używane są lokalnie skompilowane i zainstalowane pakiety oprogramowania.

Jeśli jesteś jedynym użytkownikiem pliku binarnego, instalacja w $HOME/binodpowiedniej lokalizacji jest możliwa, ponieważ możesz go zainstalować samodzielnie, a Ty będziesz jedynym konsumentem. W przypadku kompilacji pakietu oprogramowania ze źródła należy również utworzyć częściową lub pełną lokalną hierarchię w $HOMEkatalogu. Pełna lokalna hierarchia wyglądałaby tak.

  • $HOME/bin Lokalne pliki binarne
  • $HOME/etc Konfiguracja systemu specyficzna dla hosta dla lokalnych plików binarnych
  • $HOME/games Lokalne pliki binarne gier
  • $HOME/include Lokalne pliki nagłówka C.
  • $HOME/lib Biblioteki lokalne
  • $HOME/lib64 Lokalne biblioteki 64-bitowe
  • $HOME/man Lokalne instrukcje online
  • $HOME/sbin Pliki binarne systemu lokalnego
  • $HOME/share Hierarchia niezależna od lokalnej architektury
  • $HOME/src Lokalny kod źródłowy

Podczas uruchamiania configurenależy zdefiniować lokalną hierarchię instalacji, określając $HOMEjako prefiks domyślnych ustawień instalacji.

./configure --prefix=$HOME

Teraz po make && make installuruchomieniu skompilowane pliki binarne, pakiety, strony podręcznika i biblioteki zostaną zainstalowane w $HOMElokalnej hierarchii. Jeśli nie utworzyłeś ręcznie $HOMElokalnej hierarchii, make installutworzy katalogi potrzebne pakietowi oprogramowania.

Po zainstalowaniu $HOME/binmożesz dodać $HOME/bindo swojego $PATHpliku binarnego lub wywołać go za pomocą absolutu $PATH. Niektóre dystrybucje będą domyślnie dołączone $HOME/bindo twojego $PATH. Możesz to przetestować, echo $PATHsprawdzając, czy $HOME/bintam jest, lub umieścić plik binarny $HOME/bini uruchomić which binaryname. Jeśli wróci $HOME/bin/binaryname, domyślnie znajduje się w zmiennej $ PATH.


5
tak długo, jak $ HOME nie znajduje się na zamontowanym systemie plików noexec. / tmp / jest zwykle montowany również jako noexec.
ewanm89

3
Jest to poprawne, jest to część standardu Hierarchii Systemów Plików (FHS). pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
Patrick

29
Nie polecałbym używania $HOME. Powoduje to zalanie twojego katalogu domowego licznymi katalogami, które w ogóle Cię nie interesują. Kto chce mieć man, libitp jedynek w domu dir? Wolałbym stworzyć hierarchię poniżej $HOME/binlub $HOME/local. To dodaje tylko jeden podkatalog do katalogu domowego zamiast dziesięciu. Można PATHje łatwo dostosować do włączenia $HOME/bin/binlub $HOME/local/bin.
Marco

18
Jedną z opcji jest użycie $ HOME / .local / {bin, lib itp.}, Jak np. W specyfikacji XDG opartej na specyfikacji ( standard.freedesktop.org/basedir-spec/basedir-spec-latest.html ) i python ( python.org/dev/peps/pep-0370 )
janneb

4
@janneb Specyfikacja katalogu podstawowego XDG, do której się odwołujesz, tylko w $HOME/.local/sharewersji (wersja 0.7, 24 listopada 2010).
Piotr Dobrogost

27

Jak wspomniano wcześniej , /usr/localjest przeznaczony jako przedrostek dla oprogramowania zainstalowanego przez administratora systemu, podczas gdy /usrpowinien być używany dla oprogramowania zainstalowanego z pakietów dystrybucji.

Ideą jest to, aby uniknąć kolizji z rozproszonego oprogramowania (takie jak rpmi debpakiety) i dać Admin pełne panowanie nad „lokalnym” prefiksem.

Oznacza to, że administrator może zainstalować niestandardowo skompilowane oprogramowanie, wciąż korzystając z dystrybucji typu debian.

Z FHS

Oprogramowanie umieszczone w / lub / usr może zostać zastąpione przez uaktualnienia systemu (chociaż zalecamy, aby dystrybucje nie zastępowały danych w / etc w tych okolicznościach). Z tego powodu lokalnego oprogramowania nie wolno umieszczać poza / usr / local bez uzasadnionego powodu.

Podczas instalowania oprogramowania specyficznego dla użytkownika uther sugeruje użycie $HOMEjako prefiksu, ponieważ zapewnia to uprawnienia do zapisu. Osobiście uważam, że jestem $HOME/.localbardziej eleganckim rozwiązaniem, ponieważ pozwala uniknąć zaśmiecania twojego (mam nadzieję) ładnego i uporządkowanego katalogu domowego!

$HOME/.local/sharejest już używany w specyfikacji katalogu bazowego XDG freedesktop.org , więc nie trzeba wiele wyobrażać sobie dodawania $HOME/.local/bindo niego $PATHi tworzenia $HOME/.local/libitp., gdy jesteś przy nim.

Jeśli tak naprawdę nie chcesz, aby twój prefiks był ukrytym katalogiem, możesz łatwo utworzyć do niego również symboliczny link, np .:

ln -s .local ~/local

Dygresja

Warto zauważyć, że .config(nie .local/etc) jest wartością domyślną dla $XDG_CONFIG_HOMEplików konfiguracyjnych specyficznych dla użytkownika. Powinienem również zauważyć, że niestety duża część oprogramowania ignoruje XDG i tworzy pliki konfiguracyjne w dowolnym miejscu (zwykle w katalogu głównym $HOME). Należy również pamiętać, że $XDG_CONFIG_HOMEmoże być niezbrojony, jeśli $HOME/.configpożądane jest ustawienie domyślne .

Co dziwne, nie ma katalogu zarezerwowanego dla domyślnych plików konfiguracyjnych dystrybucji, więc nie ma sposobu, aby dowiedzieć się, czy plik /etczostał dostarczony przez dystrybucję, czy edytowany przez administratora systemu.


1
Nie mogę znaleźć żadnej wzmianki .localw FHS
Daniel Serodio

@DanielSerodio Jest w specyfikacji katalogu XDG, nowszym standardzie, który zyskuje na znaczeniu. Zobacz unix.stackexchange.com/questions/316765/… i superuser.com/questions/1170793/…
ivan_pozdeev

Ta uwaga dodatkowa /etcjest naprawdę irytująca przy zarządzaniu serwerem z wieloma administratorami - dość trudno jest śledzić niestandardowe zmiany w plikach conf.
naught101
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.