Format of options file

[RS]

On 04/03/18 21:34, Ralph Corderoy wrote:
> 
> 
> It probably doesn't.
> 
> Let's forget Mac for the moment.  Linux text files are POSIX text files;
> zero or more lines, each terminated by a LF.  See ascii(7).  DOS ones
> use CR followed by LF at the end of each line.
> 
> Thus a DOS text file looks like a text file to Linux, but one where the
> last character at the end of each line, just before the LF, is a CR,
> which is just another possible byte that could be within the line.  If
> the operation you're doing doesn't mind that the CR is present then it
> works;  reading the PID from the start of the line and using it as a
> key.  But if you're using the data that runs to the end of the line then
> you'll pick up the unwanted CR and that may do things like corrupt the
> output.

Hi Ralph

Essentially you seem to be saying I can't have a CR in a Linux text file 
because it is non-standard.  It seems a strange standard that prevents 
data interchange rather than facilitates it. My approach would be to 
ignore the CR or to recognise three possible end of record markers, but 
it seems that is not allowed.

One article I read mentioned that errors can be caused by strict 
adherence to a standard so that the last line of data is ignored if it 
does not end with a newline.

I can exchange data in elaborate formats like DOCX, ODT or H.264 but I 
can't as a text file.

What is the answer?  How can Windows and Linux exchange data in text 
files without requiring the user to run them through external conversion 
programs?

Best wishes
Richard