Steps to Compile and Run Midnight Commander on OSX 10.5

With a complete lack of a "good" commander on OSX (yes it is my opinion and I have run many of them) a few months ago with a fress install of OSX 10.5 installed, I decided to give the old Midnight Commander a try.
I used it a few years ago when toying with linux, but never on a mac. It works, it is fast, it has good keyboard shortcuts (a key feature), but alas after a couple weeks I don't have it installed anymore.

Anyway, today I stumbled across the notes I took as I compiled MC that day and I thought I'd share them here...

Download mc and put in ~/bin/mc . Then start up a terminal and begin the "install" process (don't *nix guys know there are installers for *nix?).


% cd ~/bin/mc
% ./configure


Fails, requires pkg-config (simply invaluable useful little "thing"). Download pkg-config, put in ~/bin/pkg-config .


% cd ~/bin/pkg-config
% ./configure
% make
% sudo make install

% cd ~/bin/mc
% ./configure


Fails, requires GLib.

Download GLib, put in ~/bin/glib-2.12.13 .


% cd ~/bin/glib-2.12.
% ./configure


Fails! requires get-text.


Download get-text, put in ~/bin/gettext-0.17.


% cd ~/bin/gettext-0.17
% ./configure
% sudo make # (takes forever)
% sudo make install

% cd ~/bin/glib-2.12.13
% ./configure
% sudo make
% sudo make install

% cd ~/bin/mc/
% ./configure
% make


Fails! Says:

slsmg.c:76: error: ‘SLtt_Has_Alt_Charset’ undeclared here (not in a function)
slsmg.c:78: error: ‘SLtt_Use_Blink_For_ACS’ undeclared here (not in a function)
make[2]: *** [slsmg.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


So I start fresh with the following:

% sudo make clean
% sudo make


Says:

slsmg.c:76: error: ‘SLtt_Has_Alt_Charset’ undeclared here (not in a function)
slsmg.c:78: error: ‘SLtt_Use_Blink_For_ACS’ undeclared here (not in a function)
make[2]: *** [slsmg.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


Then I google for mc SLtt_Has_Alt_Charset and found www.nabble.com/Compiling-under-OS-X-10.4-got-an-error-t997833.html
Also googled for compile mc on OSX and found http://www.macosxhints.com/article.php?story=20040112172024838 .

Next, I type:

% cd ~/bin/mc/
% ./configure --with-screen=ncurses
% make
% sudo make install
% mc


Horray!!! It works! Remember it requires X11 extensions for OSX. That is a good thing for OSX and a bad thing for running X11 apps on OSX (experience is just lousy for various reasons, especially when using two different keyboard languages). If MC had a Cocoa front-end it would probably be the perfect file manager for osx.

Why Insist on User Stories?

I'm a programmer at heart and in an effort to make the most effective contribution that I can, I've found myself in a Product Management role. As a programmer in this role one thing I have great compassion for is the difference in the what us programmers know (or maybe think) are the highest priority and what is the highest priority to the end-user Product Manager/Owner customer.

Sometimes, especially very early in the development cycle, creating user stories can be challenging. It is easier to put programmer-oriented tasks into the backlog for our upcoming sprint. For example, as programmers we know we need to build the encapsulated, extensible, and testable presentation layer framework (e.g. MVP, passive view or other MVCesque) the communication and serialization framework (web services, REST, or RPC). Obviously these components are absolutely necessary in order to deliver the most essential customer features for our product and are the foundation of the product.

Of course we need that encapsulated and testable presentation layer. The efficient and extensible communication system is needed too. They are important. However, they are the means (implementation details) to the end (customer feature). As we design, build, and prioritize those means it is imperative that we always have the customer at the forefront of our mind. As we determine how extensible to make a class and how that decision impacts the orthogonality of the rest of the subsystem, it is invaluable to never be allowed to stop thinking about the feature or progress that we promised to deliver to our customer.

The point of going through the sometimes challenging process of breaking customer-oriented progress down into user stories is exemplified by a statement made by Alan Cooper:

Moving toward software components is a laudable thing. The problem is that the "componentization" is not based on giving users what they want; it's based on giving programmers what they want. What users want and what programmers want differ dramatically. What makes software easy for humans is not at all easy for programmers. Right now you have toolmakers out there who are creating extremely powerful sophisticated tools that serve programmers but not users.

On the more pragmatic side, another useful statement from Kent Beck is The way I explain it now is that stories don't have to represent business value to the customer team, but they do have to represent progress. Only the customer team knows what it will consider progress, so they have to do the slicing.

"Find in Files" in the *Nix Shell

Another language I'm slowly learning is the *nix shell. It is terribly difficult to learn and terribly powerful at the same time. Its difficulty is the reason it is powerful and its power is the reason it is difficult. As we curse the *nix shell one must remember it was created by programmers for programmers. So the *nix shell does not prescribe to Cooper's (and others') teaching that in software less is more. Anyway, on to the point...

As with most programmers, a common thing I have to do all the time is find a specific piece of text a huge list of files. There are probably hundreds of ways to do this on the nix command line but I've recently realized what I think is the most simple and concise way for my common needs. Assume we need to search all files ending in .cs in all subdirectories of the current one for the text zip. We can do this by entering the following at the command line:

egrep zip `find ./ -iname "*.cs" -type f`

Note that zip is my regular expression (albeit a very simple one) and that find is a command with arguments surrounded on both sides by the grave accent character. Its worth noting that I alias egrep on my machine in my profile to mark matches in color which makes viewing the output much easier.

Now, the only problem with this more simple expression above is that it doesn't work with large lists of files. Instead you need to do a loop like the following to use huge lists of files:

for myfile in `find ~/projects/mySourceDir -iname "*.cs" -type f -print`
do
egrep -H zip "$myfile"
done

In this case I'm doing a loop to pass only one file at a time to egrep. I'm also using a more qualified path to get find to return a fully qualified pathname (I'm sure find can do that a better way, I just haven't figured out how). The -H options just makes sure the filename is printed too. The only thing I have a problem with in the second one is path names containing spaces aren't grabbed by egrep.

While trying to solve a problem with spaces in directory names I found you can use xargs (xargs is a real a gem) to sweeten this syntax a bit more:

find ./ -iname "*.cs" type f -print0 | xargs -0 egrep --color=always -H zip

The trick to solving the spaces in filenames problem is using the -print0 option of find and the -0 option of xargs. -print0 uses null characters instead of spaces to separate file names, and -0 tells xargs to expect arguments to be separated by null instead of space. I added --color because xargs apparently won't use aliased commands (where I added --color=always) and goes directly to egrep instead.

Read about standard input/output streams and command substitution, grep, find, regular expressions, our saving grace xargs, and spend some time trying to let the nix command line spirit flow into your brain, and eventually it will become obvious why all of these things work (and do the same thing).

A 46 Year Old Coal Mine Fire is Nothing

Last night I received a link from a friend to a googlesightseeing page about a coal mine fire currently burning in Centralia Pennsylvania. As he was, I was shocked to learn that it started in 1962 and continues to burn to this day. Started by a trash fire in a landfill that was located in an abandoned strip mine, it has ravaged the area and now only nine of the 1000 residents it had in 1981 are left in this ghost town (look at these before & after pictures of the area). There are no plans to put this fire out and it is estimated that there is enough fuel there for it to burn for the next 250 years! As outrageous as that is, I found even more incredible facts about coal and coal mine fires as my curiosity lead me on a journey through wikipedia and the Internet to learn more...

This 46 year old fire in Centralia, Pennsylvania is only one of thousands of mine fires currently burning throughout the world. In the western United States (the country with the largest recoverable reserves of coal, followed by Russia) such as Wyoming and North Dakota, there are many mine fires. Apparently, they usually start naturally due to a lack of ventilation and cooling which makes coal susceptible to spontaneous combustion. In fact, Lewis & Clark reported wild coal mine fires burning in the west at the beginning of the 19th century! [coal, wikipedia]

China Leads the Pack of Thousands
More coal mine fires are known to be burning in Tajikistan, Turkestan, India, and especially in China. China’s fires alone are estimated to consume 20-200 million tons of coal per year (to put it into perspective, "During the third quarter of 2007, U.S. coal production totaled 285.6 million short tons") and makes up as much as 1% of the global carbon dioxide emissions from fossil fuels [coal, wikipedia]. Some Tajikistan coal deposits have been mistaken as active Volcanoes and are thought to have been burning for thousands of years. Original explorers of Burning Mountain in Australia also thought it was a volcanic, although it too is a coal mine fire. Burning Mountain has been burning for 5500 - 6000 years! This great article at Smithsonian Magazine tells the story of coal mine fires more eloquently.

Coal is not Clean
I also learned that "clean coal" is merely a marketing term created by the coal industry (coal has poisons throughout it, you have to put them somewhere). It is purely theoretical (there is no such power plant in existence and won't be for at least a decade), and is widely believed (1,2) to not be economically viable unless governments subsidize the way they subsidize oil companies. Then I learned that the US government is already subsidizing "clean coal", but in the most prominent $1.8 billion dollar project, the DOE has withdrawn funding from the project after the DOE's share went from the original commitment (by percentage) of $620 million to $1.33 billion after the cost overruns thus far. New subsidies for plain old "dirty coal" were renewed in 2005 too. All worth considering as we go into an election year in the US with most (all?) of the candidates casually insinuating that their belief in investment in clean coal is one of the solutions to our high automobile gas prices (of which I still see no reasonable relation between coal and the price I pay at a gas station).