Gdzie jest dobre stałe miejsce do instalowania niestandardowych skryptów bash?

32

Mam zamiar zainstalować „leiningen”, który jest skryptem bash dla języka programowania clojure z dużą użytecznością ... ... ale nie jestem pewien, gdzie właściwe jest -put- skrypt wykonywalny w systemie Linux system, aby był stale i stabilnie dostępny.

Nie sądzę, żeby gdziekolwiek w / home miało sens, ale nie wiem, który katalog / katalogi powinny być do tego użyte.

/ usr / share?

— Kzqai
źródło

1

pathname.com/fhs/pub/fhs-2.3.html

— Ignacio Vazquez-Abrams

45

(Uwaga: ~tłumaczy jak /home/userw tym poście)

Osobiście umieszczam wszystkie niestandardowe skrypty systemowe /usr/local/bini wszystkie osobiste skrypty bash ~/bin. Bardzo niewiele programów, które instaluję, umieszcza się w /usr/local/binkatalogu, więc nie jest zbyt zagracone i było już w $PATHzmiennej na większości moich komputerów.

Aby dodać /usr/local/bindo ścieżki systemowej (jeśli jeszcze jej nie ma), dodaj to do /etc/profile:

PATH=$PATH:/usr/local/bin
export PATH

Aby dodać ~/bindo ścieżki użytkownika, dodaj to do ~/.bash_profile:

PATH=$PATH:$HOME/bin
export PATH

Czasami domyślny .bash_profileplik będzie mieć if który automatycznie dodaje ~/binsię $PATH, jeśli istnieje, więc utworzyć ~/bini otworzyć nowy terminal, aby zobaczyć, czy twoje już to robi.

— Trey Hunner
źródło

BSD robią to domyślnie.

— Chris S

@Chris: BSD umieszczają wiele rzeczy w / usr / local / bin

— Dan Andreatta

Jaka jest różnica między skryptami bash a skryptami systemowymi i czy istnieje powód, aby je rozdzielić?

— Hashim

@Hashim Oczywiście nie mogę wypowiadać się w imieniu Trey, ale narzędzia, które opracowujesz dla własnych potrzeb, mają tendencję do „przechodzenia” na narzędzia systemowe, gdy zauważysz, że rozwiązują problem, z którym borykają się inni, lub masz inną instalację systemową, która zależy na jednym z tych narzędzi. Podejrzewam, że próg instalacji czegoś systemowego jest raczej wysoki dla większości programistów. Ponadto narzędzie, które udostępniasz, musi mieć dokumentację itp., Której wielu programistów rzadko pisze inaczej.

— tripleee

Nawiasem mówiąc, nie ma potrzeby exportwielokrotnego wprowadzania zmiennej (i prawdopodobnie twój system jest już oznaczony PATHdo eksportu, więc nie musisz tego robić sam).

— tripleee

9

/ usr / local / to naprawdę właściwe miejsce, podczas gdy / opt jest naprawdę przeznaczony do aplikacji innych firm; „/ opt jest zarezerwowany do instalacji dodatkowych pakietów aplikacji”. Jest to część standardu hierarchii systemów plików.

Zobacz http://www.pathname.com/fhs/pub/fhs-2.3.html w celu omówienia / opt.

W przypadku / usr / local / służy do „użytku przez administratora systemu”. Tylko nie zapomnij o rzeczach tam zawartych - udokumentuj to.

— Jamieson Becker
źródło

Podany link informuje: „Katalogi / opt / bin, / opt / doc, / opt / include, / opt / info, / opt / lib i / opt / man są zastrzeżone do użytku lokalnego administratora systemu”. W usłudze / usr / local nie ma nic. Wspomniany jest tylko / usr / local / share. Z drugiej strony, skompilowane programy są zwykle instalowane w / usr / local w systemie Linux. Czy nie uważasz, że / opt / bin jest lepszym miejscem do korzystania przez administratora systemu?

— raacer

1

@raacer Z mojego doświadczenia wynika, że /usr/local- jak sama nazwa wskazuje - jest dla lokalnego administratora i /optdla rzeczy, które nie są oficjalnie dystrybuowane, takich jak komercyjne oprogramowanie innych firm, które jest zarządzane w podobny sposób (może zostać zastąpione lub usunięte z aktualizacji z upstream), ale nie zarządzany przez menedżera pakietów dystrybucji, lub być może faktycznie dystrybuowany jako RPM lub .debpakiety, ale nie zorganizowany i spakowany zgodnie ze wszystkimi zasadami i konwencjami dystrybucji.

— tripleee

1

@raacer W /usr/localdalszej części dokumentu znajduje się osobna sekcja .

— tripleee

@raacer tripleee ma rację. Oto link: pathname.com/fhs/pub/ ... .. poprawne, skompilowane programy (zwykle open source), które zostały skompilowane / zbudowane specjalnie dla tego systemu lub współużytkowane przez kilka systemów (ale nie są częścią normalnego pakowania / dystrybucji systemu operacyjnego, ale które w dużej mierze opierają się na współdzielonych bibliotekach) powinny być zainstalowane w / usr / local (w zasadzie odzwierciedla hierarchię / usr). Oprogramowanie innych firm, które są skompilowane w możliwie innym systemie z możliwym wsparciem własnej biblioteki (tj. Firefox, userify), powinno przejść do / opt.

— Jamieson Becker

3

Historycznie używałbyś czegoś takiego jak / opt. Wszystko jest w porządku, o ile jest aktualizowane w $ PATH dla użytkowników, którzy powinni je mieć (stąd wszystko w / home jest złym pomysłem).

— Tony
źródło

2

/usr/share/clojurewydaje się być powszechnym miejscem do umieszczania plików binarnych i bibliotek clojure - dlaczego nie wiem, wydaje się to naturalne /usr/local/share/clojure- dlatego tworzenie sitepodkatalogu dla tych skryptów bash wydaje się w porządku.

Chodzi o to, że bardziej sensowne jest organizowanie skryptów według funkcji, a nie wszystkie skrypty bash w tym samym miejscu.

— Charles Stewart
źródło

1

Istnieje kilka problemów z użyciem /usr/sharetego. Przede wszystkim shareoznacza pliki niezależne od architektury (tj. Współdzielone między architekturami). Z tego powodu biblioteki i pliki wykonywalne nie należą do sharekatalogu. Po drugie, z wyjątkiem /usr/localniczego innego, niż menedżer pakietów dystrybucyjnych powinien kiedykolwiek pisać /usr.

— kasperd

2

/usr/local, Uważam, że istnieje pewne zamieszanie w znaczeniu „lokalny”.

Jak rozumiem, „lokalny” nie oznacza „pochodzący z / z lokalnego komputera”, ale, mówiąc prościej, „specyficzny dla lokalnego komputera”, który może, ale nie musi, pochodzić z / z lokalnego komputera.

— Hatebit
źródło