Cygwin’s (many) downsides

Hits: 54

Cygwin is a free (as in freedom) open-source suite which tries to be a POSIX-based subsystem that runs on top of MS-Windows. It tries to behave as if it can do all tasks that Windows can, as if it were a wrapper for Windows. But essentially, even with an X-Window manager, it ends up being just another windowed application with windowed apps running inside it, which can be minimized so you can actually work with MS-Windows itself when you want to.

I wish to say at the outset that this is more of a review than anything. There is a lot of important info missing to construe this discussion as a how-to manual for un-installing or fixing a Cygwin system after a Windows reinstallation. If it were such a manual, this article would have to be much, much longer. In reality, I am really just venting frustration as to how Cygwin, a “program” (for lack of a better word) which I have been using for over a decade, is still very far from getting its act together.

An Eterm, running under WindowMaker. Yes, I was using the EMACS Cheat Sheet as wallpaper!

It has been a hobby of mine to make something of this subsystem for some years, and I have found it most useful as a programming environment. It has as much support for perl, python, C/C++ and vim as you like, and can even run windowed file managers, web browsers (among them, chromium, and lesser known ones like Opera and Midori), and editors like XEmacs. It has wide support of the standard window managers, such as GNOME, KDE, xfce, lxde, fvwm2, enlightenment, WindowMaker, right down to twm. And because all of this runs in a glorified window under MS-Windows, I can switch back and forth to and from MS-Windows whenever it suits me.

If Cygwin doesn’t have the packages for a “free” (as in beer) computer language, I found I can just install a Windows version of it under Cygwin, and that is fine. All Cygwin executables are “exe”, just like Windows, so I can also run Windows commands under a Bash shell. I wanted the latest Java from the Oracle website, and I found I was able to just unpack it somewhere, under, say, /opt, and link its executables to /bin or to any directory defined in my $PATH. Or, of course Java provides a “bin” directory which you can add to your $PATH without the need for making symbolic links.

All tickety-boo if you can get Cygwin up and running. Most applications ported from other unix systems will work if you recompile from source and run the configure script. Others will compile and install after some minor editing.

The downsides of Cygwin are apparent from the point of installation. When you first install Cygwin, the installer is somewhat cryptic, although you might be able to figure most of it out. The installer allows you to decide what packages you want and which ones you don’t. But it is really an illusion. If you want stuff such as your window managers to work on Cygwin, including your chosen X-Window manager, then just install everything. Maybe decide which window manager (or managers) you want and which ones you don’t want. I also was picky about the texmf language packs, which slow down the install to over 6 hours, so I do take the trouble to deselect most texmf language packs that are not English or which don’t use the “Latin” alphabet, while choosing any math or other academic fonts. Being otherwise indiscriminate about package selection means you have to live with scores (or possibly hundreds) of programs and window managers you will never care to use. My installation is typically about 26 gigs unpacked, spanning over 1 million files (1,017,806 files, to be exact) in some 65,000 folders. That is not counting my /home folder.

Another thing to know is that Cygwin has no uninstall tool to uninstall itself. So un-installation of Cygwin is infinitely more difficult than installation, for reasons we shall see.

I said earlier I found the installer cryptic. What I mean is that the installer has to download and install each package one at a time, which is a bugger if a remote server goes down or hangs. And, especially with those texmf language packs it appears to hang, when in reality it is just plain being slow. If you stop the installer and start it again, you get no indication of whether it remembered where it left off. What you do is behave as if it does remember, and click install. It does pick up from where it left off, but it is not very reassuring about it.

And God help you if you, for some reason need to reinstall MS-Windows. This is where you find when you go back to the directory with the installation, that it has introduced its own permissions, but that is not the worst permission problem. The ownership of the distribution becomes hard to untangle, in large part because when you reinstall MS-Windows the user and admin accounts you created become reduced to SID numbers of users no longer known to the system. And of course, you can remove those unknown users with Windows’ Properties, and reassert your ownership similarly, or by using the “takeown” and “icacls” commands which their cmd shell provides (running as Administrator). This takes hours when the number of files is over 1 million with 65,000 folders. This is slowed down further by the fact that there are several files and folders which have un-knowable permissions and un-knowable ownership which require you to change tactics when that happens. After an evening and the following morning, I was able to get rid of the now-bogus users while respecting other owners as much as possible. Using the inheritance option in MS-Windows has to be done judiciously, respecting that different folders have differing sets of system permissions. Some have no system permissions (just user and group permissions), while others have strange ones like “Creator Owner”, “Creator Group”, “None”, and “NULL SID”.

Some examples of strange “users”. “Everyone” isn’t considered strange, and includes all users on your system.

If you are able to untangle the Cygwin permission problems after re-installing MS-Windows, then congratulations! You are now at a point where you can decide two things: 1) you can still configure an icon to run a shell under mintty and content yourself with a bash shell as a reward for your work on permission changing; or 2) you can delete the entire Cygwin directory tree and decide if you want to reinstall again. Both prospects are hard-won, and here you are. I wish to emphasize that option 2 is not a joke. Deletion would have been impossible without taking ownership and fixing the permissions. It just sounds like a joke.

Notice that there is no choice “3” for trying to run X-Windows or a window manager. X-Windows will complain one way or another about not being able to find :0 (the root window), or will give an X window briefly, which crashes in seconds with no error message logged. Some X apps work, such as the aforementioned mintty, but except for shell commands, that’s it. If you wanted to run an application that needs any of the X-windows widgets, then you have to delete the whole thing (except possibly /home) and install from scratch. In other words you are basically screwed in all but the bleakest of ways if you reinstalled MS-Windows.

