Importing/exporting data with carriage returns (I Think)

[Fairlight]

Easily addressed:

s/\r$/\002/

s/\r/\001/g

s/\002$/\r/

m->

On Tue, Aug 29, 2017 at 11:14:13AM -0500, Richard D. Williams via Filepro-list thus spoke:
> This tip from Mark will not work;
> 
> Why not just translate the \r to \001 before import, and then whenever
> outputting or otherwise referencing the data on the way out, translate \001
> to \r?
> 
> If you replace one \r with a \001, you replace all. Therefore the
> row terminator is still not unique.
> 
> There is a PHP Class that will read column values directly from an xls file.
> 
> https://stackoverflow.com/questions/13439411/from-xlsx-sheet-rows-to-and-php-array
> 
> But, as Mike is not a programmer, this may not be a solution for him
> to pursue.
> 
> Richard D. Williams
> 
> On 8/28/2017 6:27 PM, Brian K. White via Filepro-list wrote:
> >On 8/28/2017 3:16 PM, Fairlight via Filepro-list wrote:
> >>They call it -logic-. ...
> >
> >I don't see that Mike did anything wrong deserving of these responses.
> >
> >He's not a programmer and lacked the background to make sense of
> >your initial answer. That is not illegal. Once you establish that,
> >just switch into that mode.
> >
> >
> >Mike, this kind of thing can be addressed several possible ways,
> >and Mark's first answer was really just meant as a general
> >description or basic outline of one possible approach, not any
> >kind of exact commands or details. No one could offer any exact
> >details yet at that point because we didn't yet know enough
> >details about your situation. First comes picking a possible
> >approach, then comes hashing out what exact details are required
> >to make that happen.
> >
> >That idea might not have been practical for you for some reason,
> >or might be doable but might not be the most convenient option
> >available. It was too early at that point to do more than
> >essentially spitball some different basic possible approaches.
> >
> >For instance:
> >
> >* If there are CR's or LF's or both within the cells, then how ARE
> >the records delimited, if not by CR? Maybe you don't need to do
> >anything but adjust the record delimiter option on the import
> >command line in processing. That would be much better than
> >cobbling together some external pre-processing steps.
> >
> >* Or, you could do your own more manual parsing of the data by
> >using open and readline instead of import. Then you could detect
> >incomplete records and read in the next line, and concatenate to
> >the previously read line, repeat until you know you have read in a
> >complete record (by counting the commas that weren't inside any
> >quotes or something). This would not be convenient to write at
> >all, but it's one and only advantage is, it would be done entirely
> >in filepro processing and doesn't depend on any external programs
> >or batch files, and once it's done, it's done. It'll then 'just
> >work" forever.
> >
> >* Or, if you control the export, then maybe you could alter the
> >export to make it possible for fp to import it reliably. (again,
> >even this one idea, has many possible meanings. Impossible to
> >guess them before even knowing the first thing: "if you control
> >the export". Only IF that is true, the next question would be,
> >what program are you exporting from? maybe that program has some
> >option to specify the record delimiter, or if not, maybe you can
> >add another column to the data that you could then look for in
> >processing to detect the real end of the record. Or maybe you
> >could export in a fixed-length format, and then the filepro import
> >wouldn't even look at any LF or CR at all. They would just be
> >bytes like any other bytes.)
> >
> >* Or maybe pre-processing the data is the most practical way to go
> >after all.
> >
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 

-- 
Audio panton, cogito singularis.