なひです。

OpenVMSでのCSVモジュールの利用について、直接メイルをもらいました。
RubyのVMSへのport状況についてよく知らないので、どなたか
相談にのってください。

もらったメイルによると、VMSのvariable-lengthフォーマットの
ファイルをCSV.parseで解析しようとすると、"foo,bar\n"という
stream-lf(もしくはstream-cr)的なフォーマットを期待している
CSV.parseが誤動作する、というもので、

  RubyのVMS portでは、IO#getsしてくれればちゃんと1行、
  stream-lfっぽく返すので問題がない。IO#getsにならん?

ということのようです。

variable-lengthフォーマットだとそれで問題ないのですが、そうでない
platformでは、IO#getsすると、cell中にlfが入っていたときに
だまされてしまうため、使いたくありません。

その後のメイルのやりとりで、このユーザさんは、

  それならVMS用に、IO#getsを使うモードを用意してほしい、
  できれば自動判別してほしいけど、駄目ならCSV.parseを
  使うアプリ側からモードを指定してもよい

と言っています。

というわけで、以下にまとめます。

* VMS環境で、ファイルフォーマットを知る方法はあるか。

* もしかして、「VMS環境だろうと、Rubyでは、portabilityのため、
  IO#readもIO#gets同様、stream-lfっぽく読めるべきだ(自前で
  変換すべきだ)」と主張する人は居ますか?
  portabilityを最大限に重視すると、IO#readは使わないほうがよい?

* あるいは別に、好ましい解決方法を知っている人がいたら教えてください。

以下は元メイルの引用です。許可は取ってあります。

    /    /    /

Subject: csv.rb portability issue


Greetings,

Thanks for writing csv.rb.  It looks like what we need for a project we
are working on.  However, we are having trouble using your code on the
OpenVMS platform because of a portability issue.

It appears you have assumed input/output files are always represented on
disk as standard line terminator delimited files (i.e. <lf> or <cr><lf>
files).  Although this assumption does hold on most platforms, it is not
universal.

Since csv.rb processes files in a non-line oriented fashion (i.e.
blocked and decoded), the code doesn't work properly on the
native text file structure used in OpenVMS, which has a character count
in front of each line, and has no line delimiters:

<count1><line1><count2><line2>...

The OpenVMS implementation of ruby does support reading and writing
files in this format if you use standard library calls.  The file will
be seen by the caller as a conventional file of lines with line
terminators.  But when the raw data is read from the disk a block at a
time, it is impossible for OpenVMS ruby to do the necessary translation
so your library will see line terminators.

If the csv.rb routine were to read the data thru the standard "gets"
input line methods, the problem would cease to exist.  Would you please
modify your code to make it possible to bypass the raw disk read, and
use standard IO calls for text files instead, or eliminate the raw read
altogether?