Re: [Gnu-arch-users] minor extension to arch protocol

[Tom Lord]

    > From: Colin Walters <address@hidden>

    > we're not
    > just talking about bash; specifically I use zsh, and to it '=foo' means
    > $(which foo).  I use the = shortcut fairly often too, so I don't want to
    > just make it un-special.

What about making that ~~foo?   


    > > Yes, I know.  From an engineering perspective, some aspects of
    > > the explosion of interest in GNU/Linux have been destructive.
    > > This is one of them.

    > I don't understand the relation between the interest in
    > GNU/Linux and this issue...

"Back in the day" -- say, about 10 years before you started using
GNU/Linux -- there was still debate about this kind of stuff.   To be
sure, it was at about the level and seriousness of "vi vs. emacs"
debates but the point is that there were still people advocating a
very conserative approach to shell design (and many other aspects of
the unix toolset).   

A lot of the "aesthetic" of the GNU tools was not exactly
"conservative unix".  One way to stereotype them would be to say that
there was a feeling that GNU should try to recreate, as much as
possible, the user experience of operating systems like DEC's TOPS-20
and similar systems.  There were explicitly stated project goals along
those lines (regarding completion, numbered backup files, and on-line
help as I recall).

One example of what resulted from that effort is the readline library
and its completion facilities.

If I recall (with the help of Goggle :-) correctly, the TOPs systems
took a different approach to completion and to command line interfaces
generally.  There were a few "built in" (or specially installed)
commands that the main interface knew about.  So you could type:

        copy <esc>

and the system would complete:

        copy (FROM FILE)

and you could type 

        copy (FROM FILE) foo.tx<esc>

and the system would say:

        copy (FROM FILE) foo.txT (TO FILE) 

etc.  (Those parenthesized words were "noise words" -- they'd be
ignored by the command line parser when you finally hit <enter>.)
Completion also understood about options and so forth:

        copy/<?>

would print a list of the options to the copy command and:

        copy/x<esc>

would complete for whatever option names started with "x".


The routines that did that completion were table driven and available
in a library.  Many applications had this same command processor
"built in" and instead of relying on the shell so much would run their
own command interpreter (sort of like gdb).  A hypothetical mail
reader when run would give you a prompt:

        mail> 

upon reading:

        mail> send <esc>

it would reply:

        mail> send (TO USER) 

and reading:

        mail> ?

would print a list of commands.

There was a help system built-in, too (something roughly like):

        mail> help send

        send (TO USER)

        Compose a message to send to the indicated user.

        Options:

          /cc:USER      send a carbon copy to USER
          /bcc:USER     send a blind carbon copy to USER



I don't know anyone who has used that system and not liked it.  
It certainly makes it very easy to find your way around programs
you aren't familiar with.

It also, though, is not very unixy.   "Conservative unix" likes to use
a single shell for all interaction.   That makes it easy to do things
like construct pipelines:

        ls | sort | grep '.*\.txt' | xargs lpr

but hard to do smart completion, as we've seen here in the arch world:

        % tla commit -A <tab>

uh..... unless you go out of your way to teach the shell about tla,
it can't possibly come up with:

        % tla commit -A (DEFAULT ARCHIVE) 

or

        % tla commit -A (DEFAULT ARCHIVE) address@hidden<tab>
    =>
        % tla commit -A (DEFAULT ARCHIVE) address@hidden


In some sense, the proposed itla framework is an alternative answer to
bash's readline/completion facilities:  like the dec system, it's data
driven not code driven;  like the dec system, you specialize it for
particular subsystems rather than relying on just one top-level
shell.  It's "unixy" in the sense that you can use it to write
applications in two parts:  a unix command-line part (like tla) and 
a fancy command processor for interactive use (like itla).

But anyway, back to why GNU/Linux is in some ways kind of destructive.

As I said, there was a kind of aesthetic that GNU tools should come as
close as possible to the TOPS-20 user experience, yet still be unix.
That's how we wound up with a shell using 'readline', for example.

