"The problem posed in Futurist architecture is not one of linear
rearrangement. It is not a question of finding new moldings and
frames for windows and doors, of replacing columns, pilasters and
corbels with caryatids, flies and frogs. Neither has it anything
to do with leaving a fašade in bare brick, or plastering it, or
facing it with stone or in determining formal differences between
the new building and the old one. It is a question of tending the
healthy growth of the Futurist house, of constructing it with all
the resources of technology and science, satisfying magisterially
all the demands of our habits and our spirit, trampling down all
that is grotesque and antithetical (tradition, style, aesthetics,
proportion), determining new forms, new lines, a new harmony of
profiles and volumes, an architecture whose reason for existence
can be found solely in the unique conditions of modern life, and
in its correspondence with the aesthetic values of our
sensibilities. This architecture cannot be subjected to any law
of historical continuity. It must be new, just as our state of
mind is new."
Antonio Sant`Elia, 1914
mpsh was written for my own use. I needed it. If anyone else finds a use for it, that's a nice bonus. It's really an experiment to see if a few shell features I had in mind are actually useful in normal day-to-day usage.
There are a number of mpsh features that I think are genuinely good, and should be adopted by other shells. There are a few features which are nice, but not particularly compelling. And then there are the Set Theory features, which are just insane. I have found uses for them, and hopefully there are a few people out there who will find even better uses for them, but most people will justifiably shake their heads and ignore them.
As Lou said:
"Most of you won't like this and I don't blame you at all. It's not meant for you."
The primary feature that I wrote mpsh to experiment with is the job handler.
The general idea behind the job handler feature was inspired directly by VMS's DCL. In DCL, many things that seem to the user to be related, but are completely unrelated in how they run internal to the system, are presented to the user in a consistant fashion. For example, these DCL commands obviously have nothing to do with each other, as they are actually carried out by the system:
$ SET HOST GAMMA $ SET TERMINAL/VT100 $ SET PASSWORD $ SET DEFAULT SYS$LOGIN:
In the Unix world, those commands roughly translate as:
$ telnet gamma $ TERM=vt100 $ passwd $ cd $HOME
Not that I want to change those commands to be similar, but I do think it's a bad thing that the following are so different:
$ a.out & $ echo a.out | submit $ rsh gamma a.out
Traditionally in Unix, depending on what you want to do, you execute a command by typing it directly, by using it as an argument to another command (ex: rsh), or by using it as stdin to another command (ex: at). mpsh lets you use the same basic syntax for all of those methods, with an option at the end of the command to specify how the command is to be handled. So you think about the task you want acomplished, and the method is an afterthought.
Depending on how you've configured things, the above three commands could be:
mpsh$ a.out & mpsh$ a.out &s mpsh$ a.out &g
In terms of writing mpsh, my mantra throughout development, whenever I ran into a difficult problem, has been:
A lisp programmer could do this, therefore so can I.
I tried very hard to keep both the design and the implementation clean and simple. Frequently problems have been overcome simply by repeating the mantra, stepping back from the problem, and trying to find a more elegant path forward.
As mpsh is written entirely in K&R C, obviously I consider good software design a matter of attitude and discipline, rather than a question of sophisticated language features.
The primary mpsh development machine is a Sun E3500 running Solaris 8. (In 2015. Really.) Porting is done on an Origin-2000, a Raspberry Pi, and an assortment of laptops.