I'm trying to compile a resource file (.rc) for a Win32 application but I'm getting this error
use "" to put " in a string
Among other things, I'm trying to define a MENUITEM with a string that looks like this "&Save\t\"Alt+S\"". I have tried escaping the " character with "\"" but it still doesn't work.
Why are you escaping it with \" when the resource compiler clearly says you that you must escape it with ""? Just do:
"&Save\t""Alt+S"""
Related
I did this
-Dserver.address=hostname -I|cut -f5 -d ' '
in configuration, in "VM Options"
but I got Error
Unrecognized option: -I|cut
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
I need help, please
The reason you get the unrecognised option error is because you use spaces in your JVM argument. You will need to enclose it with quotes. The official JVM docs say:
-Dproperty=value. Sets a system property value. The property variable is a string with no spaces that represents the name of the property. The value variable is a string that represents the value of the property. If value is a string with spaces, then enclose it in quotation marks (for example -Dfoo="foo bar").
So in your example that should be something like:
-Dserver.address="hostname -I|cut -f5 -d ' '"
However I'm not 100% if you are able to use a command as a value. As far as I know it can only be a 'static' value.
am triggering SQL loader from a python script (2.7);
The password does contain an # sign. If I call sql loader from the command line and escape the password (username/\"p#ssword\"#database) the process works. However, when I apply what I believe is the same logic within a python script I get an error:
SQL*Loader-704: Internal error: ulconnect: OCIServerAttach [0]
ORA-12154: TNS:could not resolve the connect identifier specified
Since I can run the same command in the cmd prompt successfully, I don't believe this is an issue with the TNSNAMES.ORA file containing any incorrect or missing parameters. I'm pretty confident this is an issue with calling SQL loader from the subprocess command and the escape characters.
Python Logic:
subprocess.call("sqlldr userid=" +config.ddw["user"] + "/\"" +
config.ddw["password"] +"\"#" + config.ddw["connection"] + "
control=C:/projects/controlFile.ctl log=C:/logFile.log)
If I print this statement the string looks like:
sqlldr userid=USERNAME/"p#ssw0rd"#connection/db
(2.7)control=C:/projects/controlFile.ctl log=C:/logFile.log
When I load the string directly in the command line it works:
sqlldr userid=USERNAME/\"p#ssw0rd\"#connection/db
control=C:/projects/controlFile.ctl log=C:/logFile.log
You need those double-quotes escaped so sqlldr sees them. I don't know python, but it appears you need to change that code to make sure you get a backslash in front of the double-quotes. You may need to escape the backslash too since it is most likely a special character.
Perhaps something like this?
subprocess.call("sqlldr userid=" +config.ddw["user"] + "/\\"" +
config.ddw["password"] +"\\"#" + config.ddw["connection"] + "
This is a SWAG so your mileage may vary a little :-)
I've been trying to write a function for my bash profile for quite some time now.
The problem I'm trying to overcome is I'm usually provided with file paths that include spaces and it's a pain having to go through and escape all the spaces before I try to open it up in terminal.
e.g.
File -> /Volumes/Company/Illustrators/Website Front Page Design.ai
What I'm trying to end up with is '/Volumes/Company/Illustrators/Website\ Front\ Page\ Design.ai' being opened from my terminal.
So far I've managed to escape the spaces out, but I then get the error "The file ..... does not exist."
My code so far is
function opn { open "${1// /\\ }";}
Any help would be very much appreciated.
The important thing to understand is the difference between syntax and literal data.
When done correctly, escaping is syntax: It's read and discarded by the shell. That is, when you run
open "File With Spaces"
or
open File\ With\ Spaces
or even
open File" "With\ Spaces
...the quoting and escaping is parsed and removed by the shell, and the actual operating system call that gets executed is this:
execv("/usr/bin/open", "open", "File With Spaces")
Note that there aren't any backslashes (or literal quotes) in that syscall's arguments! If you put literal backslashes in your data, then you cause this to be run:
/* this is C syntax, so "\\" is a single-character backslash literal */
execv("/usr/bin/open", "open", "File\\ With\\ Spaces")
...and unless there's a file with backslashes in its name, that just doesn't work, giving the "file does not exist" error you report.
So -- just call open with your name in quotes:
open "$1"
...there's no need for an opn wrappper.
Spaces are problematic in filenames because they're part of bash's default IFS (Internal Field Separator), which is used to separate tokens in a command line. That means that by default, when you use command an argument with spaces, the command will receive 4 arguments rather than 1 containing spaces.
I'm guessing you called your opn function in the same way, thus resulting in only the first part of your path as $1.
Hopefully, the fix is easy : enclose your path in quotes so that bash does not interpret the spaces. By using this, the need for your opn function disappears : open "/Volumes/Company/Illustrators/Website Front Page Design.ai" should work just fine.
I'm looking a way to compile Ruby code on OSX. I am using MacVim, and my code says:
puts "test"
I type rubydo %, and I get an error message SyntaxError: eval:1: unterminated quoted string meets end of file. What am I doing wrong?
Vim's rubydo command executes a command. You may have thought it was a filename (and used "%" as the parameter, i.e., the current buffer). The % is ruby's alternate string delimiter, and depending on how rubydo is implemented, the bare "%" could be mistaken for the beginning of a string.
The % Notation (Ruby Programming)
Vim documentation: if_ruby
I tried to create a package using some functions and scripts I created (using X11 on a Mac). While R CMD check was doing its work, it encountered a problem as follows:
temp = trim(unlist(strsplit(lp.add(ranefterms[[i]]),
+ "\+")))
Error: '\+' is an unrecognized escape in character string starting "\+"
The oddest thing, however, is that my function actually does NOT have "\ +". Instead, it has "\ \ +" (see below). So I don't know why "\ \ +" is recognized as "\ +".
for(i in 1:n)
temp = trim(unlist(strsplit(lp.add(ranefterms[[i]]), '\\+')))
To dig a little further, I looked at the packageName-Ex.R file in the Rcheck folder. As it turned out, all the "\ \"s have been changed to "\" in the checking process (e.g., the double slashes I need for functions such as strsplit() and grepl())
I wonder what may have been the cause of it. Sorry that I can't come up with a reproducible example...
The offending code comes from the Examples section of one of your help files (which is why it ends up in packageName-Ex.R). To fix it, just escape each of the backslashes in the Examples sections of your *.Rd documentation files with a second backslash. (So, type \\to get \ in the processed help file, and type \\\\ to get \\.)
Unless it's escaped, \ is interpreted as a special character that identifies sectioning and mark-up macros (i.e. commands like \author, \description, \bold, and \ldots). Quoting from Duncan Murdoch's Parsing Rd files (the official manual for this topic):
The backslash \ is used as an escape character: \, \%, { and }
remove the special meaning of the second character.
As an example of what this looks like in practice, here is part of $R_SOURCE_HOME/src/library/base/man/grep.Rd, which is processed to create the help file you see when you type ?grep or ?gsub.
## capitalizing
txt <- "a test of capitalizing"
gsub("(\\\\w)(\\\\w*)", "\\\\U\\\\1\\\\L\\\\2", txt, perl=TRUE)
gsub("\\\\b(\\\\w)", "\\\\U\\\\1", txt, perl=TRUE)
In the processed help file, it looks like this:
## capitalizing
txt <- "a test of capitalizing"
gsub("(\\w)(\\w*)", "\\U\\1\\L\\2", txt, perl=TRUE)
gsub("\\b(\\w)", "\\U\\1", txt, perl=TRUE)