Why not install Msvcr71.dll into system32?

Question

TL;DR

I have a snippet of text

str <- '"foo\\dar embedded \\\"quote\\\""'
# cat(str, '\n') # gives
# "foo\dar embedded \"quote\""
# i.e. as if the above had been written to a CSV with quoting turned on.

I want to end up with the string:

str <- 'foo\\dar embedded "quote"'
# cat(str, '\n') # gives
# foo\dar embedded "quote"

essentially removing one "layer" of quoting. How may I do this?

(Initial attempt -- eval(parse(text=str)), which works unless you have something like \\dar, where you get the error "\d is an unrecognized escape in character string ...").

Gory details (optional)

The reason my strings are quoted once-too-many times is I kludged some data processing -- I wrote str (well, a dataframe in my case) to a table with quoting enabled, but forgot that many of the columns in my dataframe had embedded newlines with embedded quotes (i.e. forgot to escape/remove them).

It turns out that when I read.table a file with multiple columns in the same row that have embedded newlines and embedded quotes (or something like that), the function fails (fair enough).

I had since closed my R session so my only access to my data was through my munged CSV. So I wrote some spaghetti code to simply readLines my CSV and split everything up to reconstruct my dataframe again. However, since all my character columns were quoted in the CSV, I have a few columns in my restored dataframe that are still quoted that I want to unquote.

Messy, I know. I'll remember to save an original version of the data next time (save, saveRDS).

---

For those interested, the header row and three rows of my CSV are shown below (all the characters are ASCII)

"quote";"id";"date";"author";"context"
"< mwk> I tried to fix the bug I mentioned, but I accidentally ascended the character I started for testing... hoped she'd die soon and I could get to coding, but alas I was wrong";"< mwk> I tried to fix the bug I mentioned, but I accidentally ascended the character I started for testing... hoped she'd die soon and I could get to coding, but alas I was wrong";"February 28, 2013";"nhqdb";"nhqdb"
"< intx14> \"A gush of water hits the air elemental on the central core!\"
< intx14> What is this, a weather forecast?";"< intx14> \"A gush of water hits the air elemental on the central core!\"
< intx14> What is this, a weather forecast?";"February 28, 2013";"nhqdb";"nhqdb"
"< bcode> n - a spherical amulet.  You are lucky!  Full moon tonight.
< bcode> That must be a sign - I'll put it on! What could possibly go wrong...
< oracle\devnull> DIED : bcode2 (Wiz-Elf-Mal-Cha) 0 points, killed by strangulation on pcs1.nethack.devnull.net";"< bcode> n - a spherical amulet.  You are lucky!  Full moon tonight.
< bcode> That must be a sign - I'll put it on! What could possibly go wrong...
< oracle\devnull> DIED : bcode2 (Wiz-Elf-Mal-Cha) 0 points, killed by strangulation on pcs1.nethack.devnull.net";"February 28, 2013";"nhqdb";"nhqdb"

The first two columns of each row are the same, being the quote (the first row has no embedded newlines in the quote; the second and third do). Separator is ';'.

