Thoughts on Perl and Emacs, technology and writing

Enablers and Obstructors

A tail about the Windows Unix shells and MSYS path mangling

I am aware of three libre "Unix" shells on Windows, Cygwin (bash), MSYS (bash) and the shell that comes with UnixUtils (zsh). Out of all of these, only the MSYS shell mangles the paths. And sometimes, even though it can be surprising, path mangling is a good thing.

I believe the heuristic that is used is that native MSYS apps use unix style paths and other apps use windows style paths.

Larry Wall – An Enabler

I really like Larry Wall. He didn’t decide ahead of time how people were going to use Perl. He provided the various features, observed what people were doing with them and then made it easier to do typical tasks. He enabled useage that he hadn’t necessarily foreseen.

[With Perl], I was trying to encourage what I call diagonal thinking. Traditionally computer languages try to be as orthogonal as possible, meaning their features are at all at right angles to each other, metaphorically speaking. The problem with that is that people don’t solve problems that way. If I’m in one corner of a park and the restrooms are in the opposite corner of the park, I don’t walk due east and then due north. I go northeast — unless there’s a pond in the way or something.

I am told that when they built the University of California at Irvine, they did not put in any sidewalks the first year. Next year they came back and looked at where all the cow trails were in the grass and put the sidewalks there. Perl is designed the same way. It’s not just a random collection of features. It’s a bunch of features that look like a decent way to get from here to there. If you look at the diagram of an airline, it’s a network. Perl is a network of features… It’s more like glue than it is like Legos.

Counter example – An Obstructor

Contrast that with Keith talking about a proposed feature for MSYS 1.0.12 in this post. (Emphasis mine)

I agree that there is a need to do something, but if I’m understanding you correctly, you propose implementing some sort of environment variable hook, which will switch path name translation ON or OFF globally? IMO, that simply will not cut the mustard. If path name translation is globally OFF, then MSYS will be emasculated, becoming nothing more than a limited clone of an obsolete version of Cygwin; might just as well ditch it, and use current Cygwin instead.

For me, the principal reason to choose MSYS over Cygwin is the automatic path name translation feature. Take that away, and MSYS is dead; I will use Cygwin instead. (Except, of course, that you make it optional, so I keep the path translation turned ON, and entirely ignore whatever effort you invest in providing the option).

No, we do not need a global method of disabling path name translation…

Who is we referring to here? I would find a global method of disabling path name translation useful for two out of the three uses I have for a Unix shell on Windows and I don’t imagine I’m unusual:

An tool for building libraries or executables from a tarball

A superior interactive alternative to cmd.exe.

A superior alternative to cmd.exe for writing batch scripts.

And I’m not thrilled about needing to install cygwin just to get a usable shell. Fortunately, there is an alternative. I can set up zsh from UnxUtils to use the MSYS executables and at a pinch it can provide a reasonable facimile of bash.

One word of warning: although this works fine on Windows XP, on Vista, even with XP compatibility enabled it sometimes crashes with a c:/home/jared/.zshrc: fork failed: no error [48] error. When this happens, sourcing zshrc manually with . ~/.zshrc works.