Format of options file

[MacFH - C E Macfarlane]

Please see below ...

On 05/03/2018 12:02, Ralph Corderoy wrote:
> Hi Colin,
>
>>>> ') - using defaultalue for --ffmpeg-loglevel ('info
>>> That line above seems to be overprinting the «')» at the start of
>>> the line suggesting there's an ASCII CR, carriage return, after the
>>> `info' as if a Unix system was reading a POSIX text file of lines
>>> ending in ASCII LF, linefeed, but being fed a DOS one with CR LF
>>> pairs.
>> Are we certain that the problem has been correctly analysed?
> Yes, I did.  :-)
>
>> The line shown above appears to have a CR after info and before the
>> quote sign, which would not be valid on either system.
> Because the value is «info\r» and it's being printed surrounded by
> «('...')».
>
>      WARNING: invalid value for --ffmpeg-loglevel ('$opt->{ffmpegloglevel}') - using default\n
>
> becomes
>
>      WARNING: invalid value for --ffmpeg-loglevel ('info
>      ') - using default
>
> becomes
>
>      ') - using defaultalue for --ffmpeg-loglevel ('info

Seems valid reasoning to me.

Some people may be misunderstanding the precise meaning of 'Carriage 
Return'.  I'm not 100% up on my telecoms history, but AIUI ...

CR, LF, etc are ASCII acronyms, it itself being one for American 
Standard Code for Information Interchange, 
https://en.wikipedia.org/wiki/ASCII, which was a coding designed 
originally to allow early telecoms equipment to inter-operate. 'Carriage 
Return', CR, meant precisely that  -  in other words, move the slidable 
teleprinter carriage holding the paper to the right so that the fixed 
print head is at the left margin position.  LineFeed, LF, also meant 
exactly that, rotate the carriage roller to move the printing position 
to the next line.  Thus to print a new line of teleprinter output, both 
a CR and a LF are required.  DOS followed by Windows have always stuck 
by the original meaning of these codes, and thus both use both codes at 
the end of lines of text.  Arguably the oddballs are Linux and perhaps 
Macs, using only one.  This would mean that if their text was sent 
directly to a teleprinter, the output would not be what is required, but 
of course these days that would seldom if ever be done.  However, when 
printing CRs to the Linux console, as Ralph has explained above, Linux 
still retains the original meaning of CR, and moves the cursor back to 
the beginning of the line, and in the absence of a line feed immediate 
following, any other text following overprints  the beginning of the 
same line.  Linux could be argued to have subverted both codes, because 
not only does a LF move the cursor to the next line of text, but an 
implicit CR is also performed, which is why having only a LF at the end 
of each line of text works in Linux, but what really throws the spanner 
in the works is that Linux counts a CR preceding a LF as part of the 
text of the line, not as part of the line termination, hence the 
original problem and subsequent rather convoluted thread.