rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
* cpu bigots
@ 1991-08-01 14:55 DaviD W. Sanderson
  1991-08-01 15:00 ` Boyd Roberts
  0 siblings, 1 reply; 3+ messages in thread
From: DaviD W. Sanderson @ 1991-08-01 14:55 UTC (permalink / raw)
  To: rc

> `test' does _not_ belong in the shell.

I was unaware there was any revealed doctrine on this issue.
I suppose you were violently against the "echo" builtin, too,
since it is not strictly necessary to have it in the shell.

> On my 3max it takes 0.4s (real & 0.0s cpu) to start rc and 1.6s (real
> & 0.4s cup) to process my .rcrc, and it's bloated to 181 lines of
> system imposed crap and 61 lines of personal stuff.  Getting a `rc
> -l' in an xterm is damn near instantaneous, once X decides to give me
> a window.

I am delighted you have such fast hardware.  People with fast hardware
can certainly afford to be zealots for modularity.  The university has
chosen not to let me use any fast hardware, however, and I certainly
can't afford to buy any myself.
It takes my poor machine thirty seconds to put up an xterm, but only
when the compiler isn't running.  If it is, then the xterm doesn't come
up until the compiler has finished.

You speak of small programs.  I agree wholeheartedly.  The whole reason
my machine is so slow is because the university has chosen to force me
to use X, which is the most apallingly bloated thing I've ever had the
misfortune to see on a computer.  And no, I can't avoid it, because
here they don't let grad students administer their own workstations.

DaviD Sanderson


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: cpu bigots
  1991-08-01 14:55 cpu bigots DaviD W. Sanderson
@ 1991-08-01 15:00 ` Boyd Roberts
  0 siblings, 0 replies; 3+ messages in thread
From: Boyd Roberts @ 1991-08-01 15:00 UTC (permalink / raw)
  To: rc

    > `test' does _not_ belong in the shell.

    I was unaware there was any revealed doctrine on this issue.
    I suppose you were violently against the "echo" builtin, too,
    since it is not strictly necessary to have it in the shell.

Got it in one.  I'm against gratuitous builtins.  The shell is there to run
programs, not to have programs built into it.  Shell builtins are there because
there's no other way to do it.  It's got nothing to with cpu power, but
everything to do with `doing one thing well' and a modular, tools approach.

    > On my 3max it takes 0.4s (real & 0.0s cpu) to start rc and 1.6s (real
    > & 0.4s cup) to process my .rcrc, and it's bloated to 181 lines of
    > system imposed crap and 61 lines of personal stuff.  Getting a `rc
    > -l' in an xterm is damn near instantaneous, once X decides to give me
    > a window.

1 second of CPU on CPU unknown is a useless measurement.  The 3max is given as
a reference.  Granted it's an absurd amount of CPU power for one person.  But,
that's life around here.

    It takes my poor machine thirty seconds to put up an xterm, but only
    when the compiler isn't running.  If it is, then the xterm doesn't come
    up until the compiler has finished.

30 seconds!!  That's appalling!  How do you get _any_ work done?


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: cpu bigots
@ 1991-08-01 15:54 Arnold Robbins
  0 siblings, 0 replies; 3+ messages in thread
From: Arnold Robbins @ 1991-08-01 15:54 UTC (permalink / raw)
  To: rc

> Got it in one.  I'm against gratuitous builtins.  The shell is there to run
> programs, not to have programs built into it.  Shell builtins are there because
> there's no other way to do it.  It's got nothing to with cpu power, but
> everything to do with `doing one thing well' and a modular, tools approach.

Well goodness, does pattern matching belong in the shell?  Not really, the
notation is inconsistent with what the other regexp utilities on Unix use,
which confuses the heck out of beginners, and it adds lots of extra code
to the shell.  We should really all use:

	grep stdio.h `{ls | egrep '\.c$'}

all the time.  None of this silly *.c nonsense.

-------------------------------

Obviously, I'm not serious.  The point is, there are times when separate
programs should be merged.  A primary example is the -u option to sort;
it wasn't added until it became obvious that sort|uniq was such a common
idiom.

I ran a 4BSD system for some years, and still vividly remember the process
accounting numbers for the separate 'test' program.  It's not suprising that
that one got built into the shell.

To sum up, I think a balance has to be struck.  Sometimes things should
be moved into the shell.  I'm not going to make a case one way or the
other for 'test' (which has some weird semantics) or the proposed access
program.  But let's keep the real world in mind.

Arnold


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1991-08-01 15:56 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1991-08-01 14:55 cpu bigots DaviD W. Sanderson
1991-08-01 15:00 ` Boyd Roberts
1991-08-01 15:54 Arnold Robbins

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).