テキストファイルに使用する拡張子は?(Unix / Linux)


20

拡張子のないテキストファイルを.txt正常に読み取ることができることに気付きました。どうして?これらのファイルを.txt拡張子付きまたは拡張子なしで保存する必要がありますか?

また、.iniファイルについてはどうですか?私は通常、次のように使用します:config.iniここで拡張機能を削除する必要がありますか?

Linuxがファイル拡張子を処理する方法に関する一般的なリソースがあれば役に立つでしょう。

回答:


37

UNIX / Linuxには、Windowsと同じ初期のDOS / CP / Mの遺産がありません。したがって、ほとんどのUNIXユーティリティおよびツールにとって、拡張機能は一般的にそれほど重要ではありません。

私は通常、コマンドラインのみの環境を使用します。Linuxでのそのような環境での拡張は、オペレーターまたはユーザーの利便性を除いて、実際には重要ではありません。(KDEまたはGNOMEのファイルマネージャーが拡張子をどのように扱うかを知るのに十分な経験がありません。)

しかし、そのような利便性は通常重要です。場合はconfig.ini、マイクロソフト標準「の.ini」の形式で本当に、私は延長スタンドを聞かせたいです。通常、プレーンテキストファイルはLinuxで拡張子を持ちませんが、これはすべてのプログラム構成ファイルに共通するわけではありません。通常、プログラマーはそれを決定します。

「.txt」は、構成ファイルやその他の機械可読文書ではないことを強調したい場合、Linuxでは便利だと思います。ただし、ソース配布では、このようなファイルに拡張子を付けずにすべて大文字にする(つまり、README、INSTALL、COPYINGなど)という規則があります。

いくつかの標準と規則がありますが、他の人と物を共有している場合を除き、好きな名前を付けることを妨げるものはありません。

Windowsでは、ファイルに名前を付ける.exeと、シェルに(通常はexplorer.exe)実行可能ファイルであることを示します。UNIXは、この知識をファイルシステムの権限に組み込みます。適切なxビット(を参照man chmod)が設定されている場合、シェルおよびカーネル関数によって実行可能と認識されます(信じています)。これを超えて、Linuxは気にせず、ほとんどのシェルは気にせず、ほとんどのプログラムはファイルを調べて「タイプ」を見つけます。

もちろん、fileファイルを分析し、ある程度の確実性でファイルの内容を伝えることができる素晴らしいコマンドがあります。ファイル内のデータを既知のタイプと一致させることができず、印刷可能なASCII / Unicode文字のみが含まれている場合、テキストファイルであると想定します。


以下の@Bruce Edigerは絶対に正しいです。カーネルまたはファイルシステムレベルには何もありません。つまり、Linux自体は、ファイルの内容をその名前またはそれを理解するはずのプログラムと一致させる必要があることを強制または気にしません。これは、ファイル名に基づいて処理を行うシェルまたはランチャーユーティリティを作成できないことを意味するものではありません。


7
また、コンソールで多くの作業をしている場合にも便利です。これは、適切に名前が付けられたファイルが、グロビングを使用して他のファイルと簡単に区別できるためです。
lynxlynxlynx

9
Linuxファイル名には「拡張子」がないことを強調する必要があります。これを含むファイル名の「.txt」部分は単なるサブストリングです。また、内部ファイル編成(LF終了文字列、CR-LF終了文字列、固定サイズレコードなど)は、名前とわずかに関連するものではなく、名前で関連するファイルを認識する「アプリ」でもないことを強調する必要があります。
ブルースエディガー

2
私は、DOSの下のFAT16 8.3ディレクトリエントリだけが、拡張用に別個の3バイトフィールドを持っていると思います。FAT32は互換性のために8.3フィールドを保持しましたが、実際の「長いファイル名」は、複数のディレクトリエントリ(fandecheng.com/personal/interests/ewindows/nuhelp/lfnspec.htm)に対して分割された個別の拡張子フィールドのない文字列です
LawrenceC

23

