-=> mark lewis wrote to Tony Langdon <=-

 ml> AFAIK, yes... i have no clue what OS the data files my project works
 ml> with are created on or what kind of transfers and conversions may
 ml> happen before the data is zipped... we use a script that pulls the zips
 ml> from the remote server(s) and unzips it... then my project takes
 ml> existing data in locally processed text files and loads in the new data
 ml> from the remote server... it hasn't cared about EOLs on any systems
 ml> i've run the project on... each one pulls the data archives from the
 ml> remote server(s) and off we go to the races...

Cool, that's even better. :)  My guess would have been that FPB would have
defaulted to behaviour native to the OS the binary was compiled for.  Looks
like there won't be any cross platform issues with text files.

 ml> now, if one must have the same EOL, that's easy enough to do... IIRC,
 ml> there's one system variable that you can
""override"" to make it use
 ml> 0x0d0a for EOL on all systems... or you can go for 0x0a on all or even
 ml> 0x0a0d (older mac eol) if you desire...

Nah, just wanted to make sure we can read logs from different systems without
error. :)  I sent Steven samples of the same log extract in Windows and Unix
format, so he should be able to confirm this.

 ml> FPC is very flexible when it comes to plain ASCII text files using the
 ml> traditional readln and writeln routines... now, if you want to use that
 ml> UTF-8 mess, it is a whole other story...

AFAIK, logs are in plain ASCII. :-)


 ml> FWIW: my project is a TLE processor... if anyone knows what a TLE is,
 ml> they will have an idea of what my project does ;)

Tracking satellites, are we? ;)

Yep, I do know what TLEs are, and have used them many times. :-)


... These mating rituals you humans indulge in are quite disgusting.
--- MultiMail/Win32 v0.49