Hi Ted:
In my previous message on this subject I said:
------------------------------------------------------------------------
By the way, the CRs that I had in my copies of the data files that I
used for my previous testing had to be manually entered using Okteta,
because they weren't present in the copy/paste data for ndata2.dat. I
must have gotten my facts turned around when I stated that the CRs
showed up as a result of the copy/paste operation.
------------------------------------------------------------------------
I've done a little more exploring and I have discovered the source of my
confusion.
When I initially created my data files, I used kwrite as the text
editor, which is configured for automatic end of line detection so it
uses what ever line endings are present in the open file; a fact I only
discovered this morning.
After I edited ndata1.dat with okteta to include the CRLF sequences, I
opened that file again with kwrite to see the effect on it. Without
closing kwrite, I created the other data files by copy/paste from your
email message and used "Save As " to rename them. Since I hadn't closed
kwrite, it kept the CRLF line endings for all of the data files I saved,
which caused me to think I was getting the CRLF sequences from the
Thunderbird email message.
With the CRLF sequences in the file, the read_data function chokes on
the seemingly blank lines with the CRLF sequence whether I use:
"if %l # "" then"
or
"if slength(%l) # 0 then"
as the zero-length test.
I had to include:
"%l : strim(" ", ssubst(" ", ascii(13), %l ) ),"
just prior to the zero-length test for proper operation.
A simple work-around for linux/unix users is to run, from a terminal window:
dos2unix <filename> on the data file if dos2unix is installed.
Paul