numToChar(13)

[Joe Lewis Wilkins]

Jim,

You paint a pretty bleak picture to the aspiring "programmer/coder/ 
scripter". Are we already too far gone to espouse the establishment of  
some kind of standard? Or, at least, some method of Universal  
conversion to a common standard; perhaps something as mundane as a  
conversion function? I, for one, would not have the foggiest of ideas  
as to how to begin such a task, but you seem to have something of an  
handle on the subject. Thanks for your, as always, insightful  
contribution.

Joe Wilkins


On Mar 31, 2008, at 7:37 AM, Jim Ault wrote:

> On 3/31/08 6:32 AM, "David Bovill" <david at openpartnership.net> 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.
>
> Since this is a tricky area that usually requires customization, a  
> quick
> suggestion:  Google the terms that would apply to your situation,  
> bookmark
> these for reference.
>
> Another excellent reference area is PHP.NET when it comes to managing
> characters for web, ftp, and database delimiters.  As you will soon  
> find, it
> can be very tricky and confusing when moving data from platform-to- 
> platform
> and app-to-app.
>
> And of course, you could post your specific need to this list and  
> let others
> learn some of the tricks that sometimes take hours to develop.
>
> This is an area that I deal with frequently since I grab data from  
> various
> sources (other apps, text files, databases, web pages, ftp sites, php
> servers, CD published archives, spreadsheets).  There is no  
> 'standard' since
> all of these formats have their own delimiter conventions and escaping
> rules.  (Now add grep to the mix and you have some real head  
> scratchers)
>
> The main caution I would give you is to be aware of the exact  
> escaping rules
> for each data source and its storage location.
>
> One example is the path name which has special characters depending  
> on the
> operating system (not to mention 'long name' limitations).  I  
> believe that
> most of this is documented in our list archives.  It is like driving  
> your
> car on vacation.. you may or may not have to worry about crossing  
> water.
>
> The Rev docs do get into the use of binfile, CRLF and other issues  
> that
> regard single character replacements, but there are other  
> considerations:
>
> encoding files for storage or transfer, then decoding later
> multi-character html entities
> xml tag rules
> database text string storage
> CSV, tab delimited files that include quotes and commas in the data
> invisible files on ftp sites
> permissions that allow the directory listing but not access to the  
> file
> contents
>
> It is difficult to find a single source for these issues, but they are
> critical to successful programming.
>
> Hope this helps
>
> Jim Ault
> Las Vegas