Re: Format of options file

Rob Dixon Norfolk England -Original Message- From: Ralph Corderoy <ra...@inputplus.co.uk> To: get_iplayer@lists.infradead.org Sent: Tue, 06 Mar 2018 13:30 Subject: Re: Format of options file Hi David, > binmode does still work AFAIK, but a more modern and flexible method >

Re: Format of options file

> > binmode does still work AFAIK, but a more modern and flexible method > > is to use the crlf I/O layer, which is documented here: > > https://perldoc.perl.org/PerlIO.html > > > > Note however that an awful lot of perl code just doesn't bother. > > Windows stacks the `:crlf' layer by default.

Re: Format of options file

Hi David, > binmode does still work AFAIK, but a more modern and flexible method > is to use the crlf I/O layer, which is documented here: > https://perldoc.perl.org/PerlIO.html > > Note however that an awful lot of perl code just doesn't bother. Windows stacks the `:crlf' layer by default. I

Re: Format of options file

On Mon, Mar 05, 2018 at 08:04:09PM +, RS wrote: > It's worse than I thought. I had got the impression from the perlport > perldoc that if replaced \n with \012 in a print statement I would get a > LF on its own in Windows. I don't. If I insert \015 I can have a CR on > its own, but \012

Re: Format of options file

Hi MacFH, > nor am I questioning the use of device drivers, obviously they make a > lot of programming sense.  What I'm questioning is the wisdom, perhaps > that should be rank stupidity, You're saying Unix's core designers are stupid for choosing to stick with text files as lines terminated by

Re: Format of options file

We could argue about this for hours, but I have no desire to do so  -  there are things I like and others I detest about both OSs, and the thread's becoming increasingly OT.  I answer one specific point below, but anyone not interested in computer history and debugging programs can safely

Re: Format of options file

Hi David, > Macs use \n like normal Unix machines. They used to use \r in the bad > old days before they went Unixy. Yes, you're right. Earlier in the thread I said I thought they used CR, but that was much earlier up to Mac OS 9. Mac OS X came along around 2000, was based on Unix, unlike 9,

Re: Format of options file

On 05/03/2018 14:19, Ralph Corderoy wrote: I suggested ignoring CR because they are there. Ideally they would not be there. The files are internal to get_iplayer so they can be in any format. Only if you don't want them to be native text files, editable on that system with a text editor by

Re: Format of options file

On Mon, Mar 05, 2018 at 09:52:53AM +, RS wrote: > 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. Yes, it is strange that Microsoft chose a

Re: Format of options file

On Sun, Mar 04, 2018 at 07:59:52PM +, RS wrote: > You're right I am a bit confused, but not about the line termination > conventions for each OS, although I can't speak for the Mac. Macs use \n like normal Unix machines. They used to use \r in the bad old days before they went Unixy. --

Re: Format of options file

Hi Richard, > I suggested ignoring CR because they are there. Ideally they would > not be there. The files are internal to get_iplayer so they can be in > any format. Only if you don't want them to be native text files, editable on that system with a text editor by any user. And I thought you

Re: Format of options file

On 05/03/2018 13:19, Ralph Corderoy wrote: My approach would be to ignore the CR or to recognise three possible end of record markers, but it seems that is not allowed. It certainly is allowed. It would be the Richard Text File Format. Programs could code to handle it. More precise

Re: Format of options file

Hi MacFH, > '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 >

Re: Format of options file

On 05/03/18 12:55, MacFH - C E Macfarlane wrote: 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 ... This is a long-standing problem for any organisation that exchanges text

Re: Format of options file

Hi Richard, > > 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

Re: Format of options file