> read.table('test.csv', sep=';', header=T)
Error in scan(file, what, nmax, sep, dec, quote, skip, nlines, na.strings,  : 
  line 1 did not have 5 elements
# same for with ,allowEscape=T

Solution 1

The main (only?) problem is compatibility between different versions of Msvcr71.dll. Let's say 7.10.0 is slightly incompatible with 7.10.1 and an application App1 depends on the old behavior and an application App2 depends on the new behavior. Additionally both applications do not ship this C++ runtime itself. In this case one of the two applications will fail.

How often are those cases? I don't really know, but I'd say they are seldom.

Depending on the differences between msvcr71.dll versions an application would fail to start or a particular feature would not work.

Another good solution: own PATH for each application. For example, you could write a batch like this:

PATH=c:\PathToMSVCR71.DLL_Version_7.10.0
myapp1.exe

This way you can reuse the same DLL in multiple applications and update it easier.

EDIT It is almost impossible to estimate the danger of a version collision especially as you have not mentioned the applications you use. That is why I have searched for all the different versions on my PC (Windows 7/x64). I have found the following files:

All the files are just copies of these two: 7.10.3052.4 and 7.10.6030.0. 7.10.3052.4 is also what dll-files.com offers.

I have also compared the output of dumpbin /imports /exports msvcr71.dll for these versions and neither exports nor imports have changed (as expected).

Solution 2

"More Information" in the article you linked to says placing the CRT in system32 "may cause problems when you run applications that are linked to a different version of the CRT on computers that do not have the correct versions of the CRT DLL installed."

For example, let's say App1 requires version 2.1 of Msvcr71.dll for its SpinMyRainbowPinWheel function to work. The developers of App1 installed Msvcr71.dll in App1's program files directory.

If you come along and place version 2.0 of Msvcr71.dll in system32, App1 will start using the system file instead of what was installed in its program files directory. The SpinMyRainbowPinWheel function won't work anymore, and you'll gett a call from the CEO because the pinwheel isn't spinning on his monitor when he blows into his microphone. The business comes to a screeching halt!

Comments

[smci]

See also: "How to detect the right encoding for read.csv?"

[mathematical.coffee]

@smci: encoding is not my issue here.

[smci]

Yes it is, although you don't know it. You can fix unwanted escaping.

[GSee]

cat(noquote(str)) comes close

[smci]

If your CSV file also contains arbitrary Unicode or URL escapes, you definitely need to use the right encoding when reading it back in, to avoid nervous breakdowns.

[smci]

Also, use read.csv(...allowEscapes=TRUE)

[mathematical.coffee]

I have tried this. it does not help.

[smci]

txt <- read.csv('escaped.csv', header=T, allowEscapes=T, sep=';') works

[smci]

^^ is your answer, already. By the way you also needed sep=';'

[hillu]

As I stated with the question, my role is not developing the software but making sure that it will run. The DLL in question was not shipped with the system, so I would not replace anything.

[David Harris]

See my GTK example. And you didn't answer why you just can't bundle it, I mean innosetup makes it so easy. Once you have a new version compiled you just press a button and it creates a setup program with all the files you specify and put where you want it.

[hillu]

I am not the author of the software, there is nothing to be compiled.

[mathematical.coffee]

This doesn't solve my problem. It turns \" into " within my string, but does not strip the "" surrounding my string. Even if I manually remove those, what if my string had a legitimate \\" in it, which gets converted to something like \\\\\" (or something bizarre like that)?

[Robert Krzyzanowski]

If your string has a legitimate \\" in it, that will be preserved.

[mathematical.coffee]

encoding is not my issue here.

[smci]

Yes it is, although you don't know it. You can fix unwanted escaping.

[mathematical.coffee]

Cheers. I had hoped to avoid a gsub solution but I'll go with it if I can't find a more general solution...

[smci]

txt <- read.csv('escaped.csv', header=T, allowEscapes=T, sep=';') is the general solution.

[mathematical.coffee]

Please try with the updated snippet, in which case the read.csv solution does not work (I had to find a snippet that reproduced my problem). It appears the issue is with embedded newlines in quoted columns where there are embedded quotes as well within the quoted columns.

[smci]

My earlier comments noting that you only finally gave us a reproducible testcase after 36mins and multiple requests to do so have been deleted. It's important to note this context.

[smci]

All the earlier comments noting that you only finally gave us a reproducible testcase after 36mins and multiple requests to do so have been deleted. It's important to note this context, and why after lots of patience with the question, I'm not inclined to keep answering the latest revision. I object to the behavior that went on in this question, in the strongest terms. You might reasonably apologize both for wasting my time and complaining nonstop.

[mathematical.coffee]

I apologize that I did not provide the appropriate reproducible example in your timeframe, though my original question was specifically "how to unquote a string" and not "how to parse the original CSV properly", hence my original question was reproducible as it stood. (I only updated with the CSV snippet because you wanted to answer the question "how to parse the original CSV", not "how to unquote a string", and I agree I was sloppy with providing the reproducible example there due to not understanding why read.csv was failing. Sorry.) I also note that I did not delete your comments.

[smci]

But your root-cause was reading the CSV - precisely what I told you within 10 minutes of you posting this: it breaks escaped Unicode, URL-escapes. I know this because I solved it in Python two years ago, and I was helpfully offering you that information. "I don't care, give me hackish workaround" is not a gracious response. After all this, your question is still misstated, you need to go edit something in line 1 like: "I get bad strings because I wrote&read in a CSV file the wrong way". The offending string did not just create itself - you did! In future I'll just edit bad questions ASAP

[smci]

...and not wait for the user's consent, while it rains downvotes.

[mathematical.coffee]

My file does not have any special unicode or URLs (oracle\devnull in the example is a literal backslash, not '\d'). I did mention that my strings got that way because I screwed up the CSV. I'm sorry that I even mentioned the CSV, I had only put it in for context (bandaid solution was all I was after). I do thank you for identifying the root cause of my problem. FWIW, I did try to research encodings, but I'm unaware of what encoding will deal with a CSV with embedded quotes and embedded newlines within quoted columns (the contents of those columns are all plain ASCII).