Post by tenochtitlanuk on Jul 25, 2020 15:33:04 GMT -5
I confirm Paul's results under LB4.5 ( under Linux/Wine) and LB5-351 native in Linux. But I've got into the habit of checking files I save or download in a hex editor since I still use Windows occasionally and text/data files can use CR, LF, CRLF and LFCR!
Are you saying that the CR+LF is not being created while using the LB5 IDE?
Yes, when run in LB 4.5.1, I get a CR+LF at the end of each line.
When run in LB5, it only gives the CR.
If you load the "OutPut.bas" file in the LB5 IDE, there's no problem. It loads and runs. But if you then try to load the "OutPut.bas" file in the LB 4.5.1 IDE, it seems to need a CR+LF pair. If you can, test the code you supplied by running it under the LB5 IDE and then try to load the output.bas file in the LB 4.5.1 IDE.
It seems to be a problem in LB5. Every other basic I've used (including LB4.5.1) assigns a CR+LF pair at the end of a line written to a file.
Having a system variable that sets the default line end is good. Consistent. You either write and read files with CRLF or just LF.
But, and it is a big but, or it might not be. Reading a foreign file, how to know what delimiter has been used?
So I am messing about in Windows and happen on a Linux file, or, I am messing about in Linux and happen on a Windows file.
If we open a file can we auto detect what line end combination is used? Can we test it and see if we find CRLF or only LF, can we then switch mode?
Perhaps too complex.
Can we just use the LF which is common to both and ignore the CR if it exists? So we always write CRLF unless the system variable says write LF. Reading files we react to the LF and ignore, or drop the CR if it exists. Reading gets everything up to the LF but drops any preceding CR. Currently we drop the whole CRLF combo and just get the data.
I can't find much on google but relying on the LF and dropping the CR should work for Windows, And so too Linux, react to the LF drop the CR.
There are different platform line endings for Windows and Linux, etc. But I can set up a global variable (or variables) where this can be changed.
For example OSLineEnd$ could be set to CR or CRLF depending on the OS, but then you could set it to whatever you like.
OSLineEnd$ = WindowsLineEnd$ or OSLineEnd$ = CRLFLineEnd$ OSLineEnd$ = LinuxLineEnd$ or OSLineEnd$ = CRLineEnd$
That sort thing. I'm open to ideas.
Then it might get a little more complicated if we want to set it differently for reading vs writing.
After a quick bit of online research the consensus seems to follow this method:
All versions of Microsoft Windows represent line endings as CR followed by LF.
UNIX and UNIX-like operating systems (including Mac OS X) represent line endings as LF alone.
While a global variable or even a setting within the IDE would be nice, it really should default to the normal usage of the operating system.
My personal opinion is that if you are using files from another OS, you need to program for that scenario. Whether it's to/from Windows, UNIX, C, C++, etc. Of course, when using the IDE for each operating system, the IDE should be able to ascertain the file deliminator and load the program in a cross-platform fashion. That way you can test code written in a windows environment on linux and the other way around.
Having slept on it I think I am suggesting an automatic replacement. So when line end files are read by commands that respect line ends the line end characters found should be replaced by the system variable line end.. but we need to hear from Linux users or someone more sensible than I.
I am not saying change the file, but on loading the line end characters should be replaced "internally". If they are written out to file they should take the system variable value, so in that case the file would be changed.
It would mean you could load/read any file without caring how it is line ended. The file itself would remain unchanged unless you chose to overwrite/rewrite it.