Skrypty użytkownika w katalogu domowym - $HOME/bin

Gdy piszemy własne skrypty lub też używamy skryptów pobranych z sieci, aby zachować porządek warto je trzymać w dedykowanym do tego celu katalogu - zwyczajowo w $HOME/bin (gdzie $HOME oznacza katalog domowy użytkownika np /home/janek )

Aby mieć do nich wygodny dostęp dodajemy katalog $HOME/bin do zmiennej $PATH (ścieżka wyszukiwania).

Możemy to zrobić dodając do pliku .profile (plik ukryty, znajdujący się w katalogu domowym) linię:

export PATH=$PATH:$HOME/bin

Można to wykonać poniższym poleceniem.

echo "export PATH=$PATH:$HOME/bin" >> $HOME/.profile

Po ponownym zalogowaniu sprawdzamy wartość zmiennej $PATH (ścieżka wyszukiwania)

echo $PATH

Zmienna powinna już zawierać ścieżkę do katalogu bin w naszym katalogu domowym.

Od teraz możemy uruchamiać nasze skrypty tak jak każde inne polecenia - bez podawania ścieżki.

1 polubienie

Różne szkoły obowiązują w tym zakresie. Ja również mam
~/bin/
a w nim kilka katalogów, przede wszystkim ten ze skryptami. Ale nie dodałem żadnego do ścieżki. Jeżeli chcę, aby jakiś skrypt był wykonywany na podstawie $PATH, to tworzę link’a w
/usr/bin/
Uznałem, na podstawie doświadczeń - również wcześniejszych, w Windows; oraz własnego stylu pracy, że takie rozwiązanie będzie najlepsze. Chętnie jednak usłyszę jakieś krytyczne komentarze, pod jego adresem.

To Linux, zazwyczaj nie ma jednej drogi i każdy robi jak mu wygodnie :slight_smile: Ten sposób, który opisałem jest jak mi się wydaję standardowy czy może bardziej zwyczajowy - podpatrzyłem go gdzieś - pewnie kilkanaście lat temu - i stosuję - dla mnie jest prosty i skuteczny.

Sposób jaki opisałeś @napcok jest tym, z którym spotykałem się najczęściej. Mój, z kolei, jest efektem doświadczeń windows’owych, specyfiki linux’owej i dopasowania do mojego stylu pracy. Nie uważam go za najlepszy, czy jedynie słuszny, bo jak piszesz: ‘To Linux’ - wiele dróg do celu. Wszedłem w Linux’a ze sporym bagażem doświadczeń, dlatego niektóre moje zachowania nie, są mainstream’owe i ciągle staram się być otwarty na ich doskonalenie.

Napisałbyś coś “bardziej szczegółowo” dla tych mniej zaawansowanych.

Załóżmy, że Twój użytkownik nazywa się user:

/home/user/

Utworzyłeś w domowym katalogu podkatalog ~/bin, a w nim ~/bin/skrypty:

/home/user/bin/skrypty/

W nim, z kolei, masz skrypt moj_wy-pieszczony_skrypt.sh:

/home/user/bin/skrypty/moj_wy-pieszczony_skrypt.sh

Przy pomocy odpowiedniej komendy:

$ sudo cp -s "/home/user/bin/skrypty/moj_wy-pieszczony_skrypt.sh" "/usr/bin/moj_wy-pieszczony_skrypt"

tworzysz link symboliczny skryptu w /usr/bin/.

Zalety:

  • nie musisz dodawać kolejnej pozycji do ścieżki wyszukiwania;
  • musisz użyć sudo, aby skrypt ‘był widoczny’ w systemie, co dokłada cegiełkę do muru zabezpieczeń.

Wady:

  • może zdarzyć się, że pojawi się kiedyś jakiś plik, który zechce zamieszkać w /usr/bin/ i nazywać się będzie tak, jak link, który utworzyłeś. Wtedy jednak pojawi się komunikat w trakcie instalacji/aktualizacji i będzie można problem rozwiązać w paru ruchach. Jednak przez kilka lat stosowania tego rozwiązania nie zdarzyło się coś takiego, dlatego jego prawdopodobieństwo uznaję za niewielkie - dużo zależy od metody nadawania plikom nazw i … zwykłego zbiegu okoliczności.