The conservative reaction to that was pretty much: "That's just bloat.
The shell has no business containing an editor like that.   Besides,
this is never going to work -- the shell isn't going to have enough
information to do the kind of completion you really want.  You're
heading in a bloated, fragile, flaky direction."

And that conservative reaction wouldn't have been wrong.  Look at how
the attempt to "intellegently complete" shell variable assignments
broke the usefulness of some filenames, for example.  Look at how
difficult it's proving for people to write and maintain smart bash
completion code for tla (and, for that matter, how much code it
takes!).  And in that context, why the heck _shouldn't_ zsh specially
define "=foo"; after all, "=" is already broken as a filename
character.

There were similar GNU vs. conservative "debates" (again, more like
"vi vs. emacs" than anything) about things like the number of options
to basic utilities.  The "GNU hello" program is some self parody that
is somewhat a reflection of those old debates.

New generations of GNU/Linux users don't get much exposure to those
old debates.  They enter a computing world in which its easy to become
isolated in a big software monoculture of nothing but (barely
different from one another, at this level) GNU/Linux distributions.
They absorb the GNU approach to "shell user friendliness" that they
find there and just assume "that's how things are done".  What started
off as an attempted GNU innovation, trying to recapture some great
functionality from TOPS-20, has turned into something that obscures
the existence of a real issue, fails to actually achieve its goal,
and, in so doing, it stifles innovation.

(It's interesting to wonder how much of the religion that says "you
need "widget kit GUIs" on everything for non-technical users" is
really just a side effect of the stagnation resulting from bash using
readline as the GNU approximation of TOPS-20's completion facilities.

Non-technical users could use TOPS-20 quite well.   The completion
and help facility made it very easy to teach yourself a new program
and it worked the same in every program.

Obviously graphics are needed for many parts of interaction (e.g.,
consider a spreadsheet, word processor, presentation editor, or web
browser) but there are still plenty of architectural choices within
that constraint.  One possible choice would be to preserve an
essentially command-line-driven framework for writing applications,
adding graphics to that more in the manner of Emacs: as a kind of
"auto-updated picture" of an essentially command-line driven program's
state, the picture doubling as a kind of specialized "virtual
keyboard" for entering command lines with keypresses and mouse clicks.
Instead, we've gone in a direction that makes most GUI programs a
completely different kind of beast from a command-line program.  We've
made an entire industry out of a kind of user interface design and
coding that is, arguably, completely unecessary to the goal of
producing a friendly, powerful, system.   We've latched onto not even
just one but _competing_ toolkits that make writing friendly
applications much more work than is really needed.)




    > >     > If we can fix tagging-method, I think there'd be many fewer
    > >     > complaints.

    > > I'd rather fix the problem than the symptom.

    > But even if we were to fix all existing software (hard) and all
    > existing installations (very hard), why should a revision
    > control system be hardcoding its sorting order preferences?

The use of = in a _non_arch_ file, like "=README" -- _that_ is a
"sorting order preference".   I do use names like that because of how
they sort.   Nobody else is required to do that.

The use of = in _arch_ files, like =tagging-method and =meta-info is
_not_ a sorting order issue:  it's a "namespace partitioning issue".
Those files coexist in directories in which there are also directories
or files named after arch categories.   They _must_ have a name which
is not a valid category name.   Those are the names I happened to
choose.

But anyway, the "problem" I wanted to fix isn't "all existing
software" -- its the question of which part of this nasty interaction
between bash, zsh, and tla users think of as the one worth complaining
about.  And that brings us back to the lack of exposure of most of the
complainers to the issues of "conservative unix" vs. "the gnu
aesthetic".  It's as if programs like bash are now regarded as "carved
in stone and handed down through the ages" rather than "something we
can improve upon."


    > Why don't you (and others who like this) fix your software so
    > that files that are classified as source as according to "tla
    > inventory" are displayed first?  Why should everyone else have
    > to type this = thing when it's useless?

Hopefully you understand why ("namespace partition") the =filenames
that arch generates are not useless.

You might find it quirky that I personally name some other files (like
=README) as I do -- but I don't think that that's what you're really
complaining about.

-t