|
|
Post by tsh73 on Feb 28, 2019 17:37:12 GMT -5
Writing to file under Win 10
makes weird newline
Expected under Windows: CR LF (0x0D 0x0A)
UNIX style: single LF (0x0A)
Got instead: single CR (0x0D)
Then opened in Notepad, I see no new lines at all - just single long line of text.
(though pasted here to the forum it renders right.
And I tried line input - it reads lines back right as written, line-by-line
)
|
|
|
|
Post by Carl Gundel on Mar 1, 2019 10:59:21 GMT -5
Writing to file under Win 10 makes weird newline Expected under Windows: CR LF (0x0D 0x0A) UNIX style: single LF (0x0A) Got instead: single CR (0x0D) Then opened in Notepad, I see no new lines at all - just single long line of text. (though pasted here to the forum it renders right. And I tried line input - it reads lines back right as written, line-by-line ) This is important, and I'd like to hear what people think about this. I wonder if we should do something like this: PRINT #handle, expr 'use the OS behavior PRINTLF #handle, expr 'extended - use LF as line terminator PRINTCRLF #handle, expr 'extended - use CRLF as line terminator This way we can produce identical output on different OSes by using extended PRINT statements. |
|
|
|
Post by Alyce Watson on Mar 1, 2019 11:29:48 GMT -5
Is this something you can do internally, by checking the OS and modifying the command at runtime, rather than asking the programmer to manage it?
|
|
|
|
Post by tsh73 on Mar 1, 2019 11:36:26 GMT -5
Me don't likes making special keywords just for that.
What about having global variable for NewLine
(like NET Environment.newLine, or record delimiter (separator) RS in awk)
, initialized with system default? (EDIT based on Platform$)
Now if we need it different we just explicitly set it.
(oh and it should be used for LINE INPUT as well)
|
|
|
|
Post by Chris Iverson on Mar 1, 2019 11:37:01 GMT -5
Alyce Watson: I think that's what his intention is for the first command: it uses default OS behavior. The PRINTLF and PRINTCRLF versions are for people who want to explicitly use a specific one, which WILL help with cross-platform file compatibility. You'd probably have to adjust LINE INPUT, as well, or a file that processes properly in and out on one platform won't do so on another.
|
|
|
|
Post by Carl Gundel on Mar 1, 2019 11:55:30 GMT -5
Is this something you can do internally, by checking the OS and modifying the command at runtime, rather than asking the programmer to manage it? I was thinking to remove ambiguity. You know very clearly what PRINTLF and PRINTCRLF do. No guessing and they always do the same thing on every platform. PRINT on the other hand does the OS expected behavior. |
|
|
|
Post by Rod on Mar 1, 2019 11:55:42 GMT -5
Perhaps it isn't about writing the file. Perhaps it is about reading the file. You might have a Preferences switch that uses OS,LF or CRLF but it isn't solving the problem for shared reading, is it? Don't fancy extended command use, don't see how it helps.
Can we automatically adjust reading for the used delimiter? So if LF is used we use that as the line break, if CRLF is used we use that for the line break. And does that open up a discussion about ASC/ UTF8
Is it as simple as ignoring found CRs?
|
|
|
|
Post by Carl Gundel on Mar 1, 2019 11:56:43 GMT -5
Alyce Watson : I think that's what his intention is for the first command: it uses default OS behavior. The PRINTLF and PRINTCRLF versions are for people who want to explicitly use a specific one, which WILL help with cross-platform file compatibility. You'd probably have to adjust LINE INPUT, as well, or a file that processes properly in and out on one platform won't do so on another. Maybe, but making INPUT read intelligently seems doable unless I'm missing something. |
|
|
|
Post by Carl Gundel on Mar 1, 2019 11:57:29 GMT -5
Me don't likes making special keywords just for that. What about having global variable for NewLine (like NET Environment.newLine, or record delimiter (separator) RS in awk) , initialized with system default? (EDIT based on Platform$) Now if we need it different we just explicitly set it. (oh and it should be used for LINE INPUT as well) Yeah I thought about setting the line delimiter in that way. Maybe. |
|
|
|
Post by Chris Iverson on Mar 1, 2019 12:11:51 GMT -5
Perhaps it isn't about writing the file. Perhaps it is about reading the file. You might have a Preferences switch that uses OS,LF or CRLF but it isn't solving the problem for shared reading, is it? Don't fancy extended command use, don't see how it helps. Can we automatically adjust reading for the used delimiter? So if LF is used we use that as the line break, if CRLF is used we use that for the line break. And does that open up a discussion about ASC/ UTF8 Is it as simple as ignoring found CRs? It quite possibly could be. Windows uses CRLF, and literally everything else that LB5 could run on uses LF. MacOS used to use CR, if I'm remembering that correctly, but it hasn't used that since it switched to being Unix/BSD based almost 20 years ago with Mac OS X. |
|
|
|
Post by Alyce Watson on Mar 1, 2019 13:50:11 GMT -5
Carl wrote, "I was thinking to remove ambiguity." I'm in favor of that, of course, but keeping the language as trim as possible is a goal, as well. More commands and functions = more complexity. Is the goal to allow ALL code to run on all platforms?
I'm thinking that a constant available to the programmer (the OS) would allow us to manage this more easily.
|
|
|
|
Post by donnybowers on Mar 1, 2019 18:32:40 GMT -5
Alyce Watson : I think that's what his intention is for the first command: it uses default OS behavior. The PRINTLF and PRINTCRLF versions are for people who want to explicitly use a specific one, which WILL help with cross-platform file compatibility. You'd probably have to adjust LINE INPUT, as well, or a file that processes properly in and out on one platform won't do so on another. Maybe, but making INPUT read intelligently seems doable unless I'm missing something. If I remember correctly, with LB4 you can read a Unix file into a TEXTEDITOR CONTROL with no problem. But, when you print it back out, it's still a Unix file. So now, if you want to parse that file, say to make it into an HTML file (or some other conversion), it won't read it line by line so you can parse each line. Perhaps it's less of a problem in Linux because all it looks for is the LF and probably doesn't care about the CR. I once had a professional programmer friend who told me that one of the great things about BASIC programming is the ease of parsing files to upgrade file formats. He said his company hires some BASIC programmers just for that purpose. It seems to me that 'making INPUT read intelligently' is probably the best idea for avoiding problems between platforms. Right now I can read a Windows file into LB5 Linux line by line, and easily convert it to Unix by simply adding chr$(LF); because LINE INPUT strips the line ending (doesn't it?). So conversion from Unix to Windows for sharing compatibility isn't too big of an issue when it's needed (if I'm thinking correctly). But, in LB4, I can't read a Unix file line by line in order to add the needed CR because LINE INPUT apparently looks for the CR. Conversion can be done of course, but it's a much more elaborate parsing project (parsing character by character); because "LINE INPUT #F, txt$" will read the whole file instead of just one line of text. Most text files are going to be used internally by LB in whatever system your using. So for convenience sake it should probably default to whatever platform you're using at the time IMO. I can't tell you how many hours I've spent trying to figure out why my program is behaving so strangely and then finally figuring out that I forgot to convert a file from Unix to Windows. So from that perspective, making INPUT read both types of files intelligently (especially LINE INPUT) would make shared files much more compatible. All that confusion and mess would be avoided if LB could read and process lines of text exactly the same way regardless of platform. I hope I explained that well and that you find it helpful Carl. In any case I do believe this is a major issue to get right. I know I will probably eventually be using LB5 on 3 different platforms (Windows just for testing purposes), and having to always worry about file conversion would suck. I guess if I was looking for a simple solution, I would make the LINE INPUT command only look for the LF on both platforms, since both use that character. Unless there's something else I'm not thinking of, this might just solve the whole issue. Why should LB care which file format you're using? Don't take my word on that part though because I might not be thinking right. I'm just thinking of my own experiences with the LINE INPUT command in LB404 on a Linux system or copying and pasting Unix code into my LB created TEXTEDITOR and then later trying to convert those lines to HTML. Call it brainstorming? |
|
|
|
Post by Stefan Pendl on Mar 3, 2019 5:58:06 GMT -5
If file input is done in an intelligent way, then there will be no need to have different output commands.
I support a flag variable for specifying the new line character, if it must be different from the one used by the current O/S.
If the file system functions of LB5 would be pre-processing paths internally to meat the path separator requirements of the current O/S, there will be less to take care of.
|
|
