numToChar(13)

[David Bovill]

Thanks martin - sounds good practice for Rev.

On this "standards" issue I got a question though about the Rev internet
library and "NLIST"... the result of libURLSetFTPListCommand "NLST" should
return a standard result - either because of the relevant rfc - or because
it makes sense for the Rev to library to do this - I don't really see the
value of the library returning anything other than standard Rev CR between
lines of for ftp directory listing?

On 31/03/2008, Martin Baxter <mb.userev at harbourhosting.co.uk> wrote:
>
> 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
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>