numToChar(13)

[Martin Baxter]

David Bovill wrote:
> Recently had the following problem processing lists from ftp directories -
> fetching and displaying the directories in a list field was fine but when I
> tried to use the list field to obtain an ftp url the script failed - the
> debugging was a nightmare as the ftp url looked correct and manually
> entering the url worked fine. The problem? numToChar(13) returned from the
> ftp url. So I now use this script to fetch the directory listing:
> 
> function ftp_FolderContents ftpDirectory
>>     libURLSetFTPListCommand "NLST"
>>     get word 1 to -1 of url ftpDirectory
>>     replace numToChar(13) with empty in it
>>     return it
>> end ftp_FolderContents
> 
> 
> 
> Rev uses numToChar(10) for line endings (showing its Unix origins), but if
> written to a file on a Mac, using URL "file:", they're translated to
> numToChar(13). if using URL "binfile:", no translation happens, so
> numToChar(10) is preserved. I thought the act of putting text into a field
> cleaned' up the line endings to standard Rev numToChar(10) = CR's - but
> seems not? I am also not quite sure hwat to expect from different ftp
> platforms - it seems NLST is CRLF seperated - but my server is Unix not a
> PC?
> 
> I am wandering if there is any tutorial out there that goes into these
> issues in any depth - they also come up when using certain command line
> tools, and reading and writing data in CGIs.

David,

FWIW here's what I do with incoming text whose line ending delimiters
are not known, but which are assumed to be some combination of LF and/or CR.

replace crlf with lf in tText
# if line-endings were LF or CRLF they are now LF
replace numtochar(13) with lf in tText
# if line-endings were CR (ascii 13) they are now LF

This results in LF line-delimiters in tText, regardless of the original
format, which you don't need to know. On modestly sized texts RR is
easily fast enough for this to be practical.

HTH

Martin Baxter

-- 
I am Not a Number, I am a free NaN