Dlaczego nie uruchomić pliku .txt zamiast pliku .sh do uruchamiania skryptów?


18

Zastanawiałem się, jaka jest potrzeba umieszczenia poleceń wykonywalnych w .shpliku, aby utworzyć pojedynczy skrypt, ponieważ mogę to zrobić, umieszczając polecenia w .txtpliku i umożliwiając jego wykonanie chmod.

Zakładam, że można to zrobić za pomocą dowolnego rozszerzenia pliku. Jestem więc dość zdezorientowany co do potrzeby .shprzedłużenia. Każda pomoc byłaby mile widziana.


19
Unix tradycyjnie nie dba o rozszerzenia plików. Więc masz rację - to nie ma znaczenia. Ma to na celu wyłącznie uświadomienie czytelnikowi, że jest to skrypt powłoki
vidarlo

8
rozszerzenia plików w systemie Linux nie są używane przez system operacyjny w żaden prawdziwy sposób. Dodanie rozszerzenia .sh mówi tylko użytkownikowi, że jest to skrypt powłoki, w przeciwieństwie do innych typów plików, takich jak skrypt python lub perl. Osobiście nie umieszczam rozszerzeń w moich skryptach.
doneal24

2
Trzeba tylko powiedzieć tobie lub komukolwiek innemu, kto na to patrzy, że jest to skrypt powłoki. Jeśli nie chcesz powiedzieć, które pliki .txt mają uruchamiać skrypty, a które mają być otwierane w edytorze, możesz nazwać wszystko .txt!
daboross

2
Right.txt, ale.txt if.txt wszystko. .txtTxt kończy się. .txt) zrozumienie.txt what.txt each.txt file.txt is.txt there.txt for.txt.
lewo około

1
Jest to podobne do pytania, które jest rzekomo duplikatem, ale to pytanie w rzeczywistości nie odpowiada na to pytanie.
Kenny Evitt

Odpowiedzi:


47

Jak prawidłowo się przekonałeś, rozszerzenie pliku nie musi pasować do niczego konkretnego.

W systemach uniksopodobnych typy plików są zwykle wyprowadzane z zawartości pliku (tj. „Magicznej liczby” lub innych charakterystycznych struktur w pierwszych kilku bajtach), a nie z ich nazwy. Możesz także całkowicie pominąć rozszerzenie, które często jest wykonywane dla plików wykonywalnych.

Sprawdź filepolecenie, pokazuje informacje, jakie może znaleźć na temat typu pliku na podstawie jego zawartości.

W przypadku skryptu wykonywalnego system oczekuje w pierwszym wierszu tak zwanego „shebang”, który wygląda np.

#!/usr/bin/env python3

i wskazuje, który program ma działać jako interpreter z plikiem skryptu jako argumentem. Jeśli wykonasz plik tekstowy bez takiego podziału, użyje on domyślnej powłoki, tj. Bash, aby spróbować go zinterpretować.

Tak więc w systemach Unix / Linux rozszerzenia nazw plików są w większości wskazówkami (ale nie są gwarancją) dla ludzkiego użytkownika, aby szybko rozpoznał, czego oczekiwać od określonego pliku. Jest to również konwencja, która może pomóc np. W szybszym wyszukiwaniu plików.

Zauważ jednak, że istnieją wyjątki, w których nazwa i rozszerzenie mają znaczenie (np. Niektóre systemowe pliki konfiguracyjne, które muszą być zgodne z konwencją nazewnictwa lub wiele przeglądarek i edytorów obrazów również wymaga rozszerzenia, aby wskazać typ pliku).

Możesz także spojrzeć na Czy rozszerzenia plików mają jakiś cel (dla systemu operacyjnego)?


3
Rozszerzenia plików nie mają znaczenia w powłoce, ale w świecie systemów GUI prawie ich potrzebujesz, aby podwójne kliknięcie działało poprawnie.
BallpointBen

@BallpointBen dwa punkty nie są ze sobą powiązane. Nawet pod graficznym interfejsem użytkownika „typ” pliku może być przechowywany obok jako metadane i może wyzwalać określone wykonanie, niezależnie od rozszerzenia. MacOS nie ma rozszerzeń nazw plików i jest graficznym interfejsem użytkownika i przetrwa go bardzo dobrze ...
Patrick Mevzek

1
@PatrickMevzek, w jaki sposób MacOS nie ma rozszerzeń? Włączyłem ich wyświetlanie, a wszystkie pliki je mają. Czy coś brakuje? Jestem nowy na platformie MacOS
Ciprian Tomoiagă

1
@ CiprianTomoiagă możesz nazwać swoje pliki w dowolny sposób, system operacyjny nie potrzebuje rozszerzenia, aby działał na nich poprawnie. Patrz na przykład: howtogeek.com/192628/...
Patrick Mevzek

1
@barbecue celuje w najniższy wspólny mianownik ... co może pójść nie tak :-) (jak ataki za pośrednictwem załączonych do wiadomości e-mail plików o nazwie coś.com.txt i robienie sztuczek, aby pominąć .txt jako .com jako szczególne znaczenie w Windows-land ). Rzeczywiście, dla interoperacyjności rozszerzenia plików mogą być dobrą praktyką. Trzeba jednak nauczyć się, że jest to wada w zasadzie wprowadzona przez DOS i że różne systemy operacyjne żyją doskonale zadowolone z plików bez rozszerzeń.
Patrick Mevzek,

3

W nazwie pliku UNIX / Linux nie ma czegoś takiego jak „rozszerzenie” lub „typ”.

Jak zauważyli inni, „typ” można znaleźć za pomocą polecenia file, zakładając, że odpowiednia magia jest dostępna w twoim systemie. Nazwy plików w systemie UNIX / Linux mogą zwykle zawierać dowolny dostępny znak, ale często pomocne jest użycie jakiejś formy konwencji dla tej nazwy, aby zarówno ludzie, jak i maszyny mogli oceniać zawartość (a tym samym wykorzystanie zawartości).

Jako przykład często używam przecinka jako pierwszego znaku nazwy pliku, aby wskazać plik tymczasowy, zamiast używać czegoś takiego jak ciąg „.tmp” na końcu nazwy pliku. Rezultat jest taki sam, plik zawierający dane, które są wymagane tylko przez krótki czas, ale nazwa nie musi zawierać „.” w nim ani ciąg „tmp”. Może to czasem mieć zalety, np. Podczas analizowania listy nazw plików. Ale to jest MOJA konwencja i ktoś może zdecydować się na inną, nawet używając „.tmp” jako swojej konwencji nazwy pliku tymczasowego.

Więc moja odpowiedź brzmi: nie ma czegoś takiego jak rozszerzenie pliku UNIX / Linux, a jedynie zestaw konwencji, które zwykle wyglądają jak rozszerzenia plików używane w innych systemach operacyjnych i ich systemach plików.


FWIW, ja również stosuję niestandardową konwencję. Moje skrypty, których nazwy zaczynają się od ".", powinny być kropkowane przez powłokę (nie mogą działać sensownie w podpowłoce). Odpowiednio wyłączam domyślną konwencję „początkowa kropka = ukryty plik” w moich aliasach / skryptach, które używają, lsaby widzieć wszystkie pliki, w tym te „ukryte”. Podobnie w systemie Windows wyłączam ustawienie „ukryj rozszerzenia plików”.
jrw32982 obsługuje Monikę
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.