On 05/03/2018 12:14, Colin Law wrote: Yes, I agree. For anyone who knows the code it should not be difficult to ignore CR characters after the text. I expect it is already ignoring white space after it. Any patch takes time to work out and to test though. For history (I haven't yet found

Re: Format of options file

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

Re: Format of options file

On 05/03/2018 19:07, Roger Bell_West wrote: On Mon, Mar 05, 2018 at 06:25:58PM +0800, Alan Milewczyk wrote: I've been following the gist of the thread but not the detail. I am wondering whether the answer to your second question is that they can't!!! Sorry my statement should be qualified  by

Re: Format of options file

On 5 March 2018 at 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 >> >

Re: Format of options file

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

Re: Format of options file

On 3 March 2018 at 11:09, Ralph Corderoy wrote: > > Hi Richard, > > > ') - using defaultalue for --ffmpeg-loglevel ('info > > > > If I enter the options again with --prefs-add they work correctly, so > > it is no big deal. Any ideas what is happening? > > That line above

Re: Format of options file

On Mon, Mar 05, 2018 at 06:25:58PM +0800, Alan Milewczyk wrote: >I've been following the gist of the thread but not the detail. I am wondering >whether the answer to your second question is that they can't!!! It would be possible to rewrite get_iplayer to make it agnostic with respect to line

Re: Format of options file

On 05/03/2018 17:52, RS wrote: 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? I've been following the gist of the thread but not the detail. I am wondering whether the answer to your

Re: Format of options file

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

Re: Format of options file

Please see correction below ... On 04/03/2018 21:52, MacFH - C E Macfarlane wrote:     for  F  in  options  download_history  *.cache  ;  do dos2unix -n  .get_iplayer.bak/$F  .get_iplayer/$F  ;  done I've just realised that this may no do the *.cache files because they are in a different

Re: Format of options file

Please see below ... On 04/03/2018 19:59, RS wrote: On 04/03/18 15:52, MacFH - C E Macfarlane wrote: On 04/03/2018 00:24, RS wrote: On 03/03/18 23:44, MacFH - C E Macfarlane wrote: But as the OP is changing over to Linux, perhaps the de facto standard 'dos2unix' would be a more

Re: Format of options file

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

Re: Format of options file

On 04/03/18 15:52, MacFH - C E Macfarlane wrote: Please see below ... On 04/03/2018 00:24, RS wrote: On 03/03/18 23:44, MacFH - C E Macfarlane wrote: But as the OP is changing over to Linux, perhaps the de facto standard 'dos2unix' would be a more appropriate recommendation. Thanks for

Re: Format of options file

Please see below ... On 04/03/2018 00:24, RS wrote: On 03/03/18 23:44, MacFH - C E Macfarlane wrote: But as the OP is changing over to Linux, perhaps the de facto standard 'dos2unix' would be a more appropriate recommendation. Thanks for the suggestion but I don't think I need to convert

Re: Format of options file

On 04/03/18 12:40, michael norman wrote: On 04/03/18 09:25, RS wrote: On 04/03/18 00:24, I wrote: If download_history can use 0x0A as a line terminator in both Linux and Windows I can't see why the options file should not also.  The options file is internal to get_iplayer.  Users do not

Re: Format of options file

On 04/03/18 09:25, I wrote: On 04/03/18 00:24, I wrote: If download_history can use 0x0A as a line terminator in both Linux and Windows I can't see why the options file should not also.  The options file is internal to get_iplayer.  Users do not need to edit it directly. I would add

Re: Format of options file

On 04/03/18 09:25, RS wrote: On 04/03/18 00:24, I wrote: If download_history can use 0x0A as a line terminator in both Linux and Windows I can't see why the options file should not also.  The options file is internal to get_iplayer.  Users do not need to edit it directly. I would add that

Re: Format of options file

On 04/03/18 00:24, I wrote: If download_history can use 0x0A as a line terminator in both Linux and Windows I can't see why the options file should not also.  The options file is internal to get_iplayer.  Users do not need to edit it directly. I would add that now Linux fully supports NTFS

Re: Format of options file

On 4/03/2018 9:54 AM, Bernard Peek wrote: > > On 03/03/18 17:33, James Scholes wrote: >> RS wrote: >>> The Windows download_history file seems to work correctly.  I hope I >>> don't need to edit it. >> >> You've probably edited your options file by hand in the past, >> resulting in a mixture of

Re: Format of options file

On 03/03/18 23:44, MacFH - C E Macfarlane wrote: Please see below ... On 03/03/2018 22:54, Bernard Peek wrote: On 03/03/18 17:33, James Scholes wrote: RS wrote: The Windows download_history file seems to work correctly.  I hope I don't need to edit it. You've probably edited your

Re: Format of options file

Please see below ... On 03/03/2018 22:54, Bernard Peek wrote: On 03/03/18 17:33, James Scholes wrote: RS wrote: The Windows download_history file seems to work correctly.  I hope I don't need to edit it. You've probably edited your options file by hand in the past, resulting in a mixture

Re: Format of options file

On 03/03/18 17:33, James Scholes wrote: RS wrote: The Windows download_history file seems to work correctly.  I hope I don't need to edit it. You've probably edited your options file by hand in the past, resulting in a mixture of weird line endings from a Windows editor, and appropriate

Re: Format of options file

RS wrote: The Windows download_history file seems to work correctly.  I hope I don't need to edit it. You've probably edited your options file by hand in the past, resulting in a mixture of weird line endings from a Windows editor, and appropriate ones when get_iplayer itself has updated it.

Re: Format of options file

On 03/03/18 11:09, Ralph Corderoy wrote: Hi Richard, ') - using defaultalue for --ffmpeg-loglevel ('info If I enter the options again with --prefs-add they work correctly, so it is no big deal. Any ideas what is happening? That line above seems to be overprinting the «')» at the start of

Re: Format of options file

On 03/03/18 10:53, I wrote: Is the format of the options file different in Windows and Linux? ... The criterion seems to be that options with a numeric or boolean value like --subtitles or --expiry work. Options with a string value like --tvmode, --radiomode or --ffmpegloglevel don't.