Warning: this is an htmlized version!
The original is across this link,
and the conversion rules are here.
This is the `doc/EEVMANIFESTO' file GNU eev.
I published this originally on the web - in December 1999 - without
any notice of copyright... maybe it will need one now, so let's go:

  This file is in the Public Domain.

Author: Eduardo Ochs; version (of the headers): 2005jan05
Latest version: <http://angg.twu.net/eev-current/doc/EEVMANIFESTO>
      See also: <http://angg.twu.net/eev-current/README.html>
                <http://angg.twu.net/eev-current/>



The eev Manifesto
=================

I)

Do you remember your first Unix days, when you were always asking
yourself questions like "how do I compile this?", "how do I install
this stuff?", "and now, how do I run it?", "how do I generate html
from this file?"?

Do you remember how you marvelled at the first time you ran a "make"
on a package and you saw echoed each of the commands that were used to
generate binaries and docs from the source? Have you had the same
feeling I've had, that by understanding those commands we would have
access to the tricks that the owner of the package knew, and that we'd
learn which were the "important" programs and in what way the experts
used them?

II)

Everybody is fluent in only a small fraction of all Unix commands. If
you could "listen" to how the Unix gurus "speak" to their machines you
would learn which "words" are related to solving a particular task,
and learn how they fit in "sentences". By checking the "dictionary
entries" for them (i.e., manpages, info pages, READMEs, source code,
etc) you could learn the real meaning of them. But then you'd be
learning Unix by immersion, from real use, instead of having to rely
only on "textbooks", "dictionaries" and sometimes "Rosetta stones",
"graffitis on toilet walls" and "old newspapers".

The fact is that you can make a record of how you "speak" Unix, and
more, you can become a lot more productive if you do so. Many tasks
consist on short fixed sequences of commands: connecting to your ISP
via modem, unpacking a source package and recompiling it, printing a
text file in two-column mode, and so on. The trick is that with some
functions defined in eev.el you can write these sequences of commands
in a plain text file, then mark a block of this file with your editor
(which must be Emacs for this to work), then tell a shell to execute
only the commands in that block; in this way you can easily execute
only portions of what would otherwise have to be a monolythic script;
this is great for when you're not sure if everything works, or if you
just want to do some steps. Also, it would be easy to change bits of
the "script" before execution, as you'll be doing things from inside
an editor.

There is also another trick. Scripts allow "comments", that is, lines
that are not executed; generally the convention is that lines that
start with "#" are comments. So we can place lines like these in a
script:

  # (find-enode "Picture" "C-c c-c")

The expression "(find-enode "Picture")" is an Emacs command (in Lisp)
that means: open the "info page" called "Picture", from the Emacs
manual, treating it as a file; then place the cursor after the first
occurrence of the string "C-c c-c" there. To execute this command,
i.e., to make emacs go to that point on that page, you just have to
put the cursor after the ")" and type C-x C-e. There are many other
similar commands, that will open specific files or specific manpages,
with various ways of searching. These "hyperlinks" are especially
interesting if you want to record from where you got some piece of
information relevant to the "script" you're writing; this is very
useful, for example, on "scripts" you haven't finished and on which
you plan to work more someday, or on scripts you want to send to
someone.

Just as hyperlinks have many flavors, the function that executes a
block also has variants: a block can be executed by the Tcl
interpreter instead of the shell, or can be run through LaTeX, just to
pick some examples. See the docs on eev.el
(<http:/angg.twu.net/eev-current/README.html>).

III)

I have placed essentially all my "scripts" written in this way (I call
them "e-scripts") in a public place (<http:/angg.twu.net/e/>). They
contain almost everything I know about Unix.

If you like this idea, please get in touch, send comments, ask
questions -- about e-scripts or questions whose answer could become an
e-script chunk -- or send me your e-scripts when you have some, or
even ask for help on setting up your own e-script collection or
e-script public site... anything! By asking good questions you can
help me make the documentation get better.

I really want to make this e-scripts idea spread. Learning Unix -- or
simply more Unix -- could be made easier for everybody... please help!
E-scripts are more fun to use, and easier to write, than texts that
tell everything in terms of "press this, do that". A lot of effort and
money are being invested now on these kinds of text, and they're often
very depressing. Let's try to save the world from them, at least a
bit, and maybe this money will be directed to better things. And
teaching people Unix tricks will be both easier and more fun.

Eduardo Ochs, 1999dec18.

eduardoochs@gmail.com
See: <http://angg.twu.net/eev-current/README.html>