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