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?

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.

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.