I have Cygwin running on a Windows 7 machine and have the Cygwin ssh server running on it. On Linux I have a shell script where I want to do
ssh myuser#mymachine "qwinsta | grep Active"
to see who is logged in. This worked fine for a Windows Server 2008 R2 machine, but seems to have problems on Windows 7.
If I try this on the Windows 7 machine, I get:
bash: qwinsta: command not found
Now, here is where the weirdness begins...
If I login to the Windows 7 machine normally and look in C:\Windows\System32 with Windows Explorer, I see qwinsta.exe. If I open a CMD session and do a dir in C:\Windows\System32, I see qwinsta.exe. If I open a Cygwin shell and do a ls qwinsta.exe in /cygdrive/c/Windows/System32, I get:
ls: cannot access qwinsta.exe: No such file or directory
If I do a cmd /c dir C:\\\\Windows\\\\System32\\\\qwinsta.exe from the Cygwin shell, I get a "File Not Found"
If I copy qwinsta.exe into my Cygwin home directory, then it is visible in my home directory with ls. If I try to run this local copy of qwinsta from the Cygwin shell, it runs, but it also outputs a line:
{Message(): LoadString failed, Error 15105, (0x00003B01)}
What's up with qwinsta on Windows 7?
The problem is that qwinsta.exe is not actually located in C:\Windows\System32. It is actually found in
C:\Windows\winsxs\amd64_microsoft-windows-t..commandlinetoolsmqq_31bf3856ad364e35_6.XX.XXX.XXXX_none_XXXXXXXX\qwinsta.exe
Using the above path (or a softlink to the same) will run qwinsta.exe as it exists on any machine, and will not require you to copy the executable to your home directory.
The error message {Message(): LoadString failed, Error 15105, (0x00003B01)} is about the Multilinugal User Interface (localization) system not being able to find error message localization information for the program being run (see System Error Codes). In this case, it appears that the cygwin shell does not provide qwinsta.exe with the information it needs to find qwinsta.exe.mui in your language's locale folder (usually C:\Windows\System32\en-US or whatever your locale happens to be). Looking into this folder is somewhat misleading, as explorer will show the file in this directory, but when you run ls /cygdrive/c/Windows/System32/en-US, there is no qwinsta.exe.mui file. I suspect this has something to do with the new linking structure in NTFS (see mklink command), but I haven't figured out how to fix this part of the problem yet.
Solved:
First, go to C:\Windows\winsxs\amd64_microsoft-windows-t..commandlinetoolsmqq_31bf3856ad364e35_6.1.7600.16385_none_851e6308c5b62529
(Copy and pasting that location works just as well as manually finding it.)
You should find three files: Msg.exe , Quser.exe, and qwinsta.exe .
Copy these files to your C:\Windows\system32 folder
Next, go to C:\Windows\winsxs\amd64_microsoft-windows-t..etoolsmqq.resources_31bf3856ad364e35_6.1.7600.16385_en-us_7bef78d9f4a6a8ac
You should find three similarly named files, except these will end with .mui.
Copy all three of these files to your C:\Windows\system32\en-US folder.
Now try running the msg program. It should work without issue.
Windows 10
Following on from Erutan2099's answer, for Windows 10 it's a little trickier, since the files are compressed (binary delta compression, file signature 44 43 53 01). Trying to use them as is throws an Unsupported 16-Bit Application error:
The program or feature "\??\C:\Windows\System32\msg.exe" cannot start or run due to incompatibility with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available.
A specific tool has been made to decompress such files: SXSEXP (this post pointed me in the right direction)
Usage:
> sxsexp64.exe msg.exe expand\msg.exe
Processing target path msg.exe
msg.exe => expand\msg.exe
File size 12602 bytes
DCS_HEADER found.
NumberOfBlocks 1
UncompressedFileSize 26112
DCS_BLOCK #1
Block->CompressedBlockSize 0000312A
Block->DecompressedBlockSize 00006600
Operation Successful
> sxsexp64.exe msg.exe.mui expand\msg.exe.mui
Processing target path msg.exe.mui
msg.exe.mui => expand\msg.exe.mui
File size 2150 bytes
DCS_HEADER found.
NumberOfBlocks 1
UncompressedFileSize 7680
DCS_BLOCK #1
Block->CompressedBlockSize 00000856
Block->DecompressedBlockSize 00001E00
Operation Successful
These decompressed files can now be copied to C:\Windows\System32 and C:\Windows\System32\en-US respectively.
Example:
> msg * Hello, World!
Related
I have a Windows machine with the current user in C:\Users\User.
I have an executable in another drive, let's say at D:\Folder\MyProg.exe.
Opening command prompt, it starts in the directory C:\Users\User
I type the command: start D:\Folder\MyProg.exe or D:\Folder\MyProg.exe
The exe fails to open, with a pop-up: MyProg has encountered an error
In order to run start the .exe from command prompt, I have to cd to the other directory and then start the exe.
Opening command prompt, it starts in the directory C:\Users\User
I type the command: cd /d D:\Folder && start MyProg.exe
The exe successfully opens.
Is there a better way to, from C:, start an executable in another drive?
Reproducing
Windows 10 Pro, v1809 (I don't think the version really matters)
My real use case is industrial automation, but one can observe the same result with convert.exe (cnet download link)
As commented by #Mofi, I realized the answer is most likely this:
But some programs are not good coded. Such programs depend on files in directory of the program and do not use appropriate code to reference those files from within the program with program files path, but use instead a relative path
As he instructed in the next comment, start provides a /d parameter that lets you specify a startup directory. Thus, a concise command would be:
start "" /d D:\Folder MyProg.exe
Note: the "" is for the <Title> field. The .exe I am opening is a GUI application (not a console application), so it is not necessary in this case, I just included in case other viewers find this useful in their application.
I have a Windows machine with the current user in C:\Users\User.
I have an executable in another drive, let's say at D:\Folder\MyProg.exe.
Opening command prompt, it starts in the directory C:\Users\User I type the command: start D:\Folder\MyProg.exe The exe fails to open.
In order to run start the .exe from command prompt, I have to cd to the other directory and then start the exe.
Maybe not. Try:
PATH D:\Folder;%Path%
"D:\Folder\MyProg.exe"
Windows doesn't allow you to give files reserved names, such as con. However, WSL doesn't place any such restriction.
Creating a file called con produces an error: 'The specified device name is invalid.' Creating one with
touch con
in WSL does not produce any error, but then deleting it from Windows Explorer produces an error: 'Invalid file handle.' However,
rm con
in WSL deletes it without issue.
What is going on here? Why does WSL create a file with a reserved name without errors?
Windows blocks these file names from using them completely.(if e.g. you accessed a directory C:\CON\CON in an old windows version, you got a bluescreen)
So, you cannot access/create/delete them with cmd or explorer(It does not matter in which drive).
Howewer, the Filesystem does not block it. Because of this linux(maybe because something runs in the Windows Kernel?) shell emulators like git bash or wsl (I did not test cygwin) can create/access/delete these files even in the bootable Windows Partition.
I'm using Windows 7, and my problem is running this file from a console (cmd.exe):
W:\software\projects\myproject\build\msvc\build.bat
When I move into the folder containing the file manually and run it from there using the following command sequence, it works:
W:\>cd software
W:\software>cd projects
W:\software\projects>cd myproject
W:\software\projects\myproject>cd build
W:\software\projects\myproject\build>cd msvc
W:\software\projects\myproject\build\msvc>build.bat
However, when I try to run the file from the root directory in any of these ways:
W:\>software\projects\myproject\build\msvc\build.bat
W:\>call software\projects\myproject\build\msvc\build.bat
W:\>#call software\projects\myproject\build\msvc\build.bat
W:\>"software\projects\myproject\build\msvc\build.bat"
W:\>call "software\projects\myproject\build\msvc\build.bat"
W:\>#call "software\projects\myproject\build\msvc\build.bat"
I get the following error message:
The system cannot find the path specified.
I'm pretty sure you didn't have to navigate to the folder containing the file in order to run it when I was using Windows XP (though I could be wrong, of course), but this apparently seems to be the case with Windows 7. Or am I missing something?
You are correct. You do not need to navigate to the batch scripts folder before executing.
The error "The system cannot find the path specified." is most likely caused by something inside your batch-file.
Try to add
cd W:\software\projects\myproject\build\msvc
w:
or in a single command (as suggested by James K, Thanks!)
cd /d W:\software\projects\myproject\build\msvc
Searched a bit more and found this generic solution:
cd /d %~dp0
at the top of your batch file to set the working directory to the directory of the script to check whether this is the cause.
If you execute your file from W:\ this is where the commands are executed (working directory). It is most likely that your script cannot find some file it uses in this location.
I am trying to run the program nbtstat.exe(located in c:\windows\system32) from a ruby script. The problem is that it appears that Windows 7(64-bit) is hiding the program from the ruby script(it works fine in Vista).
For example,
Nbtstat command: "nbtstat"
Dir command: dir "C:\Windows\System32\n*.exe"
If I run the nbtstat command in just the command line, nbtstat will run fine. If I then run the dir command, nbtstat.exe will show up in the list of files in that directory.
However, if I run the nbtstat command from the ruby script(using backticks, system, %x or Kernel.open), it will not succeed. If I then run the dir command(also from the ruby script), it will show a list of files in the directory minus nbtstat.exe and a few others.
UAC is turned off and it is being ran from an administrator. I tried this in both ruby 1.8.6 and 1.9.2.
I created a .bat file that runs the nbtstat command and it worked fine but if I call the .bat file from the ruby script it will fail.
Any ideas?
Thank you.
On Win64, if you run a 32-bit process, Windows will remap the c:\windows\system32 directory to actually point to c:\windows\syswow64. That directory doesn't contain the binary you're looking for, so your 32-bit process doesn't see it.
You can detect whether that's the case by looking at the process's environment (look at the output of "set" for the env variables), although I don't know of a way to make the process see the actual 64-bit directory.
Maybe the shell in which your ruby script is launched was created before the PATH is initialized. I noticed this issue in Windows 7. You can try to print PATH in your script to verify if you are encountering this issue.
I have installed ActivePerl on my Windows OS. I have followed below URL
procedure to install
ActivePerl Installation
After having done that, I have tried to run "perl -v " on the command line. But it reports the following error.
The system cannot execute the
specified program
What do I need to do to solve these issues?
I was facing a similar issue... but the thing was that I could execute the file by right clicking the file and opening it with perl command line interpreter.... but still the perl-v command would give the error... all I had to do was execute this command
set PATH=C:\Perl\bin;%PATH%
This solved the issue...
You need to make sure the directory where the Perl executable lives (it might be C:\perl\bin, but basically wherever you told ActiveState Perl to be installed) is in your PATH environmental variable (you can find the variable value by typing set PATH command on command line prompt in Windows).
If you're not sure where you installed Perl to (and can't find it in the default C:\perl\bin), you can find the directory by going to Start menu, finding ActiveState Perl folder, and right-clicking on "Perl Package Manager" icon, then pick "Properties" from the right-click menu. Properties window (in the "Shortcut" tab) will have a "Target" line showing the directory.
I was getting a similar error after installing ActiveState Perl on Windows 8 x64 bit edition and trying to invoke 'perl' at the command line.
'perl' is not recognized as an internal or external command, operable
program or batch file.
I remember selecting the option during installation to add the Perl directory to the system PATH environment, and after checking the system properties, it was indeed showing in the system PATH.
I tried installing 'Microsoft Visual C++ 2008 x86 and x64 redistributable setup' files as suggested by a few places but it still did not resolve the issue, until I tried some of the suggestions in this thread.
At the command prompt I entered:
set PATH
And surprisingly it did not list the Perl directories as being included in the PATH variables.
So to remedy that I entered this into the command prompt and hit enter:
set PATH=C:\Perl64\bin;C:\Perl64\site\bin;%PATH%
(The directory paths are for the 64 bit edition of Perl, adjust according to your installation) the %PATH% portion is important and ensures your existing settings are kept and not wiped out and overwritten when you set the PATH.
That fixed it and entering 'perl -v' into command prompt successfully replies your Perl version. If you had a PowerShell window open before setting the PATH variable, you will need to close it and re-open another instance of PowerShell.
I believe the original underlying issue was something to do with different PATH variables for 32-bit and 64-bit environments and possibly some internal Windows redirection that takes place automatically.
This doesn't sound like a problem with PATH - I would expect it to give the message 'perl' is not recognized as an internal or external command, operable program or batch file.
I have not seen this error message, but http://nirlevy.blogspot.com/2008/03/system-cannot-execute-specified-program.html makes some suggestion for related programs.
Or maybe ask on an Active State forum.
I had the same error. I was able to solve it by changing the order of the Perl64 entries in the PATH variable in the Environment Variables. I moved the C:\Perl64\bin to be before C:\Perl64\site\bin and it worked.
I had a similar error which was solved by adding the .pl extension to the script name, which I had forgotten to do.
I could not get it to work otherwise even with my Perl's location (C:\Apps\Perl\bin) verified as in %PATH%.
The problem lies in the installation directory.
The Perl PATH variable will be set to C:\Program Files\perl (depends on 32 or 64 bit of course), BUT, the default installation directory is C:\perl. This is kind of sneaky actually as you would assume the installer would be more intelligent about this, but it sets the environment variable to that directory no matter WHERE you install the damned thing.