Should there be a GNU "small" shell, period?

Should there be a GNU "small" shell, period?

Post by Tom Culliton x22 » Sat, 15 May 1993 09:42:00



The simple scripts that Mike used as speed benchmarks for various Bourne
style shells and rc were just too much of a temptation, especially since
I had just finished tuning my compilation options for rc.  Needless to
say my results were a bit different.  The usual disclaimers apply, the
only real benchmark of anything is the performance for what you do,
Mike's scripts are completely artificial.  Second, timing one run on a
multitasking system is inconclusive, especially when the results are
close.

That out of the way, ;-) on my 486/33 SCO-ODT system, the rc executable
is linked with the bash readline library to add command line and history
editing, and thus weighs in at 96500 bytes vs. 53504 for sh.  Without
readline rc is smaller than sh.  The time numbers consistently showed rc
as being faster for Mike's scripts.

time /bin/sh test.sh

real        1.4         (the most consistent (and lowest) value)
user        1.1         (consistently 1.1 or 1.2)
sys         0.2         (consistently 0.2, occasionally 0.1)

time /bin/rc test.rc

real        0.9         (the most consistent (and lowest) value)
user        0.7         (consistent)
sys         0.2         (consistently 0.2, occasionally 0.1)

Now for a sales pitch.  If you've ever struggled with Bourne style
quoting, scratched your head over the sh man page, or tried to wade
through Bolsky & Korn's book "The Kornshell" and wondered who can
remember all this nonsense.  If you want a shell that's simple, elegant,
stable, predictable, free, but still robust, powerful, and fast.  Then
rc might be just what the doctor ordered.  It's also the simplest
program to bring up on a new machine I've ever encountered.  Try it,
you'll love it!

 
 
 

Should there be a GNU "small" shell, period?

Post by Bren » Sat, 15 May 1993 13:14:12




>>> zsh 2.3.1 has 25538 lines of code.
>> zsh 2.4.93 has 31750 lines (30594 save for comments).  Still less than
>> bash....

>I may be getting lost here, but can someone explain to me the significance
>of this utterly useless statistic?

Shhhhh.  It's *another* statistic.

Depending on how lines of code are counted, you may get decent approximations
of programmer productivity, said my Software Eng. prof last semester.

Personally, I think if you give a programmer relaxed working
hours (what, I can come it at 4pm and work through midnight?? GREAT!!),
a handy vending machine and adequate manuals, measuring productivity
is a waste of time since the project will already be done.

-Brent

p.s.  Software Engineering = Quality through Deforestation

 
 
 

Should there be a GNU "small" shell, period?

Post by Bren » Sat, 15 May 1993 13:40:44


Despite my previous jokes belittling software engineering, I
do think measuring lines of code is worthwhile.  My only beef
with software engineering is that it's an *extremely* boring class. ;-)
I actually have some SWENG interests, such as source analysis,
project estimation models, etc,
some of which may fall under optimizing compilers.


|
|We're getting into a semi-religious issue, but I'd like to
|point out:
|
|1) There have been a number of studies which concluded that
|   the number of bugs is often a linear function of the source
|   code size.  No, I have no citations handy.

|3) The ratio of code size/functionality is a good indicator of how
|   competent the author of the code was.  Professional dancers
|   make no wasted motions; the same is true of good programmers.

Similarly, the number of bugs is comparable to the complexity
of the code (do I need a reference here, or do y'all agree?).

And since the complexity of the code is proportional to the
size of code in SLOC [1], then it follows that the number of
bugs is somehow proportional to the size of the code [me].

|4) As David MacKenzie pointed out earlier, issues like the number of
|   comments and indenting style (particularly the GNU style that uses
|   more vertical space) add some "noise" to the line counts.  Probably
|   we would be better off counting non-commented semicolons, as that
|   is invariant under indentation transforms. :-)

Also in [1] is the following information:
(these are style characteristics for a code analysis system called CLAMP)

* module length should be between ten and 50 statements.
* program names should be greater than four characters
* comment lines should be greater than 10% of the total lines in a module.
* indentation should be greater than 8% of total chars in a module
* the percentage of blank lines should be greater than 8% of the total lines
* goto's should be avoided.
* ...complexity can be based on program length, operators and operands,
  control instructions or a composite of multiple factors.

Perhaps now is a good time to say, "if software engineering topics
continue here, perhaps the thread should relocate?"

-Brent