Over the years there had been several reasons for reinstalling. Sometimes it was to freshen a windows installation which was becoming increasingly sluggish and full of problems. “Freshening” a windows installation involves, for me, a formatting of C: drive. This is not so bad for me. Only programs and system files go on my C: drive. My documents and other files are on other physical hard drives. My Cygwin installation is also situated on one of the other physical drives, so it doesn’t take up valuable room on C:. So, I don’t feel as nervous about reinstallation as some would; but there is that darned Cygwin distro I have to reckon with sooner or later. You are screwed if you sort out the permissions under Cygwin, and screwed even more if you don’t.

This is /etc/fstab in its entirety. The edited line on the bottom contains the “noacl” option needed to fix this file permission bug.

As a post script, I found out how you get NULL SID, as well as incorrect ordering of permissions on many of the Cygwin files, the source of the majority of my permission headaches. The /etc/fstab has just one uncommented line, a filesystem called “none” allowing all of your Windows drives to be herded under /Cygdrive. This is supposed to have the advantage of allowing you to navigate to any physical drive or partition on your computer entirely within Cygwin (which is what it does). A missing option needs to be added: “noacl” (quotes omitted). This prevents Windows from trying to assign a user SID as if “none” was a user, thereby fixing many of the permission headaches.

I don’t understand why the designers of Cygwin don’t add “noacl” before they distribute it. I think the majority of us are running some form of NT-based windows system: Windows 2000, XP, 7, 8, 10, and now 11 are packaged with most computers these days, and their hard drives are usually NTFS. These bugs are specific to NTFS systems, and these bugs don’t show up on FAT-32 filesystems, which don’t store info on ACLs, SIDs, or anything of the sort.

The Cygwin website discusses these issues, but it seems that Cygwin is trying to be POSIX compliant when Windows obviously isn’t trying to be. If they are choosing MS-Windows as the host system, they will have to do things their way and not try to fight it with Cygwin’s “correct” way, or to disenfranchise the majority of their users for the sake of backwards compatability. Would it kill the owners of FAT-32 filesystems, whom I think are in the minority, to delete “noacl” for the sake of the majority? Once the system is installed it is too late to do it then, since by then the installed apps will all have the permission bug.

In the event you decide you wish to delete the whole shebang after hours of sorting out permissions, there is one little tiny file that completely thwarts nearly all attempts at deletion. I have found it on two of my installations, and it was a problem in that specific file. It is the file located at /usr/share/avogadro/crystals/zeolites/CON.cif, relative to the Cygwin top-level folder. It cannot be deleted, and its permissions and ownership cannot be changed or even known to humans. The reason Windows appears to go braindead with this file, is because of the filename. CON is a reserved word in MS-Windows, short for “console”, going back to the days of MS-DOS. So is naming your file LPT1, short for “line printer”, a Windows reserved word with the same MS-DOS heritage. You can’t delete it with anything in Windows, so you need a POSIX tool, like, ahem, Cygwin, to affect the deletion.

So I deleted CON.cif using my later installation of Cygwin, and I was thus able to delete the entire directory tree as a result. More to this issue is: what happens when you need to delete CON.cif and have no intention of reinstalling Cygwin? Stack Exchange has a whole discussion on this which makes my long story even longer, so I will end my article here.

Not knowing what to do with my psh

Hits: 31

psh, or the Perl shell, is supposed to be, among other things, a kind of “immediate mode” for perl code segments, as well as a way of injecting Perl commands and syntax into other shells such as bash.

It is always a bit ambitious at the best of times, to install anything from source into a Cygwin installation. Cygwin lacks much of the trappings of a full UNIX installation, which is understandable, having to run on top of MS-Windows. But Cygwin does support X-Windows and subsequently big-ticket window managers like Mate or Gnome, and also Java when you unpack it. It supports GCC, perl, and many of your other favourite open source languages.

The source for psh was downloaded from GitHub, and I downloaded the ZIP file for it in an empty directory.

I had to install psh as root (actually admin, because Windows), before running it with my joeuser account. When it ran, I observed that it actually re-ran the incumbent shell, and really had no actual shell of its own that would result in its own prompt style.

For all of the rest of its behaviour, it seems to be a bash shell (my default shell). Entering some perl commands appeared to just be ignored, such as something like “my $i=10; print $i*5;”

But then I tried to do an ls in my home directory in the following way:

ls -al | s/p/Q

and as predicted it turned all occurrences of p to Q in the file listings. I tried to pipe ls through s/[pP]/q, but that didn’t work for me. So if I wanted to turn both upper and lowercase from p or P to Q, I would require a second pipe:

ls -al | s/p/Q | s/P/Q

This might be somewhat understandable, but I tried this on my Cygwin installation (on a native Perl interpreter, not just a shell, and s/p/Q changed both uppercase and lowercase p. [pP] is a sed/vi convention that specified a substitution upon detection of any letter inside the square brackets, in this case, p or P. I normally use that thinking as a shorthand for not needing to know all of the Perl string handling parameters. It the kind of thing that enamoured me to perl in the first place, due to its low learning curve if you already know how to use sed or the substitution commands in vi, both of which are pretty much the same as each other.

So, it looks like psh could be a good testbed for experimental commands or interesting shell scripts, but its actual usefulness is incubment in how well its output and behaviour matches up with your native perl installation.