Windowsとは異なり、UNIXシステムでは、ファイルタイプは拡張子によって決定されません。ファイル拡張子は、単に人間の視覚的なインジケータです。JPEG foo.cに名前を付けてGimpで開くことができます。Windowsとのもう1つの違いは、UNIXシステムではファイル名全体を使用する必要がありますが、Windowsが自動的に処理する場合が多いことです(たとえば、単にexplorervs.を実行しますexplorer.exe)。UNIX では、単にではなくfoo.shとして呼び出す必要があります。foo.shfoo

慣例により、人々は拡張機能の共通セットを使用する傾向があります。このプラクティスは、不要ですが、おそらく人類全体にとって有益です。


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

パッケージが多様であるため、適切なMIME処理が困難になる場合があります(たとえば、私の経験からKDEで)。プログラムがマジックバイトのチェックに失敗しない理由はわかりません。
lynxlynxlynx

3
「マジック」バイトがないためです。これは、「高度な確実性で確実に検出できるほど十分に文書化され構造化されている既知のすべてのファイルタイプ」の略です。テキストまたはコンテナファイルに対して非常にうまく機能します。通常、生または未知のデータ型に対しては惨めに失敗します。
バハマ

1
@bahamatこれはバイトではありませんが、ファイルの内容を定義するために「マジックナンバー」と呼ばれているファイルの一部があります。それは何fileのコマンドを見ています。(#!たとえば、shスクリプトのマジックナンバーです)
Izkata

1
私が言ったように、@ lzkataは正しい:「かなり確実に確実に検出されるのに十分に十分に文書化され構造化されている既知のファイルタイプ」。
バハマ

7

一般に、厳密で説明的な命名規則を守ることは非常に役立つことがわかりました。Unixでは拡張機能は必要ありませんが、次の2つの理由でそれを保持します。

1)そのファイルがWindowsマシンで読み取られる場合、「...で開く」を見つけようとするよりも開く方が簡単です。

2)拡張機能は、ユーザーがファイルの動作を把握するのに役立ちます。ラボでは:.txt =テキストファイル.sgi = irixコンパイルバイナリ.linux = linuxコンパイルバイナリ

古いUnixマシン(私たちはまだIRIXを使用しています)を使用する必要がある場合、* nixマシンではキャリッジリターンが異なるため、Windowsキャリッジリターンでファイルを開こうとしてもプログラムが正しく動作しない可能性があることに注意してください。



3

いくつかの良い答えがあります。さらに、元の質問の一部に答えたいと思います。「Linuxがファイル拡張子をどのように処理するかに関する一般的なリソースがあれば役立つでしょう。」

Linuxが常に特定のプログラムで特定の拡張機能を開くように、拡張機能を登録することができます。この機能はbinfmtと呼ばれます

binfmt_miscは、Linuxカーネルの機能で、任意の実行可能ファイル形式を認識して、エミュレーターや仮想マシンなどの特定のユーザー空間アプリケーションに渡すことができます。実行可能形式は、特別な目的のファイルシステムインターフェイス(/ procと同様)を介して登録されます。Debianベースのディストリビューションは、追加のbinfmt-supportパッケージを通じて機能を提供します。

各形式には、/ proc / sys / fs / binfmt_miscディレクトリに対応するファイルエントリがあり、特定のファイル形式に関する情報を取得するために読み取ることができます。


-2

.txtはさまざまなアプリケーションで開くことができます。しかし重要なことは、特定のタイプのファイルを分類するために使用されることです。.htmlを使用して同じファイルを保存すると、ファイルはInternet Explorerで開こうとします。そのようなファイルタイプをサポートするために、アプリケーションが適宜作成されます。上記で.htmlを使用すると、コンパイラはその中のhtml属性を見つけようとし、それに応じて結果を表示します。他の拡張機能と同じです。.iniファイルはテキストとして読み取ることができますが、拡張子は構成ファイルとして分類します。したがって、テキストファイルはレコードのセットであり、特定の機能を持たないため、コンパイラは通常のテキストファイルではなく構成ファイルとして扱います。 ini.henceは、iniの拡張子をテキストに変更したくないでしょう。


6
それはWindowsの場合かもしれませんが、(他の回答で説明されているように)これはUN * X-ishオペレーティングシステムでは無関係です。
-Piskvor
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.