1. D. B. Simmons, "A Win-Win Metric Based Software Management Approach,"
   IEEE Transactions on Engineering Management, vol. 39, no. 1., pp. 32-41,
   February 1992.

 
 
 

Should there be a GNU "small" shell, period?

Post by Tim Smi » Sat, 15 May 1993 14:31:12



Quote:>4) As David MacKenzie pointed out earlier, issues like the number of
>   comments and indenting style (particularly the GNU style that uses
>   more vertical space) add some "noise" to the line counts.  Probably
>   we would be better off counting non-commented semicolons, as that
>   is invariant under indentation transforms. :-)

Use the token count program from the conciseness contest on comp.programmer.
It counts tokens, excluding comments and #include lines.

--Tim Smith

 
 
 

Should there be a GNU "small" shell, period?

Post by Peter Stee » Sat, 15 May 1993 20:02:33


Quote:>If you want a shell that's simple, elegant,
>stable, predictable, free, but still robust, powerful, and fast.  Then
>rc might be just what the doctor ordered.  It's also the simplest
>program to bring up on a new machine I've ever encountered.  Try it,
>you'll love it!

Does it haave job control?
--

Acadia Univ., Wolfville, NS, Canada B0P 1X0  902-542-2201  Fax: 902-542-4364
 
 
 

Should there be a GNU "small" shell, period?

Post by Tony Porcz » Sun, 16 May 1993 00:52:10




>>! >> zsh 2.3.1 has 25538 lines of code.
>>! > zsh 2.4.93 has 31750 lines (30594 save for comments).  Still less than
>>! I may be getting lost here, but can someone explain to me the significance
>>! of this utterly useless statistic?
>>I'd guess no .)    ~~h
>1) There have been a number of studies which concluded that
>   the number of bugs is often a linear function of the source
>   code size.  No, I have no citations handy.

I said 'number of lines', not 'code size'.  I hope the distinction is
rather clear.  Even for code size:  would you say one is more prone to
get in trouble with one letter variables in a reasonable size program or
with descriptive variable names?  Wow, but that would increase code
size.  (And, obviously, a three line code is less bug prone than a
thousand line code, for pete's sake.  Was that study sponsored by our
government?)  We might as well start counting how many times letter 'e'
was used.  Why don't we give up on counting angels on the head of a pin
and see if there is a more meaningful way of judging code.

t.

 
 
 

Should there be a GNU "small" shell, period?

Post by Jim Dav » Sun, 16 May 1993 03:01:48



>>If you want a shell that's simple, elegant,
>>stable, predictable, free, but still robust, powerful, and fast.  Then
>>rc might be just what the doctor ordered.  It's also the simplest
>>program to bring up on a new machine I've ever encountered.  Try it,
>>you'll love it!

>Does it haave job control?

No, and I don't miss it.  At work I open another window if I need
another shell; at home on my dumb terminal I run 'screen' and toggle
between virtual terminals if I need another shell.

Now obviously 'multiplexing' shells like that isn't completely
equivalent to job control, but I've found it a more than adequate
substitute.  Your milage, as they say, may vary.
--
Jim Davis               | "Looking like that SHOULD be forbidden."

 
 
 

Should there be a GNU "small" shell, period?

Post by Charles Hann » Sun, 16 May 1993 04:11:06




> `rc' is the name of the Plan 9 shell, though Byron Rakitzis
> reimplemented it for unix.

Duff implemented it under Unix and later ported it to Plan 9.  Byron's
reimplementation exists because the Bell Labs code is not free, not
specifically because it runs under Unix.

--

 /\ \   PGP public key available on request.  MIME, AMS, NextMail accepted.
Scheme  White hetero* atheist male (WHAM) pride!

 
 
 

Should there be a GNU "small" shell, period?

Post by Noah Friedm » Sun, 16 May 1993 05:43:00


I was not suggesting that vanilla sh is slow.  Rather, most
reimplementations (zsh, bash) which have added features are total cows.
 
 
 

Should there be a GNU "small" shell, period?

Post by Stephen J Bev » Mon, 17 May 1993 22:00:39



   `rc' is the name of the Plan 9 shell, though Byron Rakitzis reimplemented
   it for unix.  Among its advantages over the various Bourne shells are that
   it's fast and it has vastly simpler quoting rules.  It's about as
   minimalist as you could wish for while still being very useful.

Not to contradict the above, but don't the Plan 9 docs contain
something to the effect that _rc_ is too large and that a smaller
shell would be preferable?