In reply to your message: [Re: [MacPerl] escape oddities...] [10/02/1999] <snip> # No they weren't there, but there was a character that was translated by # Fetch as a \n that was not a \n. A bug in Fetch, the result of the way # the character was interpreted by a platform, due to a bug in my script? I # really don't know and haven't been able to reproduce it. It wasn't a # problem, just an annoyance. Viewing the file with Fetch clearly showed # the database records broken mid-field with a \n, but the script(on unix - # admittedly slightly off topic) churned out the records properly # nonetheless. This would of course be impossible if there were actually a # \n in a database field. It could have been an \013 - which is what FileMaker uses for field EOL's. Should be easy to 'reproduce' though, just download in binary mode and then view with Alpha or whatever to get the characters octal code. Andy -------------------------- bibleBlack@starless.com.au ***** Want to unsubscribe from this list? ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch