Got a LiveCode personal license? Are you a beginner, hobbyist or educator that's new to LiveCode? This forum is the place to go for help getting started. Welcome!
replace numToChar(13) with numToChar(10) in container
or
replace numToChar(13) with linefeed in container
before exporting it to a file, because LC will translate it into mac linebreaks. I need unix linebreaks cause my database managers only like import files with unix linebreaks.
export your text to BINFILE (instead of FILE) , that will preserve your modifed line breaks!
...
put my_text_with_unix_linebreaks into url("BINFILE:" & wherever & "/unixlinebreaks.txt"))
...
Like Klaus said. With the open/write/close method, the difference between text writes (which alter line-endings to be native to the current host platform) and binary (which leaves data in its LC-native format, where LC happens to use Unix line-endings), this is handled in the open command, e.g.:
Thanks Klaus, FourthWorld; you both made my day. Both ways work like a charm. Alas, for very large files (I mean a monster of 700MB) the option of opening in binary and use the read/write is much faster that using the url binfile option, so I used the former. Thanks again.
danielrr wrote:...for very large files (I mean a monster of 700MB) the option of opening in binary and use the read/write is much faster that using the url binfile option...
With either the URL or open method, binary is also faster than text mode, since it avoids the overhead of tracking down and replacing line endings. Texyt mode is useful for trivial reads and writes where platform-specific line endings may be a nice convenience for the end-user. But as a general rule I tend to use binary mode to get optimal performance and have assurance I'm working on unaltered data.
Richard Gaskin LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn