Jakiego rozszerzenia użyć do plików tekstowych? (Unix / Linux)


20

Zauważyłem, że mogę dobrze czytać pliki tekstowe bez rozszerzenia .txt. Dlaczego? Czy powinienem zapisać te pliki z .txtrozszerzeniem czy bez ?

A co z .iniplikami? Zwykle używam ich w ten sposób: config.iniczy powinienem usunąć tutaj rozszerzenie?

Przydałyby się wszelkie ogólne zasoby na temat tego, jak Linux obsługuje rozszerzenia plików.

Odpowiedzi:


37

UNIX / Linux nie ma tego samego wczesnego dziedzictwa DOS / CP / M, co Windows. Dlatego rozszerzenia są na ogół mniej znaczące dla większości narzędzi i narzędzi UNIX.

Zwykle używam środowiska tylko z wiersza poleceń. Rozszerzenia w takim środowisku pod Linuksem nie są tak naprawdę znaczące, z wyjątkiem wygody dla operatora lub użytkownika. (Nie mam wystarczającego doświadczenia z KDE lub GNOME, aby wiedzieć, jak ich menedżerowie plików radzą sobie z rozszerzeniami).

Ale taka wygoda jest zwykle ważna. Jeśli config.ininaprawdę jest w standardowym formacie Microsoft .ini, pozwoliłbym, aby rozszerzenie pozostało. Zwykłe stare pliki tekstowe zwykle nie mają rozszerzenia w systemie Linux, ale nie jest to uniwersalne dla wszystkich plików konfiguracyjnych programów. Programista zazwyczaj decyduje o tym.

Myślę, że „.txt” jest użyteczny pod Linuksem, jeśli chcesz podkreślić, że NIE jest to plik konfiguracyjny lub inny dokument odczytywalny maszynowo. Jednak w dystrybucjach źródłowych konwencja polega na nazywaniu takich plików wszystkimi wielkimi literami bez rozszerzenia (tj. README, INSTALL, COPYING itp.)

Istnieją pewne standardy i konwencje, ale nic nie powstrzymuje cię od nazywania czegokolwiek, co chcesz, chyba że dzielisz się z innymi.

W systemie Windows nazewnictwo pliku .exewskazuje powłoce (zwykle explorer.exe), że jest to plik wykonywalny. UNIX wykorzystuje tę wiedzę w uprawnieniach systemu plików. Jeśli ustawione są odpowiednie xbity (patrz man chmod), jest on rozpoznawany jako wykonywalny przez powłoki i funkcje jądra (jak sądzę). Poza tym Linux nie dba o to, większość powłok nie dba o to, a większość programów szuka w pliku, by znaleźć „typ”.

Oczywiście istnieje ładne polecenie, filektóre może przeanalizować plik i powiedzieć z pewną pewnością, co to jest. Uważam, że jeśli nie może dopasować danych w pliku do żadnego znanego typu i jeśli zawiera tylko drukowalne znaki ASCII / Unicode, to zakłada, że ​​jest to plik tekstowy.


@Bruce Ediger poniżej jest absolutnie poprawny. Na poziomie jądra lub systemu plików nie ma nic, tj. Sam Linux, wymuszający lub dbający o to, aby zawartość pliku była zgodna z jego nazwą lub programem, który powinien to rozumieć. Nie oznacza to, że nie można utworzyć narzędzia powłoki lub programu uruchamiającego, aby wykonywać czynności na podstawie nazwy pliku.


7
Jest to również przydatne, jeśli dużo pracujesz w konsoli, ponieważ ładnie nazwane pliki łatwiej odróżnić od innych za pomocą globowania.
lynxlynxlynx,

9
Należy podkreślić, że nazwy plików systemu Linux nie mają „rozszerzeń” - część „.txt” zawierająca go nazwa pliku jest jedynie podciągiem. Należy również podkreślić, że wewnętrzna organizacja plików (ciągi zakończone LF, ciągi zakończone CR-LF, rekordy o ustalonym rozmiarze itp.) Nie są nawet słabo powiązane z nazwą, ani też „aplikacja”, która wie o pliku powiązanym z nazwą .
Bruce Ediger,

2
Myślę, że tylko wpisy katalogu FAT16 8.3 w systemie DOS miały osobne 3-bajtowe pole dla rozszerzenia. FAT32 zachował pole 8.3 dla kompatybilności, ale rzeczywista „długa nazwa pliku” jest ciągiem bez oddzielnego pola rozszerzenia, podzielonego na wiele pozycji katalogu ( fandecheng.com/personal/interests/ewindows/nuhelp/lfnspec.htm )
LawrenceC

23

W przeciwieństwie do systemu Windows, w systemach UNIX typ pliku nie jest określany przez rozszerzenie. Rozszerzenie pliku jest i było po prostu wizualnym wskaźnikiem dla ludzi. Możesz nazwać plik JPEG foo.c i otworzyć go w Gimp. Innym kontrastem w stosunku do systemu Windows jest to, że w systemach UNIX musisz użyć całej nazwy pliku, podczas gdy Windows często się tym zajmie (np. Działając tylko explorervs. explorer.exe). W systemie UNIX foo.shnależy wywoływać jako foo.shnie tylko foo.

Zgodnie z konwencją ludzie zwykle używają wspólnego zestawu rozszerzeń. Ta praktyka, choć niepotrzebna, jest prawdopodobnie korzystna dla całej ludzkości.


7
+1 zaThis practice…is probably beneficial for humanity at large
Ulrich Dangel

Szkoda, że ​​różnorodność opakowań utrudnia czasem właściwe posługiwanie się mimem (np. Z KDE w KDE), chociaż nie wiem, dlaczego programy nie cofają się w sprawdzaniu magicznego bajtu.
lynxlynxlynx,

3
Ponieważ nie ma bajtu „magicznego”. To tylko skrót dla „wszystkich znanych rodzajów plików, które są wystarczająco dobrze udokumentowane i wystarczająco uporządkowane, aby można je było niezawodnie wykryć z dużym stopniem pewności”. Działa bardzo dobrze w przypadku plików tekstowych lub kontenerowych. Zasadniczo zawodzi w przypadku jakichkolwiek nieprzetworzonych lub nieznanych typów danych.
bahamat

1
@bahamat To nie jest bajt, ale jest część pliku tradycyjnie zwana „ magiczną liczbą ”, która ma określać, co zawiera plik. Właśnie na to filepatrzy polecenie. ( #!to na przykład magiczna liczba skryptów sh)
Izkata,

1
@lzkata racja, tak jak powiedziałem: „znane typy plików, które są wystarczająco dobrze udokumentowane i mają wystarczającą strukturę, aby można je było niezawodnie wykryć z dużą pewnością”.
bahamat

7

Ogólnie bardzo pomocne okazało się zachowanie ścisłej, opisowej konwencji nazewnictwa. Nie potrzebujesz rozszerzenia w Uniksie, ale zatrzymam je z dwóch powodów:

1) Jeśli plik zostanie kiedykolwiek odczytany przez maszynę z systemem Windows, łatwiej będzie go otworzyć niż próbować znaleźć „otwórz za pomocą ...”.

2) Rozszerzenia pomagają użytkownikowi ustalić, co robi plik. W naszym laboratorium: .txt = plik tekstowy .sgi = skompilowany plik binarny irix .linux = skompilowany plik binarny linux

Jeśli musisz używać starszych maszyn uniksowych (nadal używamy IRIX), pamiętaj, że zwrot karetki jest inny w maszynach * nix, a programy mogą nie docenić, jeśli spróbujesz otworzyć plik ze zwrotami karetki w systemie Windows.



3

Istnieje kilka dobrych odpowiedzi. Chciałbym dalej odpowiedzieć na część pierwotnego pytania: „Przydałyby się wszelkie ogólne zasoby na temat tego, jak Linux obsługuje rozszerzenia plików”.

Możliwe jest rejestrowanie rozszerzeń, dzięki czemu Linux zawsze otwiera określone rozszerzenia w niektórych programach. Ta funkcja nazywa się binfmt .

binfmt_misc to zdolność jądra systemu Linux, która umożliwia rozpoznawanie dowolnych formatów plików wykonywalnych i przekazywanie ich do określonych aplikacji w przestrzeni użytkownika, takich jak emulatory i maszyny wirtualne. Formaty plików wykonywalnych są rejestrowane przez interfejs systemu plików specjalnego przeznaczenia (podobny do / proc). Dystrybucje oparte na Debianie zapewniają tę funkcjonalność poprzez dodatkowy pakiet wsparcia binfmt.

Każdy format ma odpowiednią pozycję pliku w katalogu / proc / sys / fs / binfmt_misc, którą można odczytać, aby uzyskać informacje o danym formacie pliku.


-2

.txt można otworzyć za pomocą różnych aplikacji. ale ważne jest to, że służy on do klasyfikowania pliku do określonego typu. Możesz sprawdzić, czy zapisujemy ten sam plik za pomocą .html, który próbuje otworzyć w programie Internet Explorer. aplikacje są tworzone odpowiednio do obsługi takich typów plików. Jeśli użyjesz .html powyżej, kompilator spróbuje znaleźć w nim atrybuty HTML i odpowiednio wyświetli wynik. to samo z innymi rozszerzeniami. Plik .ini można odczytać jako tekst, ale rozszerzenie klasyfikuje go jako plik konfiguracyjny, a zatem kompilator traktuje go jako plik konfiguracyjny, a nie zwykły plik tekstowy, ponieważ plik tekstowy jest tylko zbiorem rekordów i nie pełni określonej funkcji. ini.hence nie chcesz zmieniać rozszerzenia ini na tekst


6
Może tak być w przypadku systemu Windows, ale (jak wyjaśniono w innych odpowiedziach) nie ma to znaczenia w systemach operacyjnych UN * X-ish.
Piskvor,
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.