And we're back to the eighties again...
-
Did you know that if you export contacts in Outlook CSV format from Google Contacts, Outlook can't read it? :laugh: No, seriously. And why? Because it's stored with "\n" as the line separator instead of "\r\n" and Outlook doesn't like that, not at all. A windows app (Chrome) writes a text-based file that another Windows app (Outlook) can't read because the line terminator is Windows standard rather than it's preferred format. I thought we killed that in the eighties! Guess what, Microsoft? Excel can read it. Excel reads it fine provided it's got any type of line terminator ... :doh: [edit] OK, it's a trivial change:
string inPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts.csv"; string outPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts2.csv"; string\[\] lines = File.ReadAllLines(inPath); string appended = String.Join("\\r\\n", lines); File.WriteAllText(outPath, appended);but it shouldn't be necessary, not at all ... not this century. [/edit]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
Did you know that if you export contacts in Outlook CSV format from Google Contacts, Outlook can't read it? :laugh: No, seriously. And why? Because it's stored with "\n" as the line separator instead of "\r\n" and Outlook doesn't like that, not at all. A windows app (Chrome) writes a text-based file that another Windows app (Outlook) can't read because the line terminator is Windows standard rather than it's preferred format. I thought we killed that in the eighties! Guess what, Microsoft? Excel can read it. Excel reads it fine provided it's got any type of line terminator ... :doh: [edit] OK, it's a trivial change:
string inPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts.csv"; string outPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts2.csv"; string\[\] lines = File.ReadAllLines(inPath); string appended = String.Join("\\r\\n", lines); File.WriteAllText(outPath, appended);but it shouldn't be necessary, not at all ... not this century. [/edit]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
Did you know that if you export contacts in Outlook CSV format from Google Contacts, Outlook can't read it? :laugh: No, seriously. And why? Because it's stored with "\n" as the line separator instead of "\r\n" and Outlook doesn't like that, not at all. A windows app (Chrome) writes a text-based file that another Windows app (Outlook) can't read because the line terminator is Windows standard rather than it's preferred format. I thought we killed that in the eighties! Guess what, Microsoft? Excel can read it. Excel reads it fine provided it's got any type of line terminator ... :doh: [edit] OK, it's a trivial change:
string inPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts.csv"; string outPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts2.csv"; string\[\] lines = File.ReadAllLines(inPath); string appended = String.Join("\\r\\n", lines); File.WriteAllText(outPath, appended);but it shouldn't be necessary, not at all ... not this century. [/edit]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
\r\n is Windows standard (also ASCII standard) \n is Unix/Linux Standard \r is (was?) Apple Standard
Truth, James
-
Did you know that if you export contacts in Outlook CSV format from Google Contacts, Outlook can't read it? :laugh: No, seriously. And why? Because it's stored with "\n" as the line separator instead of "\r\n" and Outlook doesn't like that, not at all. A windows app (Chrome) writes a text-based file that another Windows app (Outlook) can't read because the line terminator is Windows standard rather than it's preferred format. I thought we killed that in the eighties! Guess what, Microsoft? Excel can read it. Excel reads it fine provided it's got any type of line terminator ... :doh: [edit] OK, it's a trivial change:
string inPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts.csv"; string outPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts2.csv"; string\[\] lines = File.ReadAllLines(inPath); string appended = String.Join("\\r\\n", lines); File.WriteAllText(outPath, appended);but it shouldn't be necessary, not at all ... not this century. [/edit]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
Ah, I see you wrote a small application - I used to do that also, when I was still in development. :-D Today, Text editor -> Ctrl+H -> replace "\r\n" with "\n" :sigh:
-
\r\n is Windows standard (also ASCII standard) \n is Unix/Linux Standard \r is (was?) Apple Standard
Truth, James
This post alone sums up everything about the notion of "standards". [There is probably an obligatory XKCD also to be included here].
-
This post alone sums up everything about the notion of "standards". [There is probably an obligatory XKCD also to be included here].
There sure is! xkcd: Standards[^]
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
Ah, I see you wrote a small application - I used to do that also, when I was still in development. :-D Today, Text editor -> Ctrl+H -> replace "\r\n" with "\n" :sigh:
Actually, for most text editors, it should just be
Load, Save
Truth, James
-
There sure is! xkcd: Standards[^]
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
:laugh: I knew it !
-
Actually, for most text editors, it should just be
Load, Save
Truth, James
Many plaintext editors default to preserving the newline convention detected when reading the file. So, between the reading and writing, you may have to change the newlinesetting before saving the file. I did write a similar mini-program a few years ago, doing not only newline changes, but also tab expansion (where you could specify a sequence of tab stops), transformation from a specified DOS codepage to ISO 8859-1, etc. Today, I do not encounter such a variety of text files; besides, I believe that Notepad++ can do 95% of what my program did. Today, I use Notepad for such tasks.
-
Did you know that if you export contacts in Outlook CSV format from Google Contacts, Outlook can't read it? :laugh: No, seriously. And why? Because it's stored with "\n" as the line separator instead of "\r\n" and Outlook doesn't like that, not at all. A windows app (Chrome) writes a text-based file that another Windows app (Outlook) can't read because the line terminator is Windows standard rather than it's preferred format. I thought we killed that in the eighties! Guess what, Microsoft? Excel can read it. Excel reads it fine provided it's got any type of line terminator ... :doh: [edit] OK, it's a trivial change:
string inPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts.csv"; string outPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts2.csv"; string\[\] lines = File.ReadAllLines(inPath); string appended = String.Join("\\r\\n", lines); File.WriteAllText(outPath, appended);but it shouldn't be necessary, not at all ... not this century. [/edit]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
Just use Excel. Load the file and re-save it. That should work unless Outlook is fussy about quoted strings - Excel always quotes strings in CSVs even if the original Griff string was unquoted and unchanged. Anyway, glad to hear that you are on the mend, albeit slowly. Take it carefully.
-
Ah, I see you wrote a small application - I used to do that also, when I was still in development. :-D Today, Text editor -> Ctrl+H -> replace "\r\n" with "\n" :sigh:
Since were all programmers: Open the file in VS, File -> Advanced Save options...
Wrong is evil and must be defeated. - Jeff Ello
-
Did you know that if you export contacts in Outlook CSV format from Google Contacts, Outlook can't read it? :laugh: No, seriously. And why? Because it's stored with "\n" as the line separator instead of "\r\n" and Outlook doesn't like that, not at all. A windows app (Chrome) writes a text-based file that another Windows app (Outlook) can't read because the line terminator is Windows standard rather than it's preferred format. I thought we killed that in the eighties! Guess what, Microsoft? Excel can read it. Excel reads it fine provided it's got any type of line terminator ... :doh: [edit] OK, it's a trivial change:
string inPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts.csv"; string outPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts2.csv"; string\[\] lines = File.ReadAllLines(inPath); string appended = String.Join("\\r\\n", lines); File.WriteAllText(outPath, appended);but it shouldn't be necessary, not at all ... not this century. [/edit]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
I would gladly go back... The eighties were awesome, totally! Big hair, parachute pants, Walkman's... etc. Hacking out basic code on a Radio Shack Color Computer (CoCo), and Apple IIe Life was good... you could shake people's hands, hug a friend, go to the movies. :)
Remember, no matter where you go... there you are.
-
I would gladly go back... The eighties were awesome, totally! Big hair, parachute pants, Walkman's... etc. Hacking out basic code on a Radio Shack Color Computer (CoCo), and Apple IIe Life was good... you could shake people's hands, hug a friend, go to the movies. :)
Remember, no matter where you go... there you are.
littleGreenDude wrote:
go to the movies.
Hmmm ... National Lampoon's European Vacation Police Academy Look Who's Talking Red Sonja K-9 Superman IV Mommie Dearest Howard the :elephant:ing Duck. Weird Science E.T. Trading Places The Money Pit ... OK, you also had Gremlins, Ghostbusters, and the Terminator, but ... you need very rose tinted glasses to watch most of 'em now! :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
I would gladly go back... The eighties were awesome, totally! Big hair, parachute pants, Walkman's... etc. Hacking out basic code on a Radio Shack Color Computer (CoCo), and Apple IIe Life was good... you could shake people's hands, hug a friend, go to the movies. :)
Remember, no matter where you go... there you are.
I guess that you are talking about going back to your youth carrying with you the 30-40 years of experience you have gained since. If you could go back to your youthful body and old-style surroundings, it would be something very different: it wouldn't be experiencing the insecurities and doubts and conflicts and whathaveyou, but an old man's view upon the world. That is what I could see as something desirable. But I never wanted to go back to my old mind, erasing all the experience I have gained. I never wanted to be a small kid again. Not a grown kid. Not a youth, nor a young adult, nor a middle aged man. I am happy that I am through with all those conflicts and demands and problems. It is much more satisfying leaning aback and relaxing with what I have gained.
-
Did you know that if you export contacts in Outlook CSV format from Google Contacts, Outlook can't read it? :laugh: No, seriously. And why? Because it's stored with "\n" as the line separator instead of "\r\n" and Outlook doesn't like that, not at all. A windows app (Chrome) writes a text-based file that another Windows app (Outlook) can't read because the line terminator is Windows standard rather than it's preferred format. I thought we killed that in the eighties! Guess what, Microsoft? Excel can read it. Excel reads it fine provided it's got any type of line terminator ... :doh: [edit] OK, it's a trivial change:
string inPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts.csv"; string outPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts2.csv"; string\[\] lines = File.ReadAllLines(inPath); string appended = String.Join("\\r\\n", lines); File.WriteAllText(outPath, appended);but it shouldn't be necessary, not at all ... not this century. [/edit]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
While I essentially agree, why blame Microsoft rather than Google? They're actually equally to blame, but Google erred first. Besides, saying that the line terminator is
\r\nis still imprecise; a line begins with\nand ends with\r. Get everything from the\nto the\rand you know you have a full and complete line; if not, you may have an incomplete line. (Of course, you also have to honor quotes and escapes.) Well, that and that it should be\n\r, but that's a different issue. Would you also like to argue the issues involved in the lack of a proper CSV standard? Just five minutes? Or the full half hour? Oh, wait, I also need to mention the superiority of the OpenVMS' file system... -
While I essentially agree, why blame Microsoft rather than Google? They're actually equally to blame, but Google erred first. Besides, saying that the line terminator is
\r\nis still imprecise; a line begins with\nand ends with\r. Get everything from the\nto the\rand you know you have a full and complete line; if not, you may have an incomplete line. (Of course, you also have to honor quotes and escapes.) Well, that and that it should be\n\r, but that's a different issue. Would you also like to argue the issues involved in the lack of a proper CSV standard? Just five minutes? Or the full half hour? Oh, wait, I also need to mention the superiority of the OpenVMS' file system...Yes, I agree that Google are wrong as well, they should be letting the system take care of EOL - but "modern" software reading line based information from a text file shouldn't care a damn what the line separator is - the system will code (and normally with pretty much anything). You actually have to work hard to decide it isn't exactly what you want and add an error to specifically tell the user that, but then leave out saying what the problem is! :laugh: We've had PC's for nearly half a century now. This kind of crap is just unacceptable in professional software, like failing to check numeric inputs and assuming the user didn't hit a wrong key ... It's like a car designer putting the fuel tank so that the filler neck snapped in a rear end collision (Ford Pinto, 1970-80) in this century. He'd be vilified today!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
Ah, I see you wrote a small application - I used to do that also, when I was still in development. :-D Today, Text editor -> Ctrl+H -> replace "\r\n" with "\n" :sigh:
I still am in development & *I'd* be using my editor (VSCode, where you just click on the 'line ending' item in the status bar and choose LF or CRLF...)
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
While I essentially agree, why blame Microsoft rather than Google? They're actually equally to blame, but Google erred first. Besides, saying that the line terminator is
\r\nis still imprecise; a line begins with\nand ends with\r. Get everything from the\nto the\rand you know you have a full and complete line; if not, you may have an incomplete line. (Of course, you also have to honor quotes and escapes.) Well, that and that it should be\n\r, but that's a different issue. Would you also like to argue the issues involved in the lack of a proper CSV standard? Just five minutes? Or the full half hour? Oh, wait, I also need to mention the superiority of the OpenVMS' file system...PIEBALDconsult wrote:
Besides, saying that the line terminator is
\r\nis still imprecise; a line begins with\nand ends with\r.Actually, the ISO standard 646, and its followers that include ISO 646 as a subset, defines CR and LF as completely orthogonal functions. LF advances the vertical position by one line, explicitly stating that the horizontal position is not affected. CR sets the horizontal position back to the start of the line, explictly stating that the vertical position is not affected. So from an ISO 646 point of view, CR LF and LF CR are equally valid. Also valid is making two blank lines before the following text as [preceeding text]LF LF LF CR[following text]. What gets you to the beginning of a line is the CR. So it would be more correct to say that CR starts the line. If your file contains xxxyyyzzz, it would look like
xxx
yyy
zzz, by the ISO standard. Note that nothing is printed before the yyy and zzz, there are no spaces overwriting previous output, just a change of vertical position. xxx[CR]yyy[CR]zzz would display xxx, yyy and zzz on top of each other. (Whether it appears as a real overprint or as a replacement depends on the physical presentation device.) Whether you call that one line or three lines on top of each other is a matter of definition.
-
Did you know that if you export contacts in Outlook CSV format from Google Contacts, Outlook can't read it? :laugh: No, seriously. And why? Because it's stored with "\n" as the line separator instead of "\r\n" and Outlook doesn't like that, not at all. A windows app (Chrome) writes a text-based file that another Windows app (Outlook) can't read because the line terminator is Windows standard rather than it's preferred format. I thought we killed that in the eighties! Guess what, Microsoft? Excel can read it. Excel reads it fine provided it's got any type of line terminator ... :doh: [edit] OK, it's a trivial change:
string inPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts.csv"; string outPath = @"C:\\Users\\PaulG\\Downloads\\ToConvert\\Contacts\\GoggleContacts2.csv"; string\[\] lines = File.ReadAllLines(inPath); string appended = String.Join("\\r\\n", lines); File.WriteAllText(outPath, appended);but it shouldn't be necessary, not at all ... not this century. [/edit]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
Yes, I agree that Google are wrong as well, they should be letting the system take care of EOL - but "modern" software reading line based information from a text file shouldn't care a damn what the line separator is - the system will code (and normally with pretty much anything). You actually have to work hard to decide it isn't exactly what you want and add an error to specifically tell the user that, but then leave out saying what the problem is! :laugh: We've had PC's for nearly half a century now. This kind of crap is just unacceptable in professional software, like failing to check numeric inputs and assuming the user didn't hit a wrong key ... It's like a car designer putting the fuel tank so that the filler neck snapped in a rear end collision (Ford Pinto, 1970-80) in this century. He'd be vilified today!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
OriginalGriff wrote:
professional software
I thought we were discussing Microsoft and Google?
