On a fresh 32-bit cygwin install onto a 64-bit windows 7 machine,
somehow sh.exe became a child node inside these two areas (or subtree
areas) in the registry:
HKEY_CURRENT_USER\Software\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags
Causing it to require elevated permission to run. Each time I ran
sh.exe manually, or via a script with /bin/sh shebang, even after
several fresh installs, it popped up the user account control question
asking for elevated privileges to run sh.exe. If you say yes, it opens
in its own new console window. If you say no, you get permission denied.
The data for the key in each case seemed to hint that it was marked as
having to run it with elevated privileges, or in windows xp
compatibility mode. By deleting both keys, normal functionality was
restored. I'm sure I didn't ask for that.
How it got this way is unknown, I had tried the 64-bit cygwin but
couldn't do without clisp. Deleted, reinstalled 32-bit cygwin and it
wouldn't work for the reasons above. Tried 2 more times, same thing.
Since it lived beyond fresh installs, I finally tried searching the
registry for "sh.exe". I removed the keys referencing sh.exe inside the
areas listed above. Then things wouldn't run from emacs-w32 due to
vfork problems and popen failure, so I had to ash rebaseall then all was
well.
Shot in the dark, but it might have to do with me trying BitDefender
free antivirus which actually blocked an exe I freshly compiled, so
since it was really blocking too many Cygwin things I went to AVG free.
So I'm sending this mostly as a reference of how I fixed it in case
someone else runs into it. Could be a narrow failure case under just
the right set of conditions with Cygwin as the victim and some
third-party software as the culprit.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
