Gdzie powinienem umieścić moje skrypty bash


15

Mam kilka bardzo prostych skryptów bash, które zebrałem razem dla rzeczy, które robię regularnie. Jednym z nich jest uruchomienie duplikatu w celu wykonania moich zadań tworzenia kopii zapasowych. Nic mądrego, po prostu kilka stwierdzeń, jeśli ... to naprawdę stwierdzenia. Ponieważ należy to uruchamiać jako sudo, czy najlepszą praktyką byłoby umieszczenie mojego skryptu w katalogu / usr / bin (lub innej lokalizacji w zmiennej PATH), chown na root.root i chmod na 700?


Powiedziałbym, że używaj gitdo kontroli wersji swoich skryptów, umieszczaj lokalne kopie repozytoriów git w dowolnym miejscu ~, a następnie łącz je symbolicznie ~/bin.
edwinksl

Masz na myśli gitjak w githubchmurach?
WinEunuuchs2Unix

2
@ WinEunuuchs2Unix Jeśli chcesz, aby twoje skrypty były dostępne dla innych użytkowników, powinieneś je umieścić /usr/local/bin. W przeciwnym razie powiedziałbym, że po prostu je włóż ~/bin. Twoje skrypty w obu katalogach powinny być bezpieczne podczas aktualizacji.
edwinksl

2
Jak wyżej, umieść je w / usr / local / bin. Upewnij się tylko, że twoje skrypty są unikalne, a nie istniejące polecenie linux / nazwa binarna. Po prostu dodaję cyfrę na końcu każdego skryptu, który tworzę, ponieważ nie widziałem, aby wcześniej istniejące nazwy linuksów kończyły się na liczbie. (żeby nie powiedzieć, że niektóre naprawdę niejasne mogą ...)
doug

1
@edwinksl Prawie rok później muszę powiedzieć, że ~/binto najlepsze miejsce dla większości skryptów, ponieważ nie trzeba sudoich edytować tak, jak w przypadku, gdy są one przechowywane /usr/local/bin.
WinEunuuchs2Unix,

Odpowiedzi:


3

Zapisuję własne skrypty /opt/scripts.

Jeśli skrypt powinien być wykonywany przez każdego użytkownika systemu, możesz utworzyć symboliczne łącze do /usr/bin.

Jeśli tylko root powinien wykonać skrypt, możesz utworzyć dowiązanie symboliczne do /usr/sbin.

Polecenie dodania dowiązania symbolicznego w /usr/bin/:

ln -s /opt/scripts/<script> /usr/bin/

Możesz wykonać skrypt, ponieważ domyślnie /usr/bin/jest on w ŚCIEŻCE .


1
Poleciłbym, aby zamiast używać /usr/binjako celu dla skryptu powłoki użytkownika / lokalnego - aby był /usr/local/bin(lub /opt/bin) zgodnie ze standardem hierarchii systemów plików - Debian Wiki, aby uniknąć konfliktów (przez większość czasu chcesz, aby dostarczone przez Ubuntu skryty miały pierwszeństwo).
shalomb

W większości systemów /usr/local/binzastępuje /usr/bin, co pojawia się później na ścieżce. Jest to celowe, ponieważ system nie umieszcza tam plików, więc można tam umieszczać pliki, które POWINNY zastąpić pliki dostarczone przez system.
allo

Oznacziłem to jako prawidłową odpowiedź, mimo że obie odpowiedzi wydają się w porządku. Powód jest taki, że chciałem przejrzeć dokumenty FHS i zrozumiałem, że / opt istnieje właśnie w tym celu. Podoba mi się pomysł, aby po prostu łączyły się z moimi skryptami w / usr / local / bin. Dzięki za wszystkie wskazówki.
hatterman

17

Jeśli żaden inny użytkownik oprócz Ciebie nie używa tych skryptów:

Następnie możesz je zatrzymać /home/$USER/bin. Utwórz binfolder, jeśli go nie ma, i przenieś tam pliki. Folder bin w twoim domu zostanie automatycznie dodany do zmiennej środowiskowej PATH. Kod znajduje się w .profile:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Zobacz Jak dodać / home / nazwa użytkownika / bin do $ PATH?

Lub w niektórych systemach może to być .bashrc:

export PATH=${HOME}/bin/:${HOME}/.local/bin:${PATH}

Dzięki, Starszy Geek

Jeśli te skrypty mają być używane przez innych użytkowników:

Zatem albo /usr/local/binalbo /opt/binsą dobre opcje. Zobacz Czy istnieje standardowe miejsce do umieszczania niestandardowych skryptów systemu Linux?

Mam nadzieję że to pomoże


3

Mam katalog, którego używam do szybkiego zbierania lokalnych narzędzi lub rzeczy, które wdrażam na różnych komputerach /usr/local/apollo. Istnieje odgałęzia ten katalog flags, bina logs.

W przypadku aplikacji, które pobieram i instaluję poza domyślnymi apt-getrepozytoriami, umieszcza się je w /opt/katalogu pod nazwą aplikacji, z jeszcze jednym podkatalogiem dla konkretnej wersji aplikacji. W ten sposób moja skompilowana wersja aplikacji jak vlclubeclipse nie będzie w konflikcie z wersją rozproszoną.

Moje użycie /opt polega na tym, że jest to właściwie oficjalnie zaprojektowane.

Nawiasem mówiąc katalogi /usr/local/bin, /usr/local/apollo, i /optprzeżywa świeża wersja OS instalacja nadpisywania.


1
$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/binPodoba mi się fakt, że /usr/local/binjuż na ścieżce jest jedna rzecz do zapamiętania. Podoba mi się twoja metoda, /opt/program/versionktórej mogę używać do rzeczy jądra, które otrzymuję i kompiluję jak EnhanceIO, gdzie zmieniają rzeczy między wersjami jądra. Czy /apollolądowanie na Księżycu jest ulubioną rzeczą, czy ma znaczenie Ubuntu?
WinEunuuchs2Unix

Jaka jest różnica między tym /usr/local/bina usr/local/sbintym, że ten ostatni zostaje ostrzelany podczas aktualizacji?
WinEunuuchs2Unix

Instalator nukuje używane katalogi. Dogodnie tworzy /usr/localkatalogi, ale nie umieszcza niczego w żadnym z nich. Te katalogi są wypełniane przez użytkownika. Wiele programów źródłowych poza repozytoriami daje użytkownikowi możliwość wyboru, dokąd ma iść instalacja. Domyślne pliki konfiguracyjne to /usr/local/bin. Ze względu na to, jak często używa się tych katalogów, domyślnie są one uwzględnione w ścieżce użytkownika. Domyślnie system sprawdza ~/bin i dodaje go do ścieżki, jeśli istnieje.
LD James

Masz na myśli sprawdzenie systemu ~/binpodczas instalacji lub przy każdym uruchomieniu? Jaka jest różnica między sbini bin? Wydaje się, że współistnieją, muszą istnieć quasi-reguły, które wybierasz na podstawie typu programu, prawda?
WinEunuuchs2Unix

1
@ WinEunuuchs2Unix Na ~/binścieżce ... nie jest dodawany podczas instalacji. System sprawdza go przy każdym logowaniu i dodaje go do zmiennej $ PATH, jeśli istnieje podczas logowania. Spójrz na dwa ostatnie wiersze ~/.profileustawień.
LD James
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.