Czy powinienem umieszczać rozszerzenia plików * .sh i * .rb na wszystkich moich skryptach?

W moim katalogu $ HOME / bin mam kilka ręcznie wykonywanych skryptów wykonywalnych. Niektóre są napisane bash, niektóre w Ruby. Wszystkie mają na górze linię shebang, która mówi powłoce, jakiego interpretera użyć (w moim przypadku bash lub Ruby).

Zastanawiam się, czy lepiej umieścić rozszerzenia plików na tych skryptach, aby wskazać, w jakim języku skryptowym są one napisane? Na przykład skrypty w języku Ruby miałyby przyrostek * .rb, a skrypty bash miałyby przyrostek * .sh.

Obecnie skrypty te mają proste nazwy bez rozszerzenia pliku.

Jaka jest najlepsza praktyka?

Możesz wykonywać polecenia wieloznaczne, takie jak ls *.rblub cp *.shjeśli chcesz organizować skrypty w przyszłości.

Moim zdaniem zacznij wcześnie lub później żałuj.

Edytorzy, tacy jak, vimbędą mogli zastosować poprawne podświetlanie składni na podstawie shebang lub rozszerzenia pliku.

Można to również osiągnąć, używając modelin w różnych edytorach. Np. Dla vima:

# vim: ft=sh

Cóż - jak większość rzeczy w życiu: zależy od twoich potrzeb.

Stwierdziłeś, że te skrypty znajdują się w katalogu bin i zakładam, że te skrypty mają być wywoływane z wiersza poleceń. Jako użytkownik uważam to za irytujące, jeśli muszę wpisać bla.ksh lub foo.bash. Również jeśli programista zdecyduje się przenieść na inny interpreter, nazwa polecenia również się zmieni i będę musiał zmienić inne skrypty korzystające z tych narzędzi - bardzo denerwujące, nawet jeśli użytkownik i programista są tą samą osobą.

Z drugiej strony w katalogach kompilacji projektu używam rozszerzeń takich jak .sh lub .tcl. W ten sposób mogę korzystać z funkcji make do wdrażania plików w ich katalogach docelowych - ale na tym etapie usuwam sufiks pliku.

Oczywiście istnieją pewne różnice między plikami wykonywalnymi w binkatalogach a edytowalnymi plikami „źródłowymi”.

• W przypadku plików źródłowych warto mieć przyrostek, aby zobaczyć, co jest, i pomóc niektórym mniej inteligentnym narzędziom, które nie skanują #!linii.
• Dla modułów, są one używane tylko przez powiązanego zestawu programów, z których wszyscy używają tego samego tłumacza (lub bez tłumacza), a typowe jest to .pm, .shczy .sow takich przypadkach.
• W przypadku programów wykonywalnych jego nazwa jest częścią „umowy programowej”, na mocy której użytkownicy i inne skrypty ją wywołują. Ważne jest, aby nazwa nie uległa zmianie, nawet jeśli implementacja się zmieni ; więc oczywiście nazwa pliku nie powinna mieć przyrostka

W przypadku skompilowanego programu różnica między „źródłowym” a „wykonywalnym” jest oczywista: jeden zawiera kod źródłowy, drugi zawiera język maszynowy lub interpretowany kod bajtowy. W przypadku skryptu nie ma oczywistej różnicy, ale makepolecenie utrzymuje hipotetyczną separację między „kodem źródłowym skryptu” a „wykonalną wersją skryptu”: jego domyślny „kompilator” dla „skryptu powłoki” jest po prostu cp.

Polecam prowadzenie osobnego $HOME/sourcekatalogu i:

• utrzymywanie dowiązania symbolicznego, takiego jak wykonane przez ln -s ../source/foo.sh $HOME/bin/foo; lub
• ręcznie je skopiować po wprowadzeniu zmian (i przetestowaniu), używając install -m 755 foo.sh ../bin/foo; lub
• za pomocą Makefilereguły, aby wykonać kontrolę składni przed skopiowaniem pliku źródłowego $HOME/sourcedo$HOME/bin

Przypis: powłoka moduł skrypt jest użyteczny tylko przez inny skrypt powłoki i modyfikuje wewnętrzny kontekst tego skryptu przy użyciu .lub sourcewbudowanych komend. Różni się to od skryptu wykonywalnego, który (jak każdy program) działa jako osobny proces i nie może modyfikować swojego procesu nadrzędnego. Z grubsza konwencja, moduły wchodzą, /usr/lib/name_of_program/name_of_module.sha polecenia wchodzą /usr/bin/name_of_command(bez żadnego przyrostka).

To nie jest konieczne. Jądro jest już informowane o poprawnym interpretatorze (przy pomocy #!wiersza), a wszystkie popularne edytory tekstu również go czytają, więc dodanie rozszerzenia nie zrobiłoby nic użytecznego, tylko zwiększyłoby pisanie. Jedynym przypadkiem, gdy program wykonywalny ma rozszerzenie, jest to, że jest ono w jakiś sposób ważne (dla programu, użytkownika lub obu).

Z drugiej strony moduły i biblioteki prawie zawsze mają rozszerzenia ( .rbdla modułów Ruby, .sodla bibliotek współdzielonych ELF i tak dalej).