I have read somewhere, that the commands entered in the run dialog box are executed as if they are executed using the start command in CMD. Which I believed was the case (as i could executed applications registered at app paths key just by their name using run).
But i noticed a little bit of deviation from this behavior when I tried to run a command on run without extensions. To illustrate this behavior:-
I added .msc and .MSC (i am unaware of extension case sensitivity/insensitivity on windows) to the PATHEXT environment variable, such that it became like this:-
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.msc
After this I executed the following command in CMD, to start the Device Manager:-
start devmgmt
Which lead to execution of Device Manager.
But when i typed in the following command in run dialog box:-
devmgmt
it prompted me with an error stating:-
Well, If my statement in the first paragraph is correct, then why did I ended up with an error in the second case?
P.S.:- Upon googling about this issue before, i read several article which stated run prompt inherits PATHEXT values of CMD, for extension resolution. And if it doesn't, then there exists an policy (in gpedit or something) which makes the run prompt only possess the default PATHEXT values!! (correct me if i was wrong here)
Related
In my directory I have a file called "t1.ps1" and a second file called "t1 - something.ps1".
Both of them run fine when run fine, when executed via right click run with PowerShell or when executed directly in PowerShell, but when executed via double click or cmd it seems to always execute the first script.
For me it seems like the dash is the problem, but I was kinda surprised that windows did not just throw an error or just did nothing, but instead executed a different script.
Maybe this is a well known phenomena or i just have some jank settings, that made this happen, but I was kinda surprised about it.
By default, .ps1 files are NOT executed when you double-click them in File Explorer / on the Desktop - instead, they're opened for editing.
The fact that they are executed for you implies that you modified the default configuration:
However, the fact that double-clicking t1 - something.ps1 executes t1.ps1 instead implies that your configuration is flawed:
Specifically, it suggests that the file-name argument in the underlying powershell.exe command used for invocation lacks (effective) enclosing "..." quoting - as would happen if you had used File Explorer to interactively associate .ps1 files with powershell.exe.
See this answer for more information and a fix.
The application moves files from one directory to another, runs an exe, and then moves files from one directory to another.
When I run the application manually it works as expected.
However, when trying to run it as a scheduled task I get the following error: 3762504530
I did some researching and it appears it may have to do with the application trying to run interactively even when there is no user actually logged in.
I have tried to suppress outputs but that didn't seem to have any effect.
Without seeing the code i guess u use console output or similar...
If so change write-host to write-output or alias "echo" pipe it to log file if u want...
Also be sure that your script run "non interactive" (no prompts etc.)
Unchecking compile a graphic windows program (parameter -noConsole), remedied the error.
I was just curious as to why with Windows O/S a simple Ruby file that prints one line to the command prompt can execute correctly from one path, but not the other.
Currently, I have said file in C:\Ruby193\test\lib saved inside the lib folder. When I go to the command prompt and set the path to C:\Ruby193\test\lib, I'd expect to see the code string be printed to the command prompt. However, nothing but an empty line is produced, and if I go up the path and set it to C:\Ruby193\test and execute the ruby file from there, it works just fine.
Does anyone have a sound explanation as to why it works that way? Would this also be the same case for a MAC O/S as well?
I'm using this new machine, so as usual I go and set the execution policy so that I can use my profile script, after doing that however powershell now opens all batch files in a new cmd.exe window.
I tried undoing this step but it's still the same so I think it has nothing to do with the script execution policy, also I still have the powershell window in which I originally set the execution policy and this one behaves normally, only new windows have this problem.
I may have installed some software, but nothing is related to windows, and I tried setting the PATH variable to its exact value in the working window but it does not work.
Batch files will open in a new window if the PATHEXT environment variable does not contain '.BAT' as one of the executable extensions.
To check the variable, enter the following at the PowerShell prompt: $env:PATHEXT
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.)