From: ski8032@tamsun.tamu.edu (The Man Behind The Curtain)
Subject: Re: The Problem with UNIX
Organization: Texas A&M University, College Station
Date: Mon, 16 Nov 1992 19:57:33 GMT

Thus spake so@brownie.cs.wisc.edu (Bryan S. So):
>I am doing research on UNIX command line interface problems.
>I am sure everyone has his/her favorite UNIX troubles, would
>you post or email me what's your favorites?  What should have
>been done by UNIX to resolve that problem in general?
> [..]
>To start the discussion, consider the following problems:
>
>    cat a b > b

Or tail -10 .fingerees > .fingerees
Clearly what I would like to do is chop out all but the last ten
lines of .fingerees (This file contains a list of whoever has
fingered me.  It is now 
     124 .fingerees  lines long.  Rather cumbersome.)  But
instead I must do 

tail -10 .fingerees > result.txt; mv result.txt .fingerees

A much less elegant solution.  How can the shell know what is
going on however?  What if cat -> /usr/5bin/echo for instance?

So this would be my proposal.  Rather than requiring that the
shell know everything about any possible application it could
run and make it try to figure out all the possible ramifications
of its actions, could we try something like this...

The shell sees
tamsun ~> cat a b > b
First, it finds /usr/bin/cat.  Then it looks inside a file called,
let's say .cat.  The file contains a few lines of specifications
in some language know to the shell like this

% Cat specifications & limitations
% All files on the cmd line are read-only
% Write permission is not given for the current
% process for these files

$* files read-only

end

The shell makes a list of read only files for the current process
(a b) and then proceeds on, and tries open b.  Since permission
is not there, the operation fails and an error message is returned.
(The error msg could possibly be described in .cat)  Though some
shells will return an error msg already, it destroys your data
anyway.  This could avoid it, or allow the specification to tell
it how to deal with it.

For example, ask the user if they wish to concatenate a & b
and store the result in b.  If they answer yes, the shell does...
cat a b > uniq-name; mv uniq-name b
(Being careful about going over quotas, etc.)  And voila!  The
problem was handled with intelligence and grace.  Not to mention
that future programs can inform the shell what actions they are
doing w/o having to rewrite the shell each time to make it guess.

/usr/bin/.echo might be empty or not exist, thus telling the shell
that it doesn't have to worry about protecting/overwriting input
files.  (Of course, .echo must be in the real place of the actual
file...)

Note that this is just being sketched out in rough detail,
particularly when I say something like 'current process' but
I think it would provide a great level of intelligence and
friendliness to the Un*x shell and would be feasible.  What
do true Un*x advocates think?

BTW, the reason why many people are clamoring for a friendlier
Un*x shell is that while Un*x may be expert-friendly, it's lack
of user friendliness will definitely hinder its acceptance in
the larger world.  While some Un*x weenies may scoff at those
who choose other alternatives, doing so only hurts Un*x, for
by expanding and growing it can only improve.  Version numbers
on files, for instance, might be a better way to handle the
above problems for instance.

And Un*x is definitely not "user-friendly," at least not to
anyone I've talked to.  Only Un*x advocates and Un*x tutorials
claim such a thing.  I wonder what they are comparing it
to..  CP/M perhaps?  It is clearly time for Un*x to
reach out and COPY /B someone. + ,,

>Bryan So

-- 
Till next time,                \o/   \o/
                                V \o/ V     email:pinky@tamu.edu
<>  Sam  Inala  <>                 V