改行コードでハマる

ついこの前も改行コードでハマってたんですが、今日も思いっきりハマりました。

GW直前からメモ帳で開きっぱなしのソースがあるため、各デバイスにソースを入れ込むのにターミナルからホームディレクトリにファイル転送させて必要な手順でスクリプトを配置していて結構問題になる改行コード。

最近だと見た目にあまり影響がなくなっている(windowsの文字コードがansiからほとんどUNICODEベースに変わりメモ帳でもUTFが扱えるようになった)ので気づきにくいのですが、改行コードだけはいまだに CR+LF。

MacもUnixベースになったとはいえ、もうこの辺は宗教的な何かとなっているのでお互いに歩み寄ろうという気配は全くありません。

愚痴ネタなので止まらなくなりそうですが、ここでやめて本題へ…ｗ

今回ハマったのは主にbashスクリプトでこの辺のトラブルを避けるために基本的に、私は必ずどこかのサーバーに投げてそこからwgetで受けて、インストールスクリプトで配置する方法をとることでポカミスを減らしています。が、今回はこれを行わずにテスト的にやっているので思いっきりハマってしまいました。

そもそもbashだとどこで改行コード問題が発生するかと言えば、結構たくさんあります。

一番目立つのは各コマンドを実行するステートメントがあったとして、いくつかのパラメータがあった場合に問題が発生します。

改行コードが\nではなく\r\nとなっていた場合、見た目テキにどちらも変わらないわけですが、

command param\r

となっていた場合、param自体の意味合いが重要な場合、顕著に発生します。

commandプログラムがparamを参照したときに、param\rとして見えてしまうため、単純に比較している場合、paramとして認識できなくなるわけです。

パラメータが無ければ影響は減ると思いますが、bashスクリプトでパラメータのない行なんておそらくないんじゃないかとｗ

pythonではかなりこの辺の処理が避けられるようになっていたりしてつい忘れがちですが、argparseでもしっかりと\r付きでパラメータを拾ってくる形になっていました。

linux上のpythonのソーススクリプトでCR+LFであってもほぼ動いたりするのですが、稀にドはまりすることがあるので、改行コードはしっかり扱っておいた方が無難です。マルチプラットフォームで一元管理したい場合は、面倒でも配布と設置は別プロセスとして分けて必要なコード変換は各環境で行うことをお勧めいたします。