In Lua os.execute(command) can be used to execute command using the device specific shell (Command Prompt on Windows). So, as expected, running os.execute("calc") opens the calculator. What I have noticed though, is that if I try to execute msg (a program in windows in system32), os.execute prints "'msg' is not recognized as an internal or external command,
operable program or batch file.", even though if I try to execute msg on a normal command prompt it succeeds (displays help and usage info). Also, msg is an actual executable, and not some alias or command prompt keyword. And if I use Lua to open a command prompt os.execute("cmd"), and then use that command prompt to run msg, it still fails.
Does anybody have any idea what might be causing this problem?
I have Lua 5.1.5 installed on my Windows 10 computer.
EDIT:
Here's what happens when I run "C:\Windows\System32\msg.exe" on a Command Prompt:
C:\Users\%username%>C:\Windows\System32\msg.exe
Send a message to a user.
MSG {username | sessionname | sessionid | #filename | *}
[/SERVER:servername] [/TIME:seconds] [/V] [/W] [message]
username Identifies the specified username.
sessionname The name of the session.
sessionid The ID of the session.
#filename Identifies a file containing a list of usernames,
sessionnames, and sessionids to send the message to.
* Send message to all sessions on specified server.
/SERVER:servername server to contact (default is current).
/TIME:seconds Time delay to wait for receiver to acknowledge msg.
/V Display information about actions being performed.
/W Wait for response from user, useful with /V.
message Message to send. If none specified, prompts for it
or reads from stdin.
Here's what happens when I do the same thing with Lua:
> os.execute("C:\\Windows\\System32\\msg.exe") --I just escaped the backslashes
'C:\Windows\System32\msg.exe' is not recognized as an internal or external command,
operable program or batch file.
Also, if I use Lua to call dir to list files in sys32, msg.exe does not appear in the list
SOLUTION:
As it turns out, because I'm running 32-bit Lua on 64-bit Windows, when I tried accessing sys32, I was actually accessing syswow64. What I still don't understand though, is why syswow64 was missing some files ...
Related
I'm at my wits end here. This is what I get when I type "echo %PATH%" into cmd:
C:\Users\user>g++
'g++' is not recognized as an internal or external command,
operable program or batch file.
C:\Users\user>echo %PATH%
C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\Wind
owsPowerShell\v1.0\; C:\MinGW\bin\;C:\Users\user\AppData\Local\Programs\Python\P
ython39\Scripts\;C:\Users\user\AppData\Local\Programs\Python\Python39\;C:\Users\
user\AppData\Local\Programs\Microsoft VS Code\bin; C:\MinGW\bin\;
C:\Users\user>
I've tried everything. Of course i'm using new cmd instances to check. Restarting doesn't work. I can go to the C:/mingw/bin directory and open g++ just fine with cmd once there. I've tried all the different formatting with the PATH variable: The 'C:' part, semi colon at end, backslash at end. No permutation works. You can see in the output above that both my user and system path have the correct directory for g++.
UPDATE: Ok I just tried updating only one user/system path at a time. I get the 'This app can't run on your PC dialogue' (windows 8.1) and at returns 'access denied' now. But when I run the cmd as admin it works!
But still VScode returns
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Cannot create temporary file in C:\Users\user\AppData\Local\Temp; C:\MinGW\bin\g++.exe\: Invalid argument
now
I've got a simple exe application that writes in a file the first argument with which it gets called, so from command line I can do
MySimpleApp.exe "FOO"
and in the SimpleFile.cfg I get "FOO".
If I try to run this batch (it's in the same folder of the app)
set mypath=%~dp0
%mypath%MySimpleApp.exe "FOO1"
%mypath%MySimpleApp.exe "FOO2"
%mypath%MySimpleApp.exe "FOO3"
every time MySimpleApp gets called Windows ask the administrator permissions to execute the app. I thought that I could just run the batch as administrator, but even if I get no UAC prompt the application doesn't execute.
Is there some option or command that I must use to call an exe file when the batch is launched in administrator mode?
Filenames with spaces MUST be enclosed in quotes.
Always tack a pause at the end of a batch to see how it is interpreting your commands. And likewise if using Echo Off turn it on. Hiding information from yourself about YOUR error is not wise.
So
C:\Users\FirstName LastName\Desktop>C:\Users\FirstName LastName\Desktop\MySimpleApp.exe "FOO3"
'C:\Users\FirstName' is not recognized as an internal or external command,
operable program or batch file.
I am trying to open notepad on remote machine using WMIC command
C:\Users\raj.kamal>WMIC /node:192.168.0.104 process call create 'cmd.exe /c notepad.exe'
ERROR:
Description = Access is denied.
I am already logged on to remote machine but I don't why this error is coming.
When I try to pass username and password using WMIC Command, it throws "Invalid Global switch" error.
WMIC /username:Raj /Password:"Dummy D" /node:192.168.0.104 process call create 'cmd.exe /c notepad.exe'
Can anyone suggest how to handle this error?
I think insteas of /username should be /user. Then use:
If password is literally "Dummy D" including surrounding double quotes:
WMIC /user:Raj /Password:"Dummy D" /node:192.168.0.104 process call ...
If password is literally Dummy D without surrounding double quotes but with a space:
WMIC /user:Raj /Password:Dummy^ D /node:192.168.0.104 process call ...
To be honest, I don't know how to spell a password containing a space character (ASCII 0x20) as a command line parameter - neither in CLI nor in a batch script.
Although I don't like the word impossible, this is the case...
More in excellent Christopher84's comments on passwords and spaces. Summarizing: "As a general rule, do not try to put spaces into passwords! Same goes for usernames, computernames and other unique, human readable identifiers".
You can't run programs with a GUI on remote machines.
From Help
The Create WMI class method creates a new process. A fully-qualified path must be specified in cases where the program to be launched is not in the search path of Winmgmt.exe. If the newly created process attempts to interact with objects on the target system without the appropriate access privileges, it is terminated without notification to this method.
For security reasons the Win32_Process.Create method cannot be used to start an interactive process remotely.
I'm curious why commands like "start iexplore" and "start firefox" work in Windows cmd.
They're not standalone commands. If you try to type in just "firefox", you'll get:
"'firefox' is not recognized as an internal or external command,
operable program or batch file."
This leads to the conclusion that this is a special behaviour of the "start" command.
My first guess was that it works in a similar way to how the %path% variable is used, having known directories to search in.
I ruled it out easily by trying to run "start [executable]" for another executable located in the same directory as firefox.
My conclusion is that somewhere on my computer there's a list of designated file paths, that can be started by simply typing their file name after the "start" command, instead of the entire path.
Imagine the potential of being able to add things to this list..
Anyone knows where I can find it?
It is in the registry
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\
Under this key there are defined applications that can be invoked without need to change the path environment variable.
Usual invocation (typing the name in the command line) will not search inside this list, but call to start command, windows Run dialog or call from anything that uses the ShellExecute or ShellExecuteEx API calls, will check for applications defined in this list.
I am running Windows 7x64 and Excel 2010x32. I call 32bit dos programs (written in Fortran) via vba using ExecCmd (a Microsoft function that waits for a command prompt process to finish). I send a command line to this function that explicitly contains the program path and the paths of the input file and output file.
This runs fine on my PC and also on a company PC running the same software (OS and Office) and for which I have general access to the C: drive.
On other company PCs, where there is not general access to the C: drive, this does not work - i.e. the dos programs do not produce an output file. On these PCs, I can still run the program at the command prompt manually. It is just that calling this command prompt does not work via Excel VBA.
Now the strange thing is that I can successfully run one of these programs by adding "cmd.exe /c" at the beginning of the command line. That would appear to be running a command prompt within a command prompt (!). The other program (which, incidentally, is quite a bit bigger) does not work at all via vba on these PCs. I need to be able to provide other employees with something that works.
Can anyone shed some light on what is happening here and suggest a work around? I could past some code, but I think the above should be self explanatory.
You're confusing the command shell with the console window. In this context, the distinction is critical.
Console-mode programs (aka "command-line programs") require a console window to provide input and output. When a console-mode program is launched from a GUI program, Windows automatically creates a console window for it (unless instructed otherwise).
The command shell (aka "Command Prompt") is cmd.exe, a console-mode program.
The important point here is that not every console window has an instance of cmd.exe running in it. When a console-mode program is launched from a GUI program, Windows automatically creates a console window but does not automatically create an instance of cmd.exe. If you want to pass a command to cmd.exe you have to do so yourself, or use a run-time library routine that does it for you.
ExecCmd does not do this; it runs the program directly. So passing cmd /c <command> to ExecCmd is not "running a command prompt within a command prompt" at all. Without the cmd /c you aren't running a command shell command, you're just launching an executable.
There are any number of reasons why the command you're passing might need to be given to the command shell. For example:
it might be a built-in command like dir or type which only exists within the command shell;
it might include redirection or pipelining operators, or environment variable substitution;
it might be a script rather than an executable.
There are other cases. If you show us the command line being passed to ExecCmd we may be able to provide more specific advice. (The fact that the same command line is apparently working on some machines is puzzling, but can't be addressed without more information.)