Re: access

Re: access

[Donn Cave]

| The efficiency of rc or `test' or `access' is not the issue.  We have now
| learned that DaviD W. Sanderson's computing resources are the real problem

If you're thinking of using this list for a fundraiser to improve DaviD W.
Sanderson's access to computing resources, well, look out, there are lots
more where he came from.

Efficiency is "not the issue" only when the program in question doesn't play
a significant role in your computing environment.

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

Re: access

[Boyd Roberts]

   Donn Cave <donn@milton.u.washington.edu>
   
   Efficiency is "not the issue" only when the program in question doesn't play
   a significant role in your computing environment.

Hmm, I've just booted up my fave old tube computer, complete with mercury
delay lines.  But, dammit!  rc is just too slow.  All those memory accesses!
All that executable code!  Time to implement test(1) with some of these handy
valve diodes, or I'll never get to login before Christmas.

Now, just where did I put my soldering iron?

Re: access

[Boyd Roberts]

    Just to add to the information content of this posting, let me expand
    on one rationale for being concerned about overhead.  If I'm the sole user
    of an over-powered workstation, who cares, right.  But when you start
    sharing computer resources, you have essentially the same problem as a
    user with a weaker computer, and under the right circumstances use will
    inevitably grow to the point where the strain on resources is just tolerable.

The efficiency of rc or `test' or `access' is not the issue.  We have now
learned that DaviD W. Sanderson's computing resources are the real problem
(30 seconds to start an xterm etc...  see `cpu bigots').  We don't need
a faster `test'.  He needs more CPU.  Who else on the list can say it takes
30 seconds to start an xterm, and would consider that reasonable?

For reference, i've received 5 or 6 messages agreement with my stand on
`access'.  Although not all agreed on the tone :-)

access

[Hamish Macdonald]

>>>>> On Thu, 1 Aug 1991 14:36:25 -0500,
>>>>> In message <9108011936.AA15100@milton.u.washington.edu>,
>>>>> Donn Cave <donn@milton.u.washington.edu> wrote:

Donn> As long as there's going to be a list for rc, it would be nice
Donn> if contributors could include some useful information in their
Donn> postings.

Good point.

I basically agree with Boyd, that if it can be done outside the shell,
it should.

I hope people can see how adding a feature because it makes things
faster could send one down the feeping creaturism road.

In David's case, it appears that repeated calls to "test" in a short
period of time are his problem.  The purpose of this is to determine
what to put in his path.  Perhaps in general, the overhead of calling
"test" is not usually a problem.

Perhaps, then, what he needs to do is create a utility which for each
directory name argument will check if the directory exists, and output
the name if it does.

Thus, setting his path simply becomes:

	path=`{$home/bin/exists $path thatdir theotherdir /usr/local}

and then only one "exec" is needed for this in his .rcrc.

access

[Donn Cave]

As long as there's going to be a list for rc, it would be nice if
contributors could include some useful information in their postings.

I rather like the "access" idea, because (as dws points out) it addresses
a very common point of shell logic and therefore seems as though it could
significantly reduce overhead.  I don't know, I could be wrong, I haven't
written any shells lately.  It looks like at least a couple of people don't
like the idea, but the postings I've seen so far have been keeping their
cards pretty close to the chest on the subject.  One posting was long, but
most of the length was repetitions of the same imperative with variations
in capitalization and vulgar language, plus complaints about other features
in other shells.

It may be that some of the readers of this list are keeping score of how
many people say yea and how many nay to a particular proposal.  I'm not -
if I want a stamp of approval of the masses, I'll use csh.

Just to add to the information content of this posting, let me expand
on one rationale for being concerned about overhead.  If I'm the sole user
of an over-powered workstation, who cares, right.  But when you start
sharing computer resources, you have essentially the same problem as a
user with a weaker computer, and under the right circumstances use will
inevitably grow to the point where the strain on resources is just tolerable.
Just like traffic on an urban highway system.  Looking ahead to that, I'd
think that one would desire a system that made efficient use of resources -
a shell that doesn't need to exec a program to blow its nose, a highway that
doesn't have a stupid bend that always gets jammed.

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