LinuxにCRLF改行の問題がありますか？

ほとんどの場合、サーバーにファイルをアップロードするとき、Linuxカーネル自体は行末を知らないか気にしません。たとえムルノートCRLFはめちゃくちゃになりますシェルボーン。

しかし、Linuxにはテキストファイルのすべての行が単一のLFで終わる慣例があります。多くのツールがCRを読み、他のツールと同じように扱います。一般文字（a、b、c、...）。これはから来ていますテキストファイルのPOSIX定義。

これできるシェルスクリプト（sh、bash、zsh、ksh...）などの一部の言語で問題が発生します。運が良ければ、偽の追加パラメータによって構文エラーが発生し、スクリプトが失敗します。ただし、悪い場合は、ファイルの内容とファイル名が破損する可能性があります。

これは主にLinux / Unixでのみ実行されるように設計されたツールと言語の問題です。プラットフォームに依存しない多くの言語とツールが自動的に適応されます。したがって、問題が発生する可能性が低い。統合開発環境、またはコードエディタ。

---

したがって、同僚との議論を終了するために、LinuxではCRLFラインエンディングに問題はありません。 しかし、特定のツールや言語をそのままにすると、息が詰まったり変なことができます。

Linux/Unix プラットフォームで実行するコードを書く場合、通常は LF 行の末尾だけを残し、CR 文字を削除するように git を設定する方が簡単です。

通常、POSIX はテキストファイルを LF で終わるファイルとして定義します。したがって、ほとんどのPOSIXユーティリティは、CRLFを、通常の文字で処理されるCRで終わる一般的な行で終わる行として扱います。

これが許可されるかどうかは、お客様のニーズによって異なります。たとえば、wc単語の数を計算するときにCRを気にしないことがあり、特定のフィールドを使用または選択すると、予期しないcutCRawkが出力されることがあります。他の人が指摘したように、ほとんどのPOSIX互換シェル（Windowsでも）はCRが好きではなく、単に構文エラー処理を拒否します。

プラットフォームに関係なく、ほとんどのテキストエディタはCRLFとLFの終わりを処理でき、一部は以前のMacOS（MacOS 9以下など）のCR行の終わりも処理できます。したがって、どの行末を使用するかは、個人の好み、使用しているプラ​​ットフォーム、使用しているツールによって大きく異なります。

Gitを使用する場合の最善の方法は、Gitに特定のファイルがテキストファイルであることを知らせることです（つまり、行末を変換する必要があります）。これにより、GitはLFで終わるファイルを内部的に保存し、必要に応じてチェックアウト時に変換します。.gitattributesリポジトリのファイルに次の内容を追加するだけです。

*.c text
*.h text
*.sh text eol=lf
*.ps1 text eol=crlf
*.jpg -text

これは.cファイルが.hテキストであり、ユーザーが設定した設定に基づいて行末にチェックアウトでき、LFの終わりにリポジトリに書き込むことを指定します。.shリポジトリとワークツリーの両方がファイルに対してLFエンディングを持ち、リポジトリにファイルにLFエンディングを持ち、ワークツリーは.ps1プラットフォームに関係なく常にCRLFエンディングを持ちます。 .jpgファイルは行末変換をまったく受けません。

各ファイルタイプを指定したくない場合は、次のように簡単に作成できます。

* text=auto

Gitは自動的に正しいことをしようとします。

Linuxアプリケーションとアプリケーションライブラリ最大CRLF（MS-DOS、Windows）またはLF（Unix、Linux）を含むすべての種類の改行をシームレスに処理します。何も変更または指定する必要はありません。古い権威あるアップルシステム（いいえ最新のMacOS X）は、CRこれらのファイルを使用すると正しく処理されません（すべてが1行で表示されます）。

場合によっては問題が発生する可能性がありますが、CRケースごとに問題を解決できます。

$ wc -l /tmp/test-*
 2 /tmp/test-dos.txt
 0 /tmp/test-mac.txt
 2 /tmp/test-unix.txt
 4 total

CR削除ツールは次のとおりですdos2unix。

tr -d '\r' < input > output

またはsed

sed -i 's/\r$//g' file