rozsądniej do /usr/local/bin coby nie mieszać z systemowymi…

Jak najbardziej można, pamiętając przy tym, że katalog /usr/local/ (i wiele innych katalogów lub link’ów symbolicznych) istnieje w Manjaro tylko pro forma, dla zgodności ze standardem - praktycznie nie jest używany (podobnie jak w wielu innych dystrybucjach). Ale nie widzę przeszkód, aby go wykorzystać do własnych celów.


EDIT-20190701-2241 … zastanawiałem się nad sensem wyboru konkretnej lokalizacji i doszedłem do wniosku, że:

  • /usr/local/bin ma sens wtedy, gdy w systemie jest wielu użytkowników i chcemy wszystkim udostępnić ‘dodatkowe’ oprogramowanie. Możemy nawet podmontować pod ten katalog osobną partycję;
  • ~/bin z kolei, to rozwiązanie czysto personalno-dektop’owe, w którym jest jeden user (poza root’em) i łatwiej zarządzać takim pozasystemowym soft’em w tej lokalizacji. Ma ona również swoje zalety związane z kopią bezpieczeństwa czy migracją użytkownika na inną instalację.

a jakiej komendy użyć, by usunąć określony link symboliczny?
Mogę oczywiście wejść z poziomu roota do tego katalogu i go usunąć. Ale chodzi mi o polecenie konsolowe.
wpisując polecenie
$ sudo cp -s "/home/nazwa_usera/.bin/skrypty/ram-drop_caches.sh" "/usr/local/bin/ram-drop_caches"
mam utworzony link symboliczny w katalogu
Link symboliczny
tutaj o nazwie @ram-drop_caches

Midnight Commander (mc) - pokazany na zrzucie ekranu to doskonały menadżer plików i można nim również usuwać pliki (F8).
A polecenie konsolowe do usuwania plików to rm.

Wiem, że mc jest świetny ale np. wpisując w konsoli:
sudo cp -s "/home/christophe/.bin/Skrypty/conky_start.sh" "/usr/local/bin/conky_start.sh"
mamy dodany link symboliczny
Link_symboliczny
a polecenie likwidacji tego linku symbolicznego to zamiast cp wpisujemy rm
sudo rm "/home/christophe/.bin/Skrypty/conky_start.sh" "/usr/local/bin/conky_start.sh"
i link symboliczny wykasowany.

Link symboliczny jest po prostu plikiem, można go usunąć jak każdy plik, czy to przez rm czy z mc - bez różnicy.

Pewny jesteś, że wykasowałeś tym dziwacznym poleceniem tylko link symboliczny?
Bo wydaje mi się, że nie tylko.

Tak z miejsca /home/christophe/.bin/Skrypty i z katalogu /usr/local/bin
… a co do pytania “tylko”??? -niczego dziwnego nie zauważyłem.

OK, chodzi mi o to, że to polecenie usuwa oba pliki: skrypt + link symboliczny.

Oczywiście, wiem o tym. Te skrypty i tak trzymam w innym katalogu z ARCHIWUM.Archiwum

Polecenie jakie podałeś, nie kasuje link’u, tylko link i plik link’owany - Twoja świadomość nie ma, tu nic do rzeczy, bo chodzi o precyzję wypowiedzi. Ktoś niedoświadczony lub skacowany zastosuje ten schemat i będzie problem.

Jak już @napcok zauważył, link symboliczny (symlink, soft link) jest również plikiem (jak ‘wszystko’ w Linux’ie) i usuwamy go taką samą komendą, jak ‘normalne’ pliki, czyli rm (remove, usuń). Ma to również zastosowanie do hard link’ów.

Co do 'cp -s', to kiedyś preferowałem tą komendę do tworzenia soft link’u (nie pamiętam już dlaczego). Ale gdzieś-kiedyś miałem jakieś z nią problemy i zacząłem używać 'ln -s'

$ ln --help
[...]
  -s, --symbolic              tworzenie dowiązań symbolicznych zamiast zwykłych
[...]
1 polubienie