Site Navigation
|
|
PGTS Humble BlogThread: Tips/Tricks For Programming etc |
|
 |
Gerry Patterson. The world's most humble blogger |
| Edited and endorsed by PGTS, Home of the world's most humble blogger | |
| | |
Upgrading To Cygwin 1.7 |
|
Chronogical Blog Entries: |
|
| | |
Date: Thu, 11 Mar 2010 22:18:33 +1100Version 1.7 of cygwin has a number of significant changes. When you install it, a little window pops up warning you that it is a "major" release. In not so many words the message implies that you should expect trouble ... And the warning should be heeded. There are several things that can make cygwin 1.7 somewhat less than a smooth and painless upgrade. |
|
On the purely "annoying" front is the little message that is printed in the console when an MS-DOS style path is first encountered. It looks something like this:
cygwin warning:
MS-DOS style path detected: c:/foo
Preferred POSIX equivalent is: /cygdrive/c/foo
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
The grammar in that message is a little imprecise. And if you make the same mistake as I did, you might waste some time trying to add lines to your .bash_profile which attempt to use the environment variables "nodosfilewarning" and/or "CYGWIN" etc. ... But it will all be to no avail!
After scratching my head for a little while, I recalled encountering a Windows environment variable %cygwin%, in a previous incarnation of cygwin. I used to set it to some value in order to modify the behaviour with NTFS and FAT files. The variable had to be set in the grand master script ... cygwin.bat which launches the cygwin shell. If you use a stock standard release with the default pathnames this script will be called C:\cygwin\cygwin.bat. You can edit it with vi as "/cygwin.bat". To turn off those annoying little warnings you need to add a line such as the following, to your cygwin.bat file:
set CYGWIN=nodosfilewarning
Or if you have admin access to your windows workstation, add it to the system environment variables in "My Computer" ... Note: Additional options can be added to the CYGWIN environment variable separated by spaces. There are new options for 1.7 and a few old options have been dropped. And of course, it is all documented. If you want to read more about the CYGWIN environment variable, go to the web page at: http://www.cygwin.com/cygwin-ug-net/using-cygwinenv.html, which is more useful than the URL quoted in the warning message above.
However, more serious than "just annoying" are the problems with "permissions". These really can be show-stoppers if you have lots of applications written as scripts for bash, perl and/or other Unix like shells.
For example, you may find that cygwin 1.7 reports that you don't have permission to copy, move, delete or modify a file when you know for a fact that you really do have permission to carry out the operation! This is especially the case if you have windows shares in the mix. It is very worrying if you have a lot of perl scripts that use the "File::Copy" module. "Copy" and "Move" commands in these scripts might suddenly and inexplicably fail. Some bash commands might (sort of) work but generate errors or warnings which go to STDERR, or they may just fail altogether.
When I first encountered these problems, they were so severe that I contemplated trying to roll-back the upgrade -- Even though I had only installed it on a TEST instance. Then I decided to calm down, take a few deep breaths and do a little investigation and RTFM.
As it turns out, it is not as bad as it first seems. It is possible to upgrade to 1.7 without re-writing all those hundreds of scripts to be POSIX compliant ... Also it is a good idea to upgrade, because Microsoft is continually rolling out updates. As we all know (or at least suspect) those updates aren't all for the benefit of the poorly informed, mooing microsoft herd. ... Many of the changes are just gratuitous, frivolous and or totally unnecessary frills crafted to introduce subtle incompatibilities with previous versions of their own product or anything generated by another operating system (especially Linux) ... But they keep on coming, nevertheless ... So, if your windows team is being diligent about applying patches, it is a good idea to keep your cygwin distribution up to date ... Otherwise your carefully crafted cygwin application could become a lonely island in an unfriendly updated neighbourhood, with a rough road to compatibility.
Here is a list of things that will help navigate the rocky road of cygwin, permissions and ACLs:
-
Hold off for a little while if you can. 1.7 is still quite new. Take a little time to TEST your upgrade.
-
And while on the topic of testing ... Use a test system! Seriously if you have a lot of software running on a Windows server, you should be able to afford a dedicated TEST machine.
-
REBOOT after the upgrade. Even though it doesn't explicitly say to do it. It seems to clear a lot of the cobwebs out the system and cygwin groks the network shares better after the reboot.
-
Read The Fabulous/Fine/Forthright Manual How many times do we have to say it? Especially useful is the page quoted in the "MS DOS warning message" (above) at: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames. Some of the file permissions problems can be fixed by adding and or modifying /etc/fstab. Yes, At last! If you are a Unix (especially Linux) user, you can use /etc/fstab to modify the behaviour or your mounts ... Which is so much easier than fiddling with dangerous, disturbing and poorly documented Windows registry entries.
-
Examine all the permissions on all local mounts. In other words, local Windows drives that are not shared. 1.7 is much stricter about "execute" permissions. If you don't have time to examine them all -- Maybe you could "nuke em" with something like:
chmod -R 777 /foo /bar /data(ugh! Yuck!) Yes, I know that is a very bad programming technique! ... Sloppy, ugly and a potential security hole if a (not nice) cygwin user gets access to your Windows server. But seriously, if a bad guy who is also an experienced cygwin/unix/windows user gets behind your firewall and into your Windows domain you are in a world of hurt anyway ... Quite apart from the fact that if you were really serious about security -- You would not be using Windows at all!
-
Try to be aware of POSIX compliance, going forward. Future scripts should be compliant where possible and when you maintain existing scripts try to make them compliant (without breaking anything).
It will be worth it. Cygwin 1.7 has a lot of bug fixes and improvements. And, as usual, the whole package is tightly integrated. It is much easier to go with the flow and keep the whole distribution up to date.