I have written a AutoHotkey script that works well uncompiled, but no matter which Base File (.bin) I use to compile the exe in Ahk2Exe, it fails for some unknown reason. Here's the AHK script:
SetTitleMatchMode, 2
WinGet, PID, PID, Anime Studio ahk_class LM_Wnd
Process, Close, %PID%
if 1 && (%ErrorLevel% != 0)
{
Run, %1%
}
And here's how I'm running it, from a Lua script (double-quotes are for spaces in actual paths):
--to uncompiled AHK (working code)
os.execute("C:/Users/JWesley/Desktop/AutoHotkey/AutoHotkeyU64.exe ".."\"".."C:/Users/JWesley/Files/AS/Anime Studio Pro/scripts/utility/ReopenAS.ahk".."\"".." "..path)
--to compiled AHK (not working)
os.execute("\"".."C:/Users/JWesley/Files/AS/Anime Studio Pro/scripts/utility/ReopenAS64.exe".."\"".." "..path)
I'm passing the variable "path" from Lua to the AHK script (%1%). I've tried setting the AHK compiled exe to Run As Administrator, but that didn't help.
path = "C:/Users/JWesley/Desktop/test.anime"
I've tried using os.execute('pause') so that I have a chance to read any command prompt messages, but the first one still closes before the paused one opens.
EDIT: Okay, I got this to leave the prompt open:
os.execute("cmd.exe /k"..'"C:\\Users\\JWesley\\Desktop\\AutoHotkey\\AutoHotkeyU64.exe" "C:\\Users\\JWesley\\Files\\AS\\Anime Studio Pro\\scripts\\utility\\ReopenAS.ahk" "' .. path .. '"')
And got this message in the prompt:
The filename, directory name, or volume label syntax is incorrect.
I found a solution here: os.execute with filename and argument containing spaces Turns out it was more a Lua problem than AutoHotkey, although I'm still unsure why the difference between compiled and uncompiled AHK script. In Lua, I checked if the path had any spaces, and if so:
path = "\""..path.."\""
Then I did:
com = "\"".."type NUL && ".."\"".."C:/Users/JWesley/Files/AS/Anime Studio Pro/scripts/utility/ReopenAS64.exe".."\"".." "..path.."\""
os.execute(com)
Supposedly this keeps the command line from removing the outer quotes, which are necessary with spaces in the path.
Now my only problem is the compiled script running slow due to my anti-virus, but that's a separate issue.
Thanks for the feedback.
Related
What is the windows equivalent to "./filename"
So for example I would usually compile by doing something like:
gcc -c homework1.c
gcc -o homework1 homework1.o
This would give me the executable names homework1
And for me to run the program, I would type: ( ./homework1 ) <-- ignore the parenthesis.
Usually I was write all my code in my schools Unix Shell thingy and I also compile it and run it there, but recently I think I took up all the disc space (because it says "disc quota exceeded").
Run cmd.exe
Go to where the program is example : cd C:\foder1\
Then type the program name with extension, for example : test1.exe or "test1.exe"
In windows (as in Linux) you can either run a program though a GUI interface or from a shell environment.
The GUI option is a program called Explorer, you navigate through the file system and double click executable files to run then. Executable typically have the extension '.exe' or '.bat', but there are others.
The shell environment in windows is called the 'command prompt', you can run it by going to the start menu and selecting 'run' or simply press the windows key and 'r' simultaneously. A box will popup, type 'cmd' (without the quotes) and hit enter - the command prompt should open. From there you can navigate the file system using commands like 'cd'. To run your executable type the name of the file (it should work with or without the '.exe').
A nice shortcut to open the command prompt already at a particular path, is to browse to the folder in Explorer, hold shift and then right-click the folder - the resulting context menu that pops up should have an option like 'open in command prompt'.
I have a windows batch script that just calls vcavars32 for a C compiler, deduces the name of my C program based on the working directory name, saves some content from the user from the command-line, then compiles and runs my program from the commandline (if you know what USACO is, I was hoping this script would help me quickly automate testing).
The script works fine for a while, but after I call it a few times it starts complaining
The input line is too long.
The syntax of the command is incorrect.
And it will stop working, until I close cmd and then reopen a new cmd window.
My batch script right now pretty much looks like this right now (I also have a ton of comments and a few gotos in my actual script to make it a little more convenient, e.g. don't run more > %myFolder%.in if %myFolder%.in already exists):
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\vcvars32.bat"
for %%A in (".") do set "myFolder=%%~nxA"
more > %myFolder%.in
CL %myFolder%.c /nologo && %myFolder%.exe >nul && type %myFolder%.out
del /q %myFolder%.exe %myFolder%.obj %myFolder%.out
Can I get my script to work every time? Why am I getting this error?
Turns out jeb's comment was right on.
It looks like vcvars.bat was adding to path every time it was run, and after a few times, I guess it got too long.
I modified the script to only run vcvars.bat if it hasn't been run yet, and now I don't get that problem anymore.
I am using Windows 7
How can i run an input file (text file of commands) in an exe progam in CMD please.
Using other questions on the site, i have tried:
CMD /c ""C:/Program Files/Mplus/Mpluswin.exe" "C:/Users/jj/Desktop/mplus/test_mplus.inp""
which opens the input file in the program but does not run it
and this, which opens the program, but not the script
CMD /c "C:/Program Files/Mplus/Mpluswin.exe" < "C:/Users/jj/Desktop/mplus/test_mplus.inp"
Does this depend on the exe program?
Edit:
At present, the first command above launches the exe program and opens the text file within it (this is a file of program specific commands that will read in data, run calculations and output automatically). I can then run the commands in the exe program that has been opened (by selecting run in a menu) . But, I would like to pass the file to the exe program and it to be run automatically, ideally in the background. I am not sure of the correct terminology to use, so sorry if my description is unclear.
I've just noticed that you enclosed the entire term in an extra set of double quotes, and used linux forward slashes - try this batch file and also see if there is any error message on the console.
#echo off
cd /d "%userprofile%\Desktop\mplus"
"C:\Program Files\Mplus\Mpluswin.exe" "test_mplus.inp"
echo mplus was launched
pause
How do i launch firefox from perl? i just need to launch the browser so WWW::Mechanize::Firefox can manipulate it. Searching around stackoverflow ive seen a few solutionsl like system('start cmd.exe /k $cmd) where $cmd is arguments to throw as input once cmd is started.
However, these have not helped me to solve my problem at all.
solutions ive tried
system("start cmd.exe /k start firefox");
system("firefox");
system("cmd","start","firefox");
system("cmd start firefox");
Basically a lot of the alternatives ive found, but i could not launch Firefox browser at all.
You're on the right track. Your second line is almost correct. If firefox is not in your PATH environment variable, you need to supply the complete path.
Click on the Firefox icon on your desktop, open the properties and check where the firefox executable is located. Then use that with your system call.
For me, it looks like this (the ' are for Perl's string, the " are for the Windows shell, because the path has spaces in it):
system('"C:\Programme\Mozilla Firefox\firefox.exe"');
You can test it by opening a new command line (win + r, cmd), cding to the directory where your Perl program is run from, and just entering the command:
C:\Dokumente und Einstellungen\simbabque>"C:\Programme\Mozilla Firefox\firefox.exe"
It will not print anything, but just open a new Firefox window after a couple of seconds. So you'd probably need to hold your program execution in Perl while the browser is starting up.
WWW::Mechanize::Firefox will launch firefox for you but you can use
system 1, qq{$ENV{PROGRAMFILES}\\Mozilla Firefox\\firefox.exe}
I'm having a weird problem with running cl.exe that has me stumped. In a large VS2008 solution consisting of C/C++ projects, I have one project that runs some scripts to do some extra processing. The project consists of a pre-build event, which calls a Perl script (ActiveState Perl is on the machine). This Perl script then calls cl.exe with /E to generate preprocessed output which gets redirected to a file. The line in Perl looks like this:
my $foo = `"\path\to\cl.exe" #args.rsp >out.txt 2>err.txt`;
args.rsp is a plain text file that contains a bunch of command line args for cl.exe, including /E to get pre-processor output on stdout.
This exact command line works as expected when run from the VS2008 command prompt. Building the project also works fine on my Windows XP machine. However, on my new Windows 7 box, when I build the project, out.txt ends up blank. I should also add that on some of my coworker's Windows 7 boxes, it works fine, and on some others it doesn't.
Clearly there's some kind of configuration difference going on, but I'm at a loss as to what it may be. We've checked matching versions of VS2008 SP1 and ActiveState Perl. I've tried myriad workarounds within the perl script - using system() instead of backticks, using cl.exe /P to output to a file and then moving the file (the file is blank), unsetting the VS_UNICODE_OUTPUT environment variable (no effect). Nothing has changed the behavior - output is generated when the command line is run manually, but not when it's run inside the pre-build event for this project.
Any ideas on what kind of configuration problem may be causing this? I'm pretty much out of avenues to pursue.
Sounds like an ACL issue to me. You can change windows to log access issues and then check the event log to see what user is getting access denied errors.
I believe the setting is in Local Policy | Audit Policy | Audit Object Access
Wow, the solution to this ended up being a lot stranger than I expected. The machine I'm working on (and the other co-workers who are also experiencing the problem) is a Mac Pro with bootcamp and Windows 7 installed. That causes C: to have the windows drive and E: to have the mac drive. This causes a problem because the pre-build event has a couple lines that test each drive letter to see if there's a drive there, and if there is, adds X:\Perl\bin to the path. Even though E:\Perl\bin doesn't exist, it gets added to the path. Later, the perl script runs and then calls cl.exe, and for some reason, having a directory in the mac drive causes cl.exe to fail. Why? I have no idea. Anyway, removing the mac drive directory from the path fixes the problem!
Thanks for your eyes everyone.
Check out the exit code of your program. You may want to build your executable name in a portable way using something like File::Spec. Also, check that #args is not interpolating. You may want to print your command line before executing to check if that's what you want. What is left your err.txt file?