I'm trying to get this program to start but I keep getting an error.
I've already tried to make the blockquotes [==[]==] around the string and "" around the program path but it still doesn't work.
local test = string.format([==["C:\Program Files (x86)\Audacity\audacity.exe" "F:\Aufnahme %s.%s.%s\ZOOM0001.WAV"]==], tag, monat, jahr)
print(test)
io.popen(test)
error when running the lua file
If I copy the command from the print(test) and use that in cmd.exe it works.
Thanks for the help :)
On Windows, you must enclose your command line (program + arguments) in additional outer-level quotes.
local test = string.format([==["C:\Program Files (x86)\Audacity\audacity.exe" "F:\Aufnahme %s.%s.%s\ZOOM0001.WAV"]==], tag, monat, jahr)
test = '"'..test..'"'
print(test)
io.popen(test)
When you are typing the command from keyboard in CMD.EXE window, then these additional quotes are added automatically by the code that is processing your keyboard input.
When you're using C function system or Lua functions os.execute, io.popen then you must add additional quotes manually.
This is how CMD.EXE works (and its design is full of not-very-logical decisions).
Related
I've got a very simple rust program but its not doing quite what I'd expect. Running on Windows, using a powershell prompt, I can do the following to display the path:
echo "%PATH%"
and I have a simple Rust program with:
Command::new("echo")
.arg("%PATH%")
.spawn()
.expect("ls command failed to start");
The command will launch and run, but it outputs:
%PATH%
instead of the path contents, like I'd expect. Other commands which don't use special characters seem to work as expected, so I suspect its related to handling them but I don't see a way in Rust to make the command any more primitive than it already is.
I've tried various formatting but it either fails to run the command or does the same.
I also tried using $env:path, but this always fails to run from Rust with a cannot find the path specified error.
Are there any suggestions for handling this? I could write the contents to a file and run the file instead, but running these types of commands from other languages directly works fine so I think it should work from Rust as well.
Thanks!
Update:
Managed to get the expected results from by using:
let out = Command::new("cmd")
.arg("/C")
.arg("echo %PATH%")
.spawn()
.expect("ls command failed to start");
}
I think the question got interpreted a bit differently, as getting the path was just an example of a larger issue I was seeing. Updating with the above solved my larger issue as well.
As the comment by French says: Spawning the process does not include the Powershell-environment, which would expand %PATH% to it's actual content before launching the process.
You need to get the content of PATH via std::env yourself or lookup the Powershell documentation on how to launch a subprocess inside a powershell-session.
As others have mentioned, it's not the special characters, it's the fact that those special characters are interpreted by powershell before the "echo" program runs at all.
Using https://doc.rust-lang.org/cargo/reference/environment-variables.html as a reference for how to look up environment variables, try something like this:
use std::env;
fn main() {
let cur_path = env::var("PATH").unwrap();
println!("Environment is: {}", cur_path);
}
You can try this here: https://play.rust-lang.org/
You can then feed cur_path into your "Command::new" if you wish. The trick is that powershell substitutes that argument BEFORE launching echo, which you may not have known, whereas when you execute the echo program directly, you have to do that substitution yourself.
I have a macro file that i can run in the cmd line in windows by simply navigating to the directory and typing profit.mac in the cmd line
however, when i go to call it in a ruby script i keep getting errors
I have tried system(), exec(), ``, and %x() and i havent been able to get it to work
are there any other options I have to call my macro file?
i get the same error on 3/4 of them
(backticks), profit.mac = (Errno::ENOEXEC)
exec('profit.mac') = (Errno::ENOEXEC)
%x('profit.mac') = (Errno::ENOEXEC)
system('profit.mac') = nothing happens
Are your .mac macros files executables or need to be interpreted by another program?
I guess those macros files have to be interpreted by another "macros executor" program. You would need to prepend that in your command execution.
exec('macrosInterpreter.exe /path/to/profit.mac')
It is like running a ruby script. Assume you want to run a test.rb file. You can't do exec('test.rb'), you would have to do exec('ruby test.rb').
I have created a Windows 7 shortcut in an attempt to give someone who is not comfortable with R the ability to run a simple program. I have tried to follow the advice of other postings, but must be missing something. This is what I have in my shortcut right now.
Target: "C:\Program Files\R\R-3.0.2\bin\x64\Rscript.exe" --vanilla -e "C:\Users\Moo\Desktop\CharCalendar.r"
Start in: "C:\Program Files\R\R-3.0.2\bin\x64"
I get error messages (that flash up very briefly on a black DOS window) that say things like Error unexpected input in "C:\"
I have tried with and without quotes in the target, I have tried using source() in the target (also with and without quotes).
The script runs without error when I submit it in the R console.
You probably want
"C:\Program Files\R\R-3.0.2\bin\x64\Rscript.exe" --vanilla C:\Users\Moo\Desktop\CharCalendar.r
as your target. No -e; that specifies an expression to run, not a script file.
I must admit, I hardly ever made my own shortcut in Windows. However, you coul seemly write a bat-file which runs the R-script and PAUSES, so you can read the output:
#echo off
"C:\Program Files\R\R-3.0.2\bin\x64\Rscript.exe" "C:\Users\Moo\Desktop\CharCalendar.r"
PAUSE
You may also want to add additional options and arguments after Rscript.exe. If you want to pass it to Rgui.exe, it will be a trickier. Read the following stackoverflow-topic for hints:
Passing script as parameter to RGui
Replace Rscript.exe -e with Rterm.exe -f, which indicates that you are passing a file as argument, -e is for passing expressions e.g. Rscript.exe -e "a<-1:10; mean(a);" Rterm provides a few more options for control compared to Rscript, see Rterm.exe --help.
When running a native compilation of gVim under Win7 I have the following in my vimrc:
if has ("win32")
let $TMP="C:/tmp"
setlocal equalprg=tidy\ --output-xhtml\ y\ -utf8\ --wrap-attributes\ 1\ --vertical-space\ 1\ --indent\ auto\ --wrap\ 0\ --show-body-only\ auto\ --preserve-entities\ 1\ -q\ -f\ shellpipe=2>
endif
This should create a temp file. However, after running the command, I see:
shell returned 1
E485: Can't read file C:\tmp\VIoC935.tmp
The common recommendation for native windows E485 errors is to set the tmp variable, which I have, as you can see from my vimrc snippet. If I remove the let statement, I get a similar result:
shell returned 1
E485: Can't read file C:\Users\ksk\AppData\Local\Temp\VIfFA01.tmp
In both cases; both directories exist and gVim can write a file to those locations, i.e.,
:w C:\Users\ksk\AppData\Local\Temp\VIfFA01.tmp
in the current buffer will write this file without error.
Interestingly, while writing this, I found that if I create a new buffer, and delete the original buffer, the equalprg function runs without error (with and without the "let" statement in vimrc)
This doesn't apply to the original question, but I ran into the same symptoms because of the setting of my SHELL variable within gvim. I was launching gvim from a Cygwin window, and it picked up the SHELL setting from within cygwin: /bin/bash. I had to do a ":set SHELL=C:/cygwin/bin/bash" from within gvim, and then the temporary file problem went away. So check the setting of your SHELL variable within gVim (via ":set shell") when trying to troubleshoot this kind of problem.
Interestingly, while writing this, I found that if I create a new buffer, and delete the original buffer, the equalprg function runs without error (with and without the "let" statement in vimrc)
That's probably because you use setlocal in your vimrc
E485: Can't read file C:\tmp\VIoC935.tmp
I know the reason, but I don't know how to fix it without changing indentation options. The issue is caused by the '>' symbol of your indent command, it should work after removing the last part of it or even only the '>' symbol. It's so because '>' has a special meaning in shell commands. In *nix one can probably just escape it, but this doesn't work for me in Windows.
P.S. I know this is not a full answer, but maybe it will help you solve the issue.
Update. Small discussion in the comments discovered that the correct way of escaping is to enclose the last argument in double quotes (the variant 2) below). So the working command is:
setlocal equalprg=tidy\ --output-xhtml\ y\ -utf8\ --wrap-attributes\ 1\ --vertical-space\ 1\ --indent\ auto\ --wrap\ 0\ --show-body-only\ auto\ --preserve-entities\ 1\ -q\ -f\ "shellpipe=2>"
I've got a Windows batch script issue that I'm bashing my head against (no pun intended). The problematic script looks like this:
if defined _OLD_VIRTUAL_PATH (
set PATH=%_OLD_VIRTUAL_PATH%
)
When I run it and _OLD_VIRTUAL_PATH is set I get:
\Microsoft was unexpected at this time.
_OLD_VIRTUAL_PATH is a variable that was originally set from PATH and it contains spaces - I'm pretty sure that's the problem. But what's the solution? It runs successfully if I enclose it in quotes, but I don't think the entire value of the PATH variable is supposed to be in quotes.
Your problem here are not the spaces but rather a closing parenthesis. You are probably running a 64-bit system where the Program Files directory for 32-bit applications is Program Files (x86). In a parenthesized block in a batch file, the closing parenthesis ends the block, so the rest of the line causes a syntax error.
You have two ways to fix this:
1) Put the complete set argument in quotes. This causes the closing paren to not be recognized as end of block:
if defined _OLD_VIRTUAL_PATH (
set "PATH=%_OLD_VIRTUAL_PATH%"
)
2) Don't use a block:
if defined _OLD_VIRTUAL_PATH set PATH=%_OLD_VIRTUAL_PATH%
Well - I never knew about the defined operation in cmd scripts until just now...
Your script seems to work fine for me - which line exactly is producing the error?
You can also try:
if not "%_OLD_VIRTUAL_PATH%" == "" (
set PATH=%_OLD_VIRTUAL_PATH%
)
And believe me, if you're coming into Windows cmd scripting expecting it to be anything like what you have in bash, your head will be very much in pain, very soon. You might want to look into using some other scripting language (PowerShell, Python, PERL - anything) if cmd scripting isn't an absolute requirement. the biggest thing (maybe the only thing) that cmd scripting has going for it is that it's already installed on every Windows box.