Unix import of a DOS spreadsheet...

[Richard Kreiss]

> -----Original Message-----
> From: filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com
> [mailto:filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com] On
> Behalf Of Brian K. White
> Sent: Tuesday, September 07, 2010 2:39 PM
> To: filepro-list at lists.celestial.com
> Subject: Re: Unix import of a DOS spreadsheet...
> 
> On 9/5/2010 12:04 PM, John Esak wrote:
> > Oh well, at least Stuart did have working syntax in the book.  I was
wrong.
> 
> No he did not have working syntax.
> Mike said Stuart had r=10&13
> That's 2 bytes which is not valid.


What Stuart had was \r=\n and indicated that 
 \n for Unix  was  ASCII 10  NL
for windows was 13/10 CR/NL

So, using \r=\n	would be like using \r13/10 by using the \n still within the
byte limit.


Richard Kreiss
GCC Consulting
rkreiss at gccconsulting.net
  



> 
> That specific claim of the possibility of 2-bytes, by any possible syntax
or
> representation, was Mike's sole and entire question. Not the various ways
to
> express a single byte, but the possibility of more than one byte by _any_
> means. He knows all the ways to express one byte and all the ways to
> manually strip or otherwise disregard the extra CR like assign it to a 1
byte
> field and ignore it, or run it through dos2unix or sed, or xlate the last
field
> etc... it would just be efficient and smart to make use of a built-in
feature to
> do it for him if it existed.
> 
> Personally I think the smartest way is to keep it all in filepro where the
> programmer can see the entire relevent logic in one place instead of
writing
> fp code that depends on some external scripts to have used some external
> binary first. It's more portable, maintainable and  transparent that way.
I like
> the xlate() on the last field idea. It doesn't cost much cpu, and you
could
> even optimize it by performing a test on the first record and only xlate()
if
> the 2nd-last byte of the last field of the first record was a chr("13").
But even
> if you just blindly xlate the last field all the time, it would
automatically handle
> 99% of situations correctly without ever having to rely on any unseen/non-
> obvious external pre/post-processing. Some other programmer can see your
> code and everything that matters is there in the processing, none of it is
out
> in some script you forgot to document in comments or forgot to include in
> your backups or restores or site migration etc...
> 
> --
> bkw
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list