This is the file I'm searching for on a Windows XP computer
C:\Windows\System32\winlogon.exe
I have displayed file extensions for all files, checked Show Hidden Files, checked Show Hidden System Files, and I can see the file using Explorer but cannot see the file with python. I cannot even see the file using:
os.system( 'dir C:/Windows/System32/winlogon.exe' )
I can see the file by using command prompt by running
dir C:\Windows\System32\winlogon.exe
Python's documentation: "On some platforms, this function may return False if permission is not granted to execute os.stat() on the requested file, even if the path physically exists."
I'd like to use the regular python libraries to be able to do this. I also tried open() command. How do I go about finding this file using Python?
Note: I'm running Python27 under Cygwin in Windows XP. This is because I'm in networking and it's easier to write scripts that run off of Linux, ssh into Windows' Cygwin sshd client, in order to run things.
The issue was that I was using 64 bit Windows with 32 bit Cygwin. Apparently 32 bit Cygwin can only see 32 bit files while 64 bit Cygwin can see all the files.
Source: http://cygwin.com/ml/cygwin/2006-01/msg00444.html
This may be true for all 32 bit applications running on a 64 bit environment. Another reason for many 32 bit applications to upgrade to 64 bit if the applications plan to be run on present 64 bit machines.
Related
I have a few simple BASH scripts, written on a 64 bit version of Cygwin.
I would like to port them them to a 32 bit Cygwin on a different PC.
What can I do to make my code run on both 32 and 64 bit versions? I would prefer code that is agnostic.
Here is what my scripts do :
Takes files from current dir and puts them in a specific directory in the C drive
Takes files from a pre-defined directory from C drive and append them in a single file
The main issue I foresee is the Windows naming scheme (for example, there are two "Program Files" and "Program Files (x86)" folders in Windows).
Other than this, are there any actual CODE or CYGWIN related problems that I may face?
I had never to port scripts from 32/64 or vice versa. Also you could ignore the Programm Files (x86) or not thing.
Porting is important when you have binary code, but not for scripts - except they will do some wired hardware dependend things.
So nothing to port - you could only make your scrpts a bit more flexible for example having parameters for path or detect in which path they have been installed.
I've two Windows machines and both have bash installed. However, they differ in the way bash starts up:
Machine 1:
Typing "bash" starts the bash. Then I can type commands like ls.
Machine 2:
It seems like it starts bash and directly runs ls in it, by only typing "ls". After that it switches back to CMD automatically, like this:
Does anyone know which setting enables the behavior of machine 2? Everything looks the same for me. It's a nice feature and I want to enable it on machine 1 as well.
Bash on Ubuntu on Windows executables (binaries) cannot run from Windows applications such as cmd.exe or PowerShell.exe - Windows doesn't even see them as executable.
The likeliest explanation is that you've installed a separate Unix emulation environment such as GnuWin, which comes with native Windows binaries.
To see the location of your - by definition Windows-native - ls executable, run where ls, which will probably tell you what product it came with, such as
C:\Program Files (x86)\GnuWin32\bin\ls.EXE.
Note that the Ubuntu on Windows binaries are stored in a user-specific manner in
%LOCALAPPDATA%\lxss\rootfs\bin, but that is a moot point, given that you cannot invoke them from Windows.
In Windows 10, there is a built-in Linux subsystem (one of the greatest features of Windows 10). It gives you almost a complete Linux shell for various distributions, and you can almost do anything with it (user mode).
I bet it is installed on your first computer, and you are using that subsystem. In the latest version of this subsystem, you can run both Linux executables and Windows exe files.
I want to install SSH on my PC (windows 7 64bits).
But I have a problem with the installation of libssh2.dll file
I saved in: C: \ Windows \ SysWOW64
and even in C: \ Windows \ System32
and when I execute this command "regsvr32 libssh2.dll" in cmd as administrator I get this error message:
Libssh2.dll "The module" "was loaded, but the DllRegisterServer entry point was not found.
Verify that "libssh2.dll" is a valid DLL or OCX file and try again. "
I downloaded from this site file:
http://windows.php.net/downloads/pecl/releases/ssh2/0.12/
The only good that contains the libssh2.dll is x86 (knowing that I have a 64bits), is what may be causing the problem?
If someone knows a solution, please, share it, it is very important that I find a solution as soon as possible and thank you.
You have to put that libssh2.dll somewhere on the %path% so then the PHP extension can find it. Logic were to put it into your PHP dir (if you use the standard zipball from windows.php.net).
well why have you downloaded a 32 bit file to a 64 bit system
am I missing something here
You can only run a 32bit type if your Apache PHP and MySQL have 32bit running versions or 64 bit in your case. So if you are running a 32bit OS on a 64bit system then this is fine, if you are running 64 bit script on a 64 bit system and are trying to use a 32 bit script which I suspect you are then this is not fine!
I would therefore suggest that if this is the case you may have a mix match of OS Versus Script.
There are a few brave people operating in the 64 bit world and you should only ever use the stable versions of the product and like Apache unless you do you will not get the support you want because you have not utilised a stable version only and Apache will not support 64 bit, hence Apache lounge.
If you are running off localhost or 127.0.0.1, then running a stable 32 bit OS and running the 32 bit stable version is the only way you will get support.
I am working on some legacy VB6 code and I am having my program break with this message:
and it then highlights this code:
I know that the specified locations exist per these screenshots:
I am running this Visual Studio 6.0 on a 64-bit Windows 7 machine. How can I make the program see shell?
command.com does not exist on 64 bit windows.
Try using C:\Windows\SysWOW64\cmd.exe instead. C:\Windows\SysWOW64 is a folder giving you backwards compatibility stuff for 32 bit.
But see the comment below (taken from Euro Micelli).
Really you should use %SYSTEMROOT\System32\cmd.exe instead. First, Windows is not always installed in C:\Windows; you should let the system figure that out. Second, using System32 is always correct for a 32-bit application: when running on Win32, it is the correct folder; when running on Win64, Windows will map %SYSTEMROOT%\System32 to %SYSTEMROOT%\SysWOW64
I use vb6 and windows 7.
I've done the same thing as you but I put the dos command in a bat file.
Login.bat
NET USE W: \\10.48.10.8\e$
Then in the code
Shell ("c:\login.bat")
The vb command is not correct for the OS that you are running. You need to check that that drive is not already mapped, and remove the command.com /c from the command that you are trying to execute.
I am working on Windows 7 64 bit and have a wierd problem. I installed installAnywhere(a 32 bit application) in c:\Programs(x86) since I did not want to install it in the regular "c:\Program Files(x86)" to avoid the hassles of space in directory.
When I attempted to call the installanywhere from command prompt using the syntax:
cmd /c "c:\Programs(x86)\InstallAnywhereEnterprise\build\build.exe" ...
I get the error "c:\Programs" is not a command. The reason being it is attempting to look to installAnywhere in c:\Programs ignoring the (x86) part.
I did some investigation on launching 32 bit programs vs 64 bit programs from command prompt and tried using %windir%\SysWow64\cmd.exe. When I used "%windir%\SysWow64\cmd.exe",
the %programfiles% correctly points to "c:\Programs Files(x86)" but launching the command I mentioned just gives the same error. The FileSystemRedirector of Windows still
keeps pointing to c:\Programs. I reinstalled InstallAnywhere in the default location "C:\Programs Files(x86)" but I dont know why it does not work with "C:\Programs(x86)".
Does anyone know of a workaround?
Escape the parentheses.
"C:\Programs^(x86)\..."
Why exactly are you not ok with putting it in the regular Program Files directory? Space shouldn't be an issue.