182。

深夜メンテだったので、昼間は平日の町をブラブラしに

銀座のH&Mに行ってみた。

なるほど。確かにドイツにあるあのH&Mと同じ。

だがしかーし、ドイツの支店もそうだけど、

支店によって服の傾向があるので、

銀座店の品揃えはイマイチに感じてしまったのでした。

かくして、何も購入せずに家に戻って体力温存モードで過ごしつつ、

出社間際になって、メンテが決行されるのか確認する為に

会社のメールを受信して、現場の状況を確かめると

メンテとは関係ないけど、ちょっと興味深い事が報告されていた。

それはどんなのか？っちゅーと、

CPANモジュールの Config::General で読み込む設定ファイル中に

特定の文字コードが入ってると、文字列が分断されて設定値として認識される症状。

ちなみに、設定ファイルはEUCで書かれてるんだけど

ゞ６ざザΧФ╋斡俺感...などといった B6 が含まれてると分断されるらしい。

へぇぇ...と思いつつ、

深夜メンテ出勤直前に、家で Config::General のソースを読んでみると

大胆なルーチンを発見。

・Config::General

sub _parse {
（略）
  my $indichar = chr 182;  # ｶ, inserted by _open, our here-doc indicator
（略）
      ($option,$value) = split /\s*$indichar\s*/, $_, 2;   # separated by heredoc-finding in _open()

なんか設定ファイル中でヒアドキュメント使えるらしいんだけど

_read でヒアドキュメントの現れた箇所だかに、

chr 182（つまりB6）を埋め込み、

それを目印に _parse で文字列を split しちゃうらしい。

困った事に、_read でヒアドキュメントが認識されたか？とかゆーフラグ類は一切ないらしいので

ヒアドキュメントを設定してないファイルを読み込ませても

_parse では有無を言わさず chr 182 を見つけると

大喜びで（？）、スパンスパン分割してる模様。

結果、日本語の文字も、途中で分断されちゃうので

早い話、この chr 182 を別の目印になるような文字列にしてしまえばいいと思うのだけど、

それにしたって、chr 182 は定数化されてないし、

なんでまた chr 182 なんだ？とか思うと、

ちょっと納得いかないルーチンだったりします。。。