Cygwin has come a long way … A story in animated GIFs

cygwin_setup
Search is handy for adding new packages to your installation.

First of all, let me say that there is some currency to what the title and pictures imply.

Cygwin/X really has come a long way.  10 years ago, the only viable way to run Cygwin was through a DOS-style UNIX shell. The windows system Cygwin/X provided, such as it was, was  mostly TWM, a primitive window manager which  I used to use, which ran the core programs in the X-Windows distribution. Most  of what came with Cygwin,  such as Gnome or KDE, never worked for me, making me an FVWM2 fan for a long time. Along the way, I appreciated  that while FVWM2 was very stripped-down, it made up for it in flexibility and configurability. Even now, FVWM2 is quite liveable.

cygwin_wait
Postinstall scripts can be a bit of a wait.

I decided yesterday to upgrade Cygwin on one of my older computers,  and after working past some glitches in installation, found that:

  1. If you have your guard down, you may still install packages you hadn’t intended, particularly the TeX language packs for languages and alphabet systems that you know you will never use. Minutes can turn to hours with postinstall scripts running trying to configure these redundant packages.
  2. hacking_keys
    I had this idea of moving my old Cygwin installation to another drive; and it was then I discovered a thicket of permission problems that I had to untangle. This took a lot of work.

    Mate is recent addition to Cygwin, and actually works on my slow system in 2016. In fact, I am using the Midori web browser to edit this blog under Mate in Cygwin/X.

  3. GIMP was once a graphics program you had to compile; now it is intallable for Cygwin as its own package.
  4. When moving my old
    vim_install_github
    Github is the place for a lot of things to round out Cygwin. I was using it to clone source code remotely, then compile and install.

    distribution to another drive, I found a ton of permision problems which were caused by compiling the source for various downloaded code  as another user – not the owner of the directory.

  5. I now have a good system, with much more functionality than ever before. Cygwin has gone from a system that was “mostly broken” to “mostly working” in the space of 10 or so years.green_ninja

Eterm on Windowmaker

This is Eterm, running under X-Windows in Cygwin. The root desktop image is an image of an Emacs Quick Reference, made for the desktop. Nice reason to have a transparency feature on a terminal window.
This is Eterm, running under X-Windows in Cygwin. The root desktop image is an image of an Emacs Quick Reference, made for the desktop. Nice reason to have a transparency feature on a terminal window.

There is always something to have to consider when bringing an app into Cygwin that is not part of the Cygwin distro. I wish to make note of this here in case anyone else has this problem.

Modern window managers are configurable, but only through windows and dialogs. I prefer to configure a bit closer to the metal, so I prefer to edit scripts. The chosen X-window manager was WindowMaker, which is somewhat “modern” while still being nicely configurable, through scripts you can edit under ~/GNUstep/Library/WindowMaker along with graphics files for things such as background images and border tiles. It was nice that WindowMaker still comes with Cygwin, along with FVWM2, another favourite window manager of mine.

I noticed that Cygwin lacked a transparent terminal. You might be thinking that I forgot “mintty”, but I didn’t, since it actually runs as a process directly under Windows, not under Cygwin. Even if I execute mintty from an xterm, the terminal that comes up is not a child of X-Windows, it is a child of MS-Windows, and thus cannot be managed under X-windows.

So, Eterm at first could not compile under Cygwin, and for hours I was racking my brain as to what the problem might be, and looking through the output of the command “configure --help“, I found what solved my problem. What seemed to stop compilation were references to “utmp” and associated header files. The configure script allowed for compilation without utmp support. Utmp is used for access to system logs. This was considered not a big deal in Cygwin, since MS-Windows still has such logs. So my configure command for Eterm was:

./configure --enable-trans=yes --enable-utmp=no

From then I was able to successfully compile Eterm with the eye candy that one associates with the Enlightenment window manager, but under WindowMaker.

BASH prompts: Box-drawing characters

xterm_shot2
An xterm session with BASH prompts containing box-drawing characters. The rest of the screen is the output of repeated fortune commands.

I used to be a big user of xterm’s box drawing characters. I hadn’t been aware that they could be used in prompts.

But I recently heard a (probably dated) discussion on how box drawing characters could be used in a command prompt.

I think that’s a great idea, however, the big problem I found was to do it in a way that correctly turn off the drawing so that you could display text again. Otherwise a lot of text ends up looking garbled.

First, let me say that I used a “twtty” example code at Giles Orr’s BASH prompt website which I modified to allow actual box prompts. A clue was provided in the HOWTO here, where they showed, in a very brief way, the entire “catalogue” of “high-bit” ANSI characters, which I pasted into an xterm:

echo -e "�33(0abcdefghijklmnopqrstuvwxyz�33(B"

The high-bit characters are whatever you type in lowercase after you output the ANSI escape sequence “�33(0“, I needed the echo command (echo -e) to get that to work. The output of echo -e can be stored in a string like this:

local box1=`echo -e "�33(0qqqqqqqqqqqqqqqq�33(B"

�33(0 turns on ANSI escapes, while �33(B turns it off. The string “qqqq”… are the characters used to draw a horizontal line. There were some other tweaks I did to his code to become more complete in box characters for a two-line prompt, but it had the side effect of not going all the way across the screen like the original. Adding six characters fixed it, albeit in a kludgy kind of way:

ESC_IN=`echo -e "�33(0"`  # turn on box-drawing
ESC_OUT=`echo -e "�33(B"` # turn off box-drawing

function prompt_command {
    #   Find the width of the prompt:
    TERMWIDTH=${COLUMNS}

    #   Add all the accessories below ...
    local l="${ESC_IN}l${ESC_OUT}"
    local m="${ESC_IN}m${ESC_OUT}"
    local temp="${l}-(${usernam}@${hostnam}:${cur_tty})---(${PWD})--"

    let fillsize=${TERMWIDTH}-${#temp}+6

What I mean by “kludgy” is that I simply added a “6” on the last line above which controls the number of characters required for the first line of the prompt to go across the screen. It’s unlikely that the terminal width will ever need to be less than 6.

I added two variables which are occasionally useful: $ESC_IN for turning on the ANSI feature, and $ESC_OUT for turning it off. Inside the function prompt_command, I added variables $l and $m since his code uses dashes and I wanted the ANSI horizontal lines instead. $l is for the ANSI output for the letter “l”; while $m is for the letter “m” in ANSI. These generate two corners of the box which occur on the far left of the prompt. And they do join up. The $l is used in the next statement below in the form of ${l} to begin making the string $temp. I could have done something with the dashes in this string such as use “${ESC_IN}qqq${ESC_OUT}” in place of “—“, but there were problems if I was too overzealous, so some dashes were left as is.

The main problem was to get a horizontal line in place of the string “——————————————————” which went on indefinitely. Those were replaced by lowercase “q” letters without the ANSI escapes. These were better placed in a statement nearby:

if [ "$fillsize" -gt "0" ]
then
    fill="qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq"
    #   It's theoretically possible someone could need more 
    #   dashes than above, but very unlikely!  HOWTO users, 
    #   the above should be ONE LINE, it may not cut and
    #   paste properly
    fill="$ESC_IN${fill:0:${fillsize}}$ESC_OUT"
    newPWD="${PWD}"
fi

where $ESC_IN and $ESC_OUT were used in the next statement below the comments. You can’t put them inside the first $fill assignment, because the second assignment cuts off the end including $ESC_OUT should you attempt to do it that way.

Updating or installing Cygwin always a headache

I wanted to update Cygwin, since I was playing around with WindowMaker on another computer, and saw that it wasn’t on my laptop. When I did this, I decided to update latex as well. My advice to those who want to do this, if all you are doing is updating, don’t ever update the font collection. If you select latex as a package to install, the default is to install everything in sight that has anything to do with latex. The update will happen fairly quixckly, but the postinstall phase of latex will take upwards of 8 hours. At any rate, whenever I use latex, I never see what fonts are installed outside of the usual Times Roman, Italic, or Sans Serif. Not altogether sure why all these fonts are needed, since I never see them in any document I edit. Certainly, any attempt to install latex or any of its latex-like couterparts such as LyX must always be accompanied by a de-selection of all fonts you know you will never use, such as, in my case, Chinese, Korean, Japanese, Cyrillic — I don’t speak the languages that would use them, so no point in installing these.

I have heard on many discussion forums that a big reason for the slow postinstall is due to interference with antivirus software. I can say that this does not appreciably affect the (slow) speed of the install, since mine was turned off. I am not sure why the effect of antivirus software would be relevant, since latex does not need an Internet connection to operate. No other software would take this long to install, with or without antivirus software.