I'm trying to parse a few commands to Houdini's Python module called Hython.
And I'm doing this through os on windows.
My command looks like this:
command = '''"c:\\Program Files (x86)\\Steam\\steamapps\\common\\Houdini Indie\\bin\\hython.exe" -c \
"import sys; sys.path.append('d:\\Cloud\\OneDrive\\Dokumenter\\GitHub\\tutorialTools\\utils'); \
import houUtils; houUtils.runReduction(\'%s\',\'%s\')"''' % (assetDir, amount)
os.popen(command)
I've tried all the tricks on quotations I could think of, but I'm getting a :
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes
in position 49-50: truncated \uXXXX escape
Any kind of help would be appreciated
First I tried adding to the command by separate lines:
"command +=" but this stopped me quickly.
I've tried doing the initial path with r'c:\...'
The entire problem seems to be connected with writing paths inside a quotation.
Related
This is basically the same issue as in mingw ld cannot find some library which is exist in the search path, MinGW linker can't find MPICH2 libraries - and I'm aware that there are heaps of posts on StackOverflow regarding the issue of static and dynamic linking with MinGW - but I couldn't find anything that explains how I can troubleshoot.
I am building a project with a huge linker command like (via g++) on MinGW, in a MSYS2 shell (git-bash.exe). The process fails with, among others:
/z/path/to/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lssl
I add -Wl,--verbose to the g++ linker call (to be passed to ld), and I can see for the -L/z/path/to/libs/openssl/lib/mingw -lssl:
...
attempt to open /z/path/to/libs/openssl/lib/mingw/libssl.a failed
...
/z/path/to/libs/openssl/lib/mingw/ssl.dll failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
But this is weird, because the file exists?
$ file /z/path/to/libs/openssl/lib/mingw/libssl.a
/z/path/to/libs/openssl/lib/mingw/libssl.a: current ar archive
(... and it was built with the same compiler on the same machine)?
Weirdly, once it attempts to open with forward slash .../libssl.a, once with backslash ...\libssl.a - but at least the first path checks out in a bash shell, as shown above?
It gets even worse if I try to specify -l:libssl.a -- or if I specify -L/z/path/to/libs/openssl/lib/mingw -Wl,-Bstatic -lssl -- instead; then all attempts to open are with a backslash:
...
attempt to open /z/path/to/scripts/other/build/openssl/build/mingw/lib\libssl.a failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
To top it all off, if I look it up manually through the command line using ld, it is found ?!:
$ ld -L/z/path/to/libs/openssl/lib/mingw -lssl --verbose
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/ssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
Does anyone have an idea why this happens, and how can I get ld to finally find these libraries? Or rather - how can I troubleshoot, and understand why these libraries are not found, when they exist at the paths where ld tries to open them?
OK, found something more - not sure if this is a bug; but my problem is that I'm actually reading arguments from a file (otherwise I get g++: Argument list too long). So, to simulate that:
$ echo " -Wl,--verbose -L/z/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
# nothing
$ g++ `cat tcmd3` 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
... it turns out, if the very same arguments are fed on the command line, then static library lookup succeeds - but if the arguments are read from file through the # at-sign, then static library lookup fails?! Unfortunately, I cannot use on my actual project, since even with cat, I'd still get g++: Argument list too long ... So how can I fix this?
MSYS has special handling of directories as arguments when they are used in the shell. This translates e.g. /<drive_letter>/blabla to the proper Windows style paths. This is to accomodate Unix programs that don't handle Z: style directory root.
What you see here is that MSYS isn't performing this interpretation for string read from a file. When you think about it, it's very logical, but as you have experienced first-hand, also sometimes annoying.
Long story short: don't put Unix style paths in files with command arguments. Instead, pass them through e.g. cygpath -w, which works in MSYS2 (which should be the MSYS that Git for Windows 2+ comes with).
Ok, with some more experiments, I noticed that:
-L/z/path/to/libs/openssl/lib/mingw, the Unix path specification, tends to fail - while if we specify the same, except starting with a Windows drive letter, that is:
-LZ:/path/to/libs/openssl/lib/mingw, then things work - also from an arguments file with # at-sign:
$ echo " -Wl,--verbose -LZ:/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
I guess, since the shell is MSYS2/git-bash.exe, entering full POSIX paths on the shell with /z/... is not a problem, because the shell will convert them - but in a file, there is nothing to convert them, so we must use Windows/MingW convention to specify them...
I am creating a TAR using system command in ruby, passing a array as argument
which look likes this:
cmd_params = ["tar", "-cf", "my.tar", "wp-signup.php_1433243457_25152", "--transform='s/_[0-9]*_[0-9]*$//g'"]
system(*cmd_params)
But getting an Error
tar: Invalid transform expression
is there any way out for doing this ??
The single quotes are needed on the command line or in a shell script to prevent the shell from interpreting the special characters. They're not needed here.
I am writing a Lua script to manage Virtualbox on windows.
It seems that multiple double quotes are not parsed correctly. I am using the following function to implement this:
--Get output from an OS command - http://stackoverflow.com/questions/132397/get-back-the-output-of-os-execute-in-lua
function os.capture(cmd, raw)
local f = assert(io.popen(cmd, 'r'))
local s = assert(f:read('*a'))
f:close()
if raw then return s end
s = string.gsub(s, '^%s+', '')
s = string.gsub(s, '%s+$', '')
s = string.gsub(s, '[\n\r]+', ' ')
return s
end
This code works so long an the machine name doesn't have a space, but machines can have spaces so I have to support them:
local command = '"\\Program Files\\Oracle\\VirtualBox\\VBoxManage\" showvminfo '..key
The following code does not work at all but it does give the correct format of the command to the log file so the syntax should be correct:
local command = '"\\Program Files\\Oracle\\VirtualBox\\VBoxManage\" showvminfo "'..key..'"'
logger:write("[",os.date("%Y-%m-%d %H:%M:%S"),"] Command: ",command,"\n")
vmStateRaw = os.capture(command, "raw")
Log file entry:
[2014-12-06 16:09:18] Command: "\Program Files\Oracle\VirtualBox\VBoxManage" showvminfo "Cerium"
Interpreter output:
'\Program' is not recognized as an internal or external command,
operable program or batch file.
I have found that the following syntax works:
local command = '""\\Program Files\\Oracle\\VirtualBox\\VBoxManage\" showvminfo "'..key..'"'
Log file output:
[2014-12-06 16:27:54] Command: ""\Program Files\Oracle\VirtualBox\VBoxManage" showvminfo "Cerium"
So this question isn't to solve a problem as I have aleady done that. I want to understand why the last command works as my current understand means this should not work.
TIA
The issue has to do with how system in C works. Under windows, system internally calls
cmd /c yourinput
Since os.execute just delegates to system (see here), your command likely ends up executing as:
cmd /c "\Program Files\Oracle\VirtualBox\VBoxManage" showvminfo "Cerium"
For reference, from help cmd:
If /C or /K is specified, then the remainder of the command line after
the switch is processed as a command line, where the following logic is
used to process quote (") characters:
If all of the following conditions are met, then quote characters
on the command line are preserved:
no /S switch
exactly two quote characters
no special characters between the two quote characters,
where special is one of: &<>()#^|
there are one or more whitespace characters between the
two quote characters
the string between the two quote characters is the name
of an executable file.
Otherwise, old behavior is to see if the first character is
a quote character and if so, strip the leading character and
remove the last quote character on the command line, preserving
any text after the last quote character.
Since your command contains 4 double quotes in there, it parses your command with the old behavior. This is why you need to surround your entire command with an extra set of " double quotes.
On my MacBook (OSX Mountain Lion), I used to use this Pandoc command to convert Markdown to PDF:
$ markdown2pdf -N -o pandoc_output.pdf --xetex --toc --template=mytemplate.tex myfile.md
But markdown2pdf no longer works, and --xetex option in markdown2pdf -N -o ../../Desktop/pandoc_output.pdf --xetex --toc --template=mytemplate-headers-garamond_date.tex is deprecated.
If I do this:
$ pandoc -N -o Desktop/pandoc_output.pdf --xetex --toc --template=mytemplate.tex myfile.md
I get this:
pandoc: unrecognized option `--xetex'
But if I take out --xetex and do this:
$ pandoc -N -o Desktop/pandoc_output.pdf --toc --template=mytemplate.tex myfile.md
then I get this:
pandoc: Error producing PDF from TeX source.
! Package hyperref Error: Wrong driver option `xetex',
(hyperref) because XeTeX is not detected.
See the hyperref package documentation for explanation.
Type H <return> for immediate help.
...
l.3925 \ProcessKeyvalOptions{Hyp}
What's the solution?
Try --latex-engine=xelatex instead of --xetex
The prior answers to this question were helpful to me, as I had installed pandoc a couple years ago, but never Tex Live. Consequently I had no idea if I had installed it correctly, so putting in the entire path helped me to see that it was working, as follows:
pandoc --latex-engine=/usr/local/texlive/2012basic/bin/universal-darwin/xelatex
This is the default install location for the BasicTex setup which you download from the Pandoc install page.
I had also forgotten about using pandoc -D Latex >my-latex-template.tex to generate a template. After giving a .tex template instead of my .html one (which caused a 'you don't have BEGIN {' error) , I got .PDF: In other words, the default template worked.
Also, I had inaccurately entered -t pdf (not shown above) to set pdf as an output format, but this was not correct. The output format is Latex, which is then translated to PDF. It is not necessary to specify an output format with the dash -t option.
I hope this record of my minor stumbles saves someone some time.
See the pandoc User's Guide (or man page) for the --latex-engine option.
I am in a search of some way , using which in ruby code I should be able to create a temp file and then append some ruby code in that, then pass that temp file path to jruby -c to check for any syntax errors.
Currently I am trying the following approach:
script_file = File.new("#{Rails.root}/test.rb", "w+")
script_file.print(content)
script_file.close
command = "#{RUBY_PATH} -c #{Rails.root}/test.rb"
eval(command);
new_script_file.close
When I inspect command var, it is properly showing jruby -c {ruby file path}. But when I execute the above piece of code I am getting the following error:
Completed 500 Internal Server Error in 41ms
SyntaxError ((eval):1: dhunknown regexp options - dh):
Let me know if any one has any idea on this.
Thanks,
Dean
eval evaluates the string as Ruby code, not as a command line invocation:
Since your command is not valid Ruby syntax, you get this exception.
If you want to launch a command in Ruby, you can use %x{} or ``:
output1 = ls
output2 = %x{ls}
Both forms will return the output of the launched command as a String, if you want to process it. If you want this output to be directly displayed in the user terminal, you can use system():
system("ls")