>>75
改行コードで困るのはコマンドをつなぐときだけですね。

ファイルに関してはWindowsの文字コードはほとんど関係なく、
アプリの仕様によりますので、例えばメモ帳は改行コードはCR+LFとLFの両方に対応しました。
殆どのエディタは両対応です。だからファイルに関しての文字コードは問題になりません。

改行コードを意識する必要があるのは、コマンドをつなぐときですが、
もちろんWindows側とWSL側それぞれで閉じている場合は何も関係ありません。
そもそもWSLはLinux環境とも言えるのでWindowsと連携せずとも
WSL内でやりたいことは完結できるわけです。

そのためさらに改行コードを意識する場合は限られており、
ようするにシェルスクリプトからWindows側のコマンドを呼び出してその出力を
読み書きするような場合にしか改行コードは問題になりません。

ですが幸か不幸かWindowsのコマンドは、元から出力を読み取って操作するような設計ではないのですよ。
例えば、Windowsのdateコマンドはdate /Tで日付のみを返すので、この出力を使用するのは簡単です。
（がもちろんWSL内に相当のコマンドがあるので必要ありません）
ですが、こういうコマンドはごく一部で、例えばレジストリの特定のキーを取得する場合、以下のようなメッセージになるため
データとして使いづらいわけです。そしてデータとして使う場合もforを使った冗長な書き方が必要になります。

C:\> reg query hkey_local_machine\software\microsoft\msbuild\4.0 /v defaulttoolsversion
HKEY_LOCAL_MACHINE\software\microsoft\msbuild\4.0
defaulttoolsversion REG_SZ 2.0

つまりWindowsのコマンドというのはファイルを出力するもので、出力を利用するものではないんですね。
「スクリプト」ではなく「バッチファイル」という名前である理由です。

ファイルに関しては改行コードが問題にならない上に出力を再利用することはすくないので改行コードの違いが問題になることはないのですね。
そもそもWSL内でたいてい事はやれるのでWSL側からWindows側のコマンドを呼び出すことは殆ど無いです。
ファイルレベルで情報をやり取りできるからそれで十分便利なわけです。