昨年から始まった新人教育ネタです。
昨年入ってきた新メンバーの作業で発生したお話。
(詳しく書くと業務内容に関係してしまう情報が入ってしまうので、内容も少し一般的な内容にしています）
ある定義ファイルを読み込んで、読み込んだ内容の解析をする処理を作っていました。
製品の対応プラットフォームとしては、WindowsとLinux。
その２つで同じ処理のプログラムを作成するという課題。
---------------
[例]
Option1=A
Option2=B
---------------
といったように、「<プロパティ名>=<値>」という形式のファイルの解析。
処理を作り、Windowsでデバッグやテストをして無事に動くことを確認して、さあ、次はLinuxだ！となりました。
半日くらい経って、もう終わったかな？と思って進捗を聞いてみると・・・
「ファイルの読み込みはできているんですが、なぜか値のチェックが正しく動作しないです」
・・・という申告。
実装を見る限り、別に処理は間違っておらず、そもそもWindowsでうまくいっていることから、やはり気になったのは、定義ファイル側。
見てみると、やはり改行コードが正しくありませんでした。
聞いてみると、Linux上でファイルを作ったわけではなく、Windowsで作ったファイルをLinuxマシンに転送したとのこと。
転送モードを聞いてみると、「？」という感じで「普通に転送しました」という回答。
なるほどねと思ってみてみると、やはりバイナリモードで転送しており、改行コードが間違っていました。
改行コードはプラットフォームごとに差異があり、
が基本。
異なるプラットフォーム間をバイナリモードで転送すると、当然改行コードもそのまま転送されてしまうため、Linuxに転送したファイルの改行コードが「CR+LF」となってしまっていました。
CR (Carrige Return) ：キャリッジリターン
LF (Line Feed) ：ラインフィード
そのため、「=」から後ろを取得した際に、例えば、「Option1=A」の行の場合、「A」が期待値ですが、「A<CR>」となってしまい、後続の処理で「Aか？」という判定が想定通りに動いていませんでした。
（判定文での値の比較が「A = A<CR>」となってしまうため）
単純で当たり前な話ですが、当然、WindowsとLinuxの違いは何か？という点を知らないと、案外ハマりがちなのかなと。
前に新人の面倒を見たときも、同じようなことで引っかかりましたからね。
