キャリッジリターンとラインフィードは最終的にあなたを悩ませます

キャリッジとは何ですか? なぜ復帰するのですか?キャリッジリターンラインフィードどういう意味ですか!?!

タイプライターの紙はキャリッジに水平に乗ります。キャリッジリターンまたは CR は、タイプライターをテキスト行の先頭にリセットする印刷不可能な制御文字でした。

ただし、キャリッジリターンはキャリッジを後ろに移動しますが、用紙を 1 行進めません。キャリッジは X 軸上を移動します...

また、ラインフィードまたは LF は、プラテン (メインのゴムシリンダー) を 1 行だけ回転させる非印刷制御文字です。

したがって、キャリッジリターンとラインフィード。 2 つのアクション、そして何年にもわたって 2 つのコントロールキャラクター。

すべてのオペレーティングシステムは、EOL (行末) のエンコード方法が異なるようです。 70 年代後半のオペレーティングシステムはすべて、文字どおり CR LF を組み合わせて使用していました。これは、日常的にタイプライターやプリンターとやり取りしていたためです。

Windows が CRLF を使用するのは、DOS が CRLF を使用したためです。これは、CP/M が履歴のために CRLF を使用したためです。

Mac OS は、OS X が LF に切り替わるまで、何年もの間 CR を使用していました。

Unix は CRLF よりも単一の LF を使用し、最初からこれを使用しています。おそらく、Multics のようなシステムが 1965 年頃に LF のみを使用し始めたためです。1 バイトごとに 1 バイトを保存することは、ストレージと送信の両方にとって大きな問題でした。

2018 年に早送りすると、Windows もテキストファイルの EOL 文字として LF を使用するように切り替える時が来るかもしれません。

なんで？手始めに、Microsoft はついにメモ帳を更新して、LF を使用するテキストファイルを処理できるようにしました。

でも

そのような変更は可能でしょうか？そうではないかもしれませんが、それは世界を壊すでしょう。これが .NET Core の NewLine です。

public static String NewLine {
    get {
        Contract.Ensures(Contract.Result() != null);
#if !PLATFORM_UNIX
        return "\r\n";
#else
        return "\n";
#endif // !PLATFORM_UNIX
    }
}

とにかく、Windows と WSL (Linux on Windows) と Linux を一緒に定期的に使用している場合は、CRLF と LF を意識して認識する必要があります。

最近、興味深い状況に遭遇しました。まず、Git の機能を確認しましょう

.gitattributes を構成して、Git にファイルの処理方法を個別または拡張子ごとに指示できます。

いつ

git config --global core.autocrlf true

が設定されている場合、git は自動的にファイルを静かに変換し、OS 固有の方法でチェックアウトされるようにします。 Linux を使用してチェックアウトすると LF を取得し、Windows を使用している場合は CRLF を取得します。

Twitter の Viola が重要な説明を提供しています:

<ブロック引用>

「gitattributes はレポの行末動作を制御します。git config (特に --global を使用) はユーザーごとの設定です。」

システムと利用可能なオプションの 99% はうまく機能します。

Linux と Windows の間でファイルシステムを共有している場合を除きます。私は Windows 10 と Ubuntu (WSL 経由) を使用し、/mnt/c/github にデータを保存しています。

ただし、Windows 10 からプルすると CRLF を取得し、Linux からプルすると LF を取得できるため、Ubuntu でシェルスクリプトが機能する場合と機能しない場合があります。

シェルスクリプトと PowerShell スクリプトの両方を LF に設定する .gitattributes ファイルを作成することにしました。このようにして、これらのスクリプトをシステム間で使用、共有、実行できます。

*.sh eol=lf
*.ps1 eol=lf

たくさんの選択肢があります。ここでも 99% の確率で autocrlf が適切です。

GitHub ドキュメントから:

ファイルが一致していることに気付くでしょう--*.c 、 *.sln 、 *.png -- スペースで区切り、設定を指定 -- text 、 text eol=crlf 、 binary .以下で、いくつかの可能な設定について説明します。

text=auto
- Git は、最適と思われる方法でファイルを処理します。これは適切なデフォルトオプションです。
text eol=crlf
- Git は常に行末を CRLF に変換しますチェックアウト時。 CRLF を保持する必要があるファイルには、これを使用する必要があります。 OSXやLinuxでも。
text eol=lf
- Git は常に行末を LF に変換しますチェックアウト時。これは、Windows でも LF エンディングを保持する必要があるファイルに使用する必要があります。
binary
- Git は、指定されたファイルがテキストではないことを認識し、それらを変更しようとするべきではありません。 binary setting は -text -diff のエイリアスでもあります .

繰り返しますが、デフォルトはおそらく正しいでしょう。しかし、オペレーティングシステム間でファイルやファイルシステムを共有している場合は、注意が必要です。

libgit2 の共同メンテナである Edward Thomson は、このように述べており、Line Endings に関する彼のブログ投稿を紹介しています。

<ブロック引用>

これはもっと強く言います。 `core.autocrlf` はユーザーごとのスコープで構成されますが、リポジトリ全体の動作に影響を与えるため、`.gitattributes` は_常に_使用する必要があります.

問題がある場合は、おそらく改行です。 Edward の推奨事項は、すべてのプロジェクトで .gitattributes をチェックインすることです。

<ブロック引用>

行末を処理するための鍵は、 .gitattributes を使用して、構成がリポジトリにコミットされていることを確認することです .ほとんどの人にとって、これは .gitattributes という名前のファイルを作成するのと同じくらい簡単です。 1行を含むリポジトリのルートで：
* text=auto

これがお役に立てば幸いです!

* クリエイティブ・コモンズで使用されている Matunos のタイプライター

スポンサー: クロスプラットフォームの .NET IDE である JetBrains Rider を確認してください。 ASP.NET、.NET Framework、.NET Core、Xamarin、または Unity アプリケーションを編集、リファクタリング、テスト、およびデバッグします。詳細を確認し、30 日間の試用版をダウンロードしてください!

キャリッジリターンとラインフィードは最終的にあなたを悩ませます - Git Tips