f.c.

f.c.

[Byron Rakitzis]

On the topic of username completion and other feeping creaturism, I
wanted to offer the following thoughts:

1) I don't want to add a new feature to rc unless someone cannot do
what they need to do without it. Putting the $^ hack in, for example,
was a big decision for me, and what persuaded me was the fact that it
was not otherwise possible to get $^ output without mucking around with
$ifs in a really ugly way.

2) Saying that your system administrator is too stupid or won't apply
the change, or that the filesystem should not be polluted with soft
links is not a conclusive argument as far as I am concerned. I honestly
think that /u is the correct way to solve the home directory problem,
because it is most definitely the most portable solution, which works
across ALL unix tools and ALL unix systems. I don't see why I need to
break rc in order to satisfy uncooperative sysadmins.

3) The readline brouhaha is a different kettle of fish as far as I am
concerned:  I added readline support because it was so easy to do so,
and because there are so many people out there "addicted" to filename
completion and command-line editing who would not otherwise consider
using rc. The number of requests for readline support that I have
received has been staggering! The number of requests for username
completion can be counted on the fingers of one hand.  Therefore, I saw
it as a necessary evil for rc to gain acceptance. (And in any case,
readline does not affect the language which rc accepts, so it was
easier to swallow the readline pill) As I said in a previous note, I am
hoping that people will instead use a mux-like xterm in order to get
command-line editing. But it is a little disingenuous of me to advocate
the use of such a program when no such program yet exists!  Hence,
readline.

Re: f.c.

[Mark-Jason Dominus]

> 1) I don't want to add a new feature to rc unless someone cannot do
> what they need to do without it.

For several weeks, I have been debating whether or not to ask for a
`...' feature.  I have always refrained.  It was not much work to code
up a version of `seq' and use that, and I find that it works well
enough.  

There are exactly two things I like about rc:

	1.  It is very fast.

	2.  The syntax is very simple.

The rest I can take or leave, but these two qualities were enough to
convince me to switch shells and redo all my .alias and ...rc files.
Until rc, I had never used a shell in which it was obvious how to quote
any given construction.  Today I catted a file called
Frequently_Asked_Questions_about_Unix_-_with_Answers_[Monthly_posting]
and I did not have to worry about metacharacters.  I can type a
multiline awk script on the command line and not worry about the shell
interpreting my awk script.  This is a big deal for me.  Even with sh, I
found that it was difficult to predict just how a certain construct
might be evaluated.  rc does the same thing every time.

I think it would be a shame to see these two qualities go away.  Putting
a `seq' or `...' operator into the language might be convenient, but it
wouldn't be much more convenient than using an external `seq'.  I would
rather spend my `very fast' advantage on exec'ing external programs than
mess up the neat syntax.

f.c.

[Donn Cave]

I'm posting this from a system with 6910 entries in /etc/passwd.  We used
a hashed passwd data base to speed things up.  Would a "/u" approach be
feasible here - searching a single directory with ca. 7K symbolic-link
entries?  Maybe we could make a tree - instead of "/u/donn", say "/u/d/o/n/n".

	Donn Cave, University Computing Services, University of Washington
	donn@cac.washington.edu