Czy powinienem zapisać moje skrypty z rozszerzeniem .sh?

Mam kilka skryptów funkcjonalnych i chcę je skopiować /usr/bin, aby używać ich jako normalnych poleceń terminala. Czy dobrą praktyką jest używanie ich z .shrozszerzeniem, czy mogę je zapisać bez rozszerzenia?

scripts

— Patterson
źródło

Również jeśli chcesz, aby te skrypty były dostępne dla wszystkich użytkowników, /usr/local/binmoże być lepszym wyborem.

— Salem,

@Salem /usr/bini /usr/local/binoba powinny być dostępne dla wszystkich użytkowników, ale /usr/local/binlepiej dla plików wykonywalnych, które nie są częścią pakietów.

— gerrit

Jedyną korzyścią, jaką widziałem, jest to, że redaktorzy tacy jak vim lub nano od samego początku wiedzą, jak wyróżniać, i to wszystko.

— rath

@rath Dostaję podświetlanie składni bez rozszerzenia, jeśli mam shebang ustawiony na #!/usr/bin/env bashlub #!/bin/bash.

— Sparhawk

@Sparhawk Rzeczywiście, ale często o tym zapominam, dopóki nie spróbuję uruchomić skryptu;)

— rath

Odpowiedzi:

Nie, nie jest to dobra praktyka, powinieneś trzymać swoje skrypty bez rozszerzenia. Zauważ, że skrypty będące częścią pakietów nie mają rozszerzenia .sh , tj. Update-grub , a nie update-grub.sh . Jeśli nadal nie jesteś przekonany, pamiętaj, że Przewodnik po stylu Google Shell mówi:

Pliki wykonywalne nie powinny mieć rozszerzenia (zdecydowanie zalecane) ani rozszerzenia .sh. Biblioteki muszą mieć rozszerzenie .sh i nie powinny być wykonywalne.

PS Nie musisz wkładać skryptu /bin. Możesz utworzyć katalog ~/bini umieścić tam swój skrypt. Katalog ~/binjest $PATHdomyślnie dołączony , więc umieszczone tam skrypty można uruchamiać jak każde inne polecenie powłoki.

— Społeczność
źródło

„Katalog ~ / bin jest $PATHdomyślnie dołączony ” - Od kiedy? W każdym razie ~/.local/binjest to prawdopodobnie lepszy wybór, ponieważ jest standardem.

— nyuszika7h

Masz na myśli „Biblioteki muszą mieć rozszerzenie .so”, prawda? Nie sh.

— Keith Wolters

@KeithWolters najpierw, nie ja, ale Google. Po drugie, .sh, nie .so, mówimy o skryptach powłoki, a nie plikach binarnych.

Przewodnik po stylu Google jest bardzo specyficzny dla Google. Na przykład „Bash jest jedynym językiem skryptowym powłoki dozwolonym dla plików wykonywalnych”. Wyraźnie jest to reguła wewnętrzna, a nie najlepsze praktyki.

— Paul Draper,

@ nyuszika7h sprawdź ~ / .profile ... wstawia $ HOME / bin do twojej ścieżki, jeśli katalog istnieje

— Corey Goldberg

Popieram zalecenie użycia, ~/binktóre automatycznie dodaje się do twojego $PATH, jak powiedział Sergey . Lub /usr/local/bin, co może już być w PATH. Jednak:

Robisz to dla siebie. Używaj czegokolwiek, z czym czujesz się komfortowo. Rzeczywiście, powiedziałbym, aby zachować rozszerzenie, aby przypomnieć sobie, że to twój skrypt, który uruchamiasz, ponieważ -
Rozszerzenia są rzadkie w /usr/bin. W moim systemie mogę znaleźć tylko dwa:
```
$ dpkg -S `ls /usr/bin/*.sh`
mtools: /usr/bin/amuFormat.sh
gettext-base: /usr/bin/gettext.sh
```
Więc jeśli pakujesz, zdecydowanie pomiń rozszerzenie.

— muru
źródło

~/binjest dodawany $PATHautomatycznie, jeśli istnieje, nie trzeba dodawać go ręcznie. Wystarczy utworzyć katalog, wylogować się i zalogować ponownie.

— Sergey

Wystarczy umieścić następujący wiersz na początku pliku:

#!/bin/bash

Tak więc plik zostanie automatycznie napisany: Skrypt powłoki bez żadnego rozszerzenia!

Pamiętaj, aby zezwolić na wykonanie pliku.

Aby umieścić skrypt tak, aby można go było uruchomić za pomocą polecenia bezpośredniego, odwiedź: Gdzie powinienem umieścić skrypt, aby można go było uruchomić za pomocą polecenia bezpośredniego?

— Pandya
źródło

Lub nawet #! / Bin / sh, jeśli nie potrzebujesz pełnej powłoki bash.

— flickerfly

Wiele systemów operacyjnych link / bin / sh i / bin / bash

— Max Coplan