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 <[EMAIL PROTECTED]> 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 > [email protected] > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
