Format of options file

[Ralph Corderoy]

Hi Richard,

> What I said the download_history file was wrong.  I have now looked at
> it with a hex editor which allows me to view the whole file.  Most of
> it was written in Windows and has CRLF as a line terminator.  The most
> recent records, appended to the end, written in Linux, have LF as a
> line terminator.  The important thing is that the discrepancy does not
> stop it working.  The entries are indexed by pid.  The script is able
> to find the pid whether it is preceded by LF or CRLF, and identify the
> programme as already in history.  The mixed file works both in Linux
> and in Windows.

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.

    $ seq 3
    1
    2
    3
    $ seq 3 | grep '^2$'
    2
    $ seq 3 | sed 's/$/\r/'
    1
    2
    3
    $ seq 3 | sed 's/$/\r/' | grep '^2$'
    $ 
    $ seq 3 | sed 's/$/\r/' | sed -n l
    1\r$
    2\r$
    3\r$
    $ 

The first grep works.  Appending CR with sed doesn't change the apparent
appearance, but it's there as a byte so the second grep fails to find
the line that contains just `2'.  sed's `l' command shows up the
problem.

So the new lines added by Linux to the end of the history file might
well look like one long, unterminated as there's no CR LF, line to
Windows.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy