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

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

Post by Noah Friedm » Thu, 13 May 1993 19:25:58




Quote:>While I don't necessarily think this is a bad thing for an interactive
>shell, I wonder if the full blown "bash" or "tcsh" is necessary for a
>"programming" or "shell script" or "Makefile" shell.  I wonder if
>there should be a "mini-bash", one that doesn't have doesn't have all
>the features of a full blown bash but which is quicker and faster for
>shell scripts and the like.  Maybe it could be made from the normal
>bash code, but with features diked out with "-DTINYBASH" at compile
>time.

Actually, if a good scripting language is what you want, there are far
better alternatives to both the C shell and the Bourne shell.  They are `rc'
and `es'.

`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.  I forget
for the moment at which FTP site(s) it's available, but I'm sure many
people in comp.unix.shell can tell you.

`es' is based on rc, but has some extensions.  For example, it provides
lexical scope, first-class functions, a general purpose exception system,
rich return values (i.e. functions can return values other than just
numbers), and hooks into the primitives for file redirection, pipelining,
etc. so you can modify their behavior.  It also features a redefinable
read-eval-print loop.  It also provides a "dumping" mechanism similar in
principle to what GNU Emacs does, but far more portable.  Source for es,
and papers describing it, are available via anonymous FTP from
ftp.white.toronto.edu in /pub/es.

es runs a little slower than rc, but both are still much, much faster than
bash.  Furthermore, I've noted that while both shells have fewer "builtins"
than bash, I've been able to implement more things in es and rc without
calling any external programs than I have in bash.  I think this is because
the builtin features in these shells are better chosen, and equivalent
ideas in the two shells often have better semantics in rc/es.  In
particular, the simpler quoting mechanisms and the behavior of arrays are
what in my experience have made the greatest difference.

Why are rc and es such an improvement?  Because the fundamental design of
the Bourne shell is decades old.  Bourne shell imitations like zsh, ksh,
etc. have added a few new features, but they haven't fundamentally changed
the original design and semantics.  Experience with the problems extant in
the Bourne shell have led to cleaner shell designs.  (Let's not even *think*
about all the things that are wrong with {t}csh.)

For the sake of backward compatibility we have to keep around the Bourne
shells to run existing scripts.  That is why no one has any intention of
abandoning bash (and Chet Ramey has done a lot of work to improve it).  But
I like to hope that people will eschew them in favor of es or rc for
writing *new* scripts.  I plan to make sure es and rc are part of the GNU
system.  (Another reason why bash is not obsolete is that it has job
control, which many people want.  Neither es nor rc have job control,
though in my personal experience this is not an obstacle to using them
interactively.)

I think that rc and especially es are perfectly good for using
interactively, as well.  Both provide emacs or vi-style command-line
editing if you want them.  I've implemented in es all the bash "builtins"
I've ever relied heavily upon including command hashing, pushd/popd,
`type', etc; and for my own purposes I've improved upon them.  And I've
reimplemented a number of the scripts I've ever written in sh or bash (the
only thing that has prevented me from doing all of them is that I have
other work to do :-)).  I have yet to implement it (and I would never
actually use it), but spell checking would be trivial to implement in es.
You can roll your own history mechanism too (in fact, at least one history
mechanism has already been written for rc, and I'm sure it works in es as
well).  I think that even job control could mostly be done in es script,
though perhaps one or two more primitive hooks would be required.

The gist of what I'm saying is that the bourne shells have too many
gratuitous builtins: they make the shell larger, slower, and more complex;
often the features are not very flexible, requiring more and more builtin
features in order to get the behavior a variety of users want.  It would be
better to provide features which are dynamically loadable from a user's
library only when and if you actually want to use them.  This is precisely
what I've done with es, modelled on the same system GNU Emacs uses for its
libraries.

Well, I guess I wandered a bit in this post, but you get the general idea.
I have nothing but praise for using rc or es instead of the Bourne shells
or the abominable C-sick shells.

Happy shell hacking.

 
 
 

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

Post by Michael John Haert » Fri, 14 May 1993 11:55:53



Quote:>Why are rc and es such an improvement?  Because the fundamental design of
>the Bourne shell is decades old.  Bourne shell imitations like zsh, ksh,
>etc. have added a few new features, but they haven't fundamentally changed
>the original design and semantics.  Experience with the problems extant in
>the Bourne shell have led to cleaner shell designs.  (Let's not even *think*
>about all the things that are wrong with {t}csh.)

The problem is not the fundamental *design* of the Bourne shell.  The
problem really is botched implementations.  Let's look at some statistics:

7th edition /bin/sh  : ~4100 lines of code

System V.2 /bin/sh   : ~8500 lines of code.
        [ the System V.2 /bin/sh added functions and builtin echo, builtin test ]

Almquist Net2 /bin/sh: ~13100 lines of code.

GNU bash 1.12        : ~27300 lines of code
        [ excluding builtins, glob, and malloc, readline.
          ~48200 lines counting everything. ]

Now although it's not necessarily true that big == slow, my observation
on the subject is that "big" usually means that the author of the program
did not have a good concept in his or her head of exactly how the program
ought to function.  People who do not have a clear idea of exactly what
they are doing often do unnecessary things that are irrelevant to the
task at hand.  Programs littered with irrelevancies tend to be large,
hard to understand, and slow.

Also, note that in the particular case of a shell, it really can be
true that big == slow.  Why?  Because the principal activity of a shell
is forking subprocesses.  Proponents of vfork will argue that this doesn't
matter.  However, for better or worse, vfork seems to be going out of
style, to be replaced by copy-on-write implementations of fork.  Now
COW is certainly faster than raw copying, but IT'S STILL LINEAR IN THE
SIZE OF THE PROCESS.

Therefore, for shells, big "mostly implies" slow.

Leaving aside the issue of large process images slowing down new process
creation, let us return for a moment to the issue of authors littering
their programs with irrelevancies.

I decided to attempt to study the performance of the shell command
interpreters themselves, rather than the performance of the system
at forking and execing non-builtin commands.  So I wrote the following
simple shell script which executes no external commands:

foo() { case $1 in a*) ;; *) ;; esac ;}
bar() { case $1 in [abc]*) ;; *);; esac ;}
baz() { case $1 in xyzzy) ;; *) ;; esac ;}
for x in /usr/lib/*/*
do
        foo $x
        bar $x
        baz $x
done

The result, on a Sparc running SunOS 4:

% time /bin/sh stupid.sh
0.9u 0.3s 0:01 94% 0+144k 0+1io 0pf+0w
% time /bin/zsh stupid.sh
6.0u 2.4s 0:08 96% 0+728k 0+0io 0pf+0w
% time /bin/bash stupid.sh
11.0u 6.7s 0:18 97% 0+512k 0+0io 0pf+0w
% time /tmp/bash stupid.sh
10.0u 6.6s 0:17 97% 0+644k 0+1io 0pf+0w

Notice that Bash is MORE THAN TEN TIMES AS SLOW as the standard SunOS
/bin/sh (which is essentially the System V release 2 one).  I noticed
that bash was compiled unoptimized, so I tried building a version
compiling with -O.  It improved the user time from 11 to 10 seconds.
Wow.

Out of curiosity, I also tried zsh (for which I do not have source code
line counts, unfortunately.)  Although zsh weighs in almost twice as
fast as bash, it's still 6 times slower than /bin/sh!  I guess zsh
is botched too.

Quote:>The gist of what I'm saying is that the bourne shells have too many
>gratuitous builtins: they make the shell larger, slower, and more complex;
>often the features are not very flexible, requiring more and more builtin
>features in order to get the behavior a variety of users want.

The gist of what I'm saying is that Bourne shells need not be large,
slow, or complex.  Bash in particular is a remarkably poor
implementation, (WHY could anyone need 50,000 lines of code just to
write a bourne shell replacement?)  and it would be a very bad idea to
attribute Bash's failings to Bourne shells in general.

Clearly the GNU system will need a better /bin/sh.  Rather than starting
with bash and stripping it down, I would recommend starting from scratch.

Now, to avoid further bash bashing, let's turn back to the issue
of the failings of the Bourne shell *design*.

As I see it, the single largest botch in the Bourne shell is the
quoting stuff.  There are two aspects here:

* four kinds of quoting have weird interactions.  this makes the
  shell hard to program, but does not in itself slow it down.
* The shell re-lexes commands after variable expansion.  This
  slows it down.  However, my guess is that the slowdown is not
  all that significant.

Other than quoting, I really do not see a dramatic difference
between the /bin/sh language and, say, the /bin/rc language.
The syntax is different (pseudo-Algol vs. pseudo-C) but that
should not affect the performance.

Let's look at how "rc" handles my earlier benchmark.  Translated
for rc it looks like this:

fn foo { switch ($1) { case a* ; case * ; } }
fn bar { switch ($1) { case [abc]* ; case * ; } }
fn baz { switch ($1) { case xyzzy ; case * ; } }
for (x in /usr/lib/*/*) {
        foo $x
        bar $x
        baz $x

Quote:}

The result?

% time /bin/rc stupid.rc
1.0u 0.5s 0:01 98% 0+388k 0+0io 0pf+0w

(By the way, this is Byron's rc version 1.4, compiled with gcc -O.)
Note that this is STILL slower than /bin/sh.

In summary, I hope I have convincingly demolished the assertion that
/bin/sh slowness has any thing to do with its design being decades
old.  Rather, I suggest that Bourne shell clones are simply botched.
So the field is still open for someone to write a high quality /bin/sh
replacement.

 
 
 

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

Post by Byron Rakitzi » Fri, 14 May 1993 16:08:56




>>Why are rc and es such an improvement?  Because the fundamental design of
>>the Bourne shell is decades old.
>The problem is not the fundamental *design* of the Bourne shell.  The
>problem really is botched implementations.

I think it depends how you look at it. I would assert that it's much
more difficult to do a from-scratch implementation of "sh" than of
"rc", precisely because of the baroque nature of the design. However,
I will also have to agree with Mike that most of the new shells look
like they have unclean implementations: nothing that really points
towards a shortcoming of the /bin/sh model, but rather a general
lack of planning and coherence.

Incidentally, Mike: I timed "stupid.sh" and "stupid.rc" on an SS1
running 4.1.1 and found that rc ran typically in 0.1 fewer user seconds
than sh. System times varied from run to run but were comparable. Were
the time results you posted an average of several runs?

Finally, about a sh replacement: I believe Berkeley is using "ash" as
their 4BSD /bin/sh. I don't know anything about the quality of the
implementation, though.

Byron.

 
 
 

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

Post by Michael John Haert » Fri, 14 May 1993 18:41:35



>I think it depends how you look at it. I would assert that it's much
>more difficult to do a from-scratch implementation of "sh" than of
>"rc", precisely because of the baroque nature of the design. However,

I certainly agree with that.  Here, again, the number one obstacle
is /bin/sh's lexical conventions.  As far as I know, the only accurate
published descripton of the way the shell scans things is in, of all
places, Andrew Hume's paper about "mk".  Perhaps the forthcoming
Posix.2 standard also has an accurate description.  We can hope!

Quote:>Incidentally, Mike: I timed "stupid.sh" and "stupid.rc" on an SS1
>running 4.1.1 and found that rc ran typically in 0.1 fewer user seconds
>than sh. System times varied from run to run but were comparable. Were
>the time results you posted an average of several runs?

I was using a different machine: a 4 processor SPARCserver 670/MP,
running SunOS 4.1.3.  Furthermore, our /usr/lib might well have
different file names in it than yours.  These environmental
discrepancies might well account for the differences we observed.  I
did not formally average the results, but picked a 'visual median' of
several runs.  Mea culpa.  By way of atonement, I've appended the
results of several runs to this post.  As you can see, /bin/sh indeed
wins slightly on this machine in user time, and more dramatically in
system time.

Quote:>Finally, about a sh replacement: I believe Berkeley is using "ash" as
>their 4BSD /bin/sh. I don't know anything about the quality of the
>implementation, though.

Yes; I mentioned "ash" in my post.  Several people emailed me
afterwards to question whether the awful hacks in Unix /bin/sh were
what allowed it to run fast, and would a "cleanly portable" shell be
necessarily slower?  It motivated me to port the Net2 shell to SunOS

it on stupid.sh.  The results for several runs are again appended to
this post.  A representative sample run is:

% time /tmp/sh stupid.sh
0.7u 0.3s 0:01 99% 0+292k 0+0io 0pf+0w

As you can see, the Net2 /bin/sh does slightly better than
both Unix /bin/sh and rc-1.4.  As far as quality of implementation,
it is perhaps a bit large (but not nearly so bloated as bash or zsh),
and the code is littered with annoying #ifdefs, but on the whole
it has far less of that "unfocused" quality that is so characteristic
of poorly written software.  The performance is certainly adequate.

Statistics follow:

# SunOS (really System V.2) /bin/sh:

% repeat 20 time /bin/sh stupid.sh
0.8u 0.1s 0:01 96% 0+144k 0+1io 0pf+0w
0.8u 0.1s 0:01 99% 0+144k 0+0io 0pf+0w
0.8u 0.1s 0:01 96% 0+144k 0+0io 0pf+0w
0.9u 0.1s 0:01 97% 0+144k 0+0io 0pf+0w
0.9u 0.1s 0:01 97% 0+144k 0+0io 0pf+0w
0.9u 0.1s 0:01 96% 0+144k 0+0io 0pf+0w
0.8u 0.1s 0:01 96% 0+140k 0+0io 0pf+0w
0.8u 0.2s 0:01 98% 0+144k 0+0io 0pf+0w
0.8u 0.1s 0:01 99% 0+140k 0+0io 0pf+0w
0.8u 0.4s 0:01 96% 0+140k 0+0io 0pf+0w
0.8u 0.2s 0:01 98% 0+140k 0+0io 0pf+0w
0.8u 0.1s 0:01 97% 0+140k 0+0io 0pf+0w
0.8u 0.1s 0:01 97% 0+144k 0+0io 0pf+0w
0.8u 0.1s 0:01 97% 0+144k 0+0io 0pf+0w
0.8u 0.2s 0:01 98% 0+144k 0+0io 0pf+0w
0.8u 0.2s 0:01 98% 0+140k 0+0io 0pf+0w
0.8u 0.1s 0:01 89% 0+140k 0+0io 0pf+0w
0.8u 0.1s 0:01 97% 0+144k 0+0io 0pf+0w
0.8u 0.1s 0:01 97% 0+144k 0+0io 0pf+0w
0.8u 0.1s 0:01 95% 0+144k 0+0io 0pf+0w

# rc-1.4

% repeat 20 time /bin/rc stupid.rc
0.9u 0.3s 0:01 96% 0+392k 0+1io 0pf+0w
1.0u 0.3s 0:01 97% 0+392k 0+0io 0pf+0w
1.0u 0.3s 0:01 98% 0+388k 0+0io 0pf+0w
1.0u 0.3s 0:01 95% 0+392k 0+0io 0pf+0w
0.9u 0.3s 0:01 99% 0+392k 0+0io 0pf+0w
0.9u 0.3s 0:01 95% 0+388k 0+0io 0pf+0w
1.0u 0.4s 0:01 95% 0+388k 0+0io 0pf+0w
0.9u 0.5s 0:01 99% 0+380k 0+0io 0pf+0w
0.8u 0.5s 0:01 99% 0+384k 0+0io 0pf+0w
1.0u 0.2s 0:01 96% 0+392k 0+0io 0pf+0w
0.9u 0.4s 0:01 99% 0+392k 0+0io 0pf+0w
0.9u 0.3s 0:01 94% 0+396k 0+0io 0pf+0w
0.9u 0.3s 0:01 94% 0+392k 0+0io 0pf+0w
0.9u 0.3s 0:01 97% 0+388k 0+0io 0pf+0w
1.0u 0.3s 0:01 95% 0+392k 0+0io 0pf+0w
0.9u 0.7s 0:01 96% 0+396k 0+0io 0pf+0w
0.9u 0.8s 0:01 95% 0+392k 0+1io 0pf+0w
0.9u 0.3s 0:01 98% 0+388k 0+1io 0pf+0w
0.9u 0.4s 0:01 96% 0+388k 0+0io 0pf+0w
1.0u 0.3s 0:01 99% 0+388k 0+0io 0pf+0w

# Berkeley Net2 /bin/sh (Almquist shell):

% repeat 20 time /tmp/sh stupid.sh
0.8u 0.3s 0:01 89% 0+300k 1+1io 0pf+0w
0.7u 0.2s 0:01 93% 0+300k 0+1io 0pf+0w
0.7u 0.3s 0:01 96% 0+292k 0+1io 0pf+0w
0.7u 0.2s 0:01 96% 0+300k 0+1io 0pf+0w
0.7u 0.2s 0:00 95% 0+300k 0+0io 0pf+0w
0.7u 0.1s 0:01 93% 0+304k 0+0io 0pf+0w
0.7u 0.3s 0:01 97% 0+296k 0+0io 0pf+0w
0.7u 0.3s 0:01 99% 0+292k 0+0io 0pf+0w
0.8u 0.2s 0:01 96% 0+296k 0+0io 0pf+0w
0.7u 0.4s 0:01 98% 0+288k 0+0io 0pf+0w
0.7u 0.3s 0:01 95% 0+296k 0+0io 0pf+0w
0.7u 0.3s 0:01 95% 0+296k 0+0io 0pf+0w
0.7u 0.2s 0:01 97% 0+304k 0+0io 0pf+0w
0.8u 0.2s 0:01 97% 0+296k 0+0io 0pf+0w
0.7u 0.1s 0:00 95% 0+300k 0+0io 0pf+0w
0.7u 0.2s 0:01 96% 0+296k 0+0io 0pf+0w
0.7u 0.2s 0:01 86% 0+296k 0+0io 0pf+0w
0.7u 0.2s 0:01 96% 0+304k 0+0io 0pf+0w
0.7u 0.2s 0:01 95% 0+300k 0+0io 0pf+0w
0.7u 0.3s 0:01 98% 0+292k 0+0io 0pf+0w

 
 
 

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

Post by Robert Ea » Fri, 14 May 1993 19:29:50




| >Why are rc and es such an improvement?  Because the fundamental design of
| >the Bourne shell is decades old.  Bourne shell imitations like zsh, ksh,
| >etc. have added a few new features, but they haven't fundamentally changed
| >the original design and semantics.  Experience with the problems extant in
| >the Bourne shell have led to cleaner shell designs.  (Let's not even *think*
| >about all the things that are wrong with {t}csh.)

| The problem is not the fundamental *design* of the Bourne shell.  The
| problem really is botched implementations.  Let's look at some statistics:

| Now although it's not necessarily true that big == slow, my observation
| on the subject is that "big" usually means that the author of the program
| did not have a good concept in his or her head of exactly how the program
| ought to function.  People who do not have a clear idea of exactly what
| they are doing often do unnecessary things that are irrelevant to the
| task at hand.  Programs littered with irrelevancies tend to be large,
| hard to understand, and slow.

I think you're missing the main point, which isn't about the relative
raw processing speed of different shells, but rather the user
interfaces, language, and extensibility inherent in a shell design.  A
shell may have a nice quick implementation, but if the quoting rules
read like an instruction booklet for my tax form, I probably won't get
a lot of work done with it.

As Noah said, rc and es have a tight, well-thought-out set of builtins
and hooks that enables the user or programmer to get things done
without surprises, or guessing games, or calling baroque sequences of
external programs.  That's what design is about.  The "design" of the
Bourne shell arose from its implementation, and its descendants have
attempted to duplicate all its dark corners---rescanning text, quoting,
comment handling---whereas rc had a concise design, spelled out in the
Plan 9 manuals, allowing Byron to reproduce it faithfully, sight
unseen, and nearly bug-free.
--
robert earl           |


 
 
 

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

Post by Harald.Eik.. » Fri, 14 May 1993 21:49:29


! As you can see, the Net2 /bin/sh does slightly better than
! both Unix /bin/sh and rc-1.4.  As far as quality of implementation,

Yes, speaking about the Almquist "ash" shell, this has been my experience
too, at least it outperforms the Sun and HP /bin/sh's.  I've only tried
the version posted in comp.sources.unix volume19, not the one from Net-2,
but I believe they're not significantly different, except for som bugs
fixes and som general cleanup.

Anybody knows where Kenneth Almquist is nowadays?

  ~~h

 
 
 

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

Post by Dave Si » Fri, 14 May 1993 21:48:06




>>While I don't necessarily think this is a bad thing for an interactive
>>shell, I wonder if the full blown "bash" or "tcsh" is necessary for a
>>"programming" or "shell script" or "Makefile" shell.  I wonder if
>>there should be a "mini-bash", one that doesn't have doesn't have all
>>the features of a full blown bash but which is quicker and faster for
>>shell scripts and the like.  Maybe it could be made from the normal
>>bash code, but with features diked out with "-DTINYBASH" at compile
>>time.

>Actually, if a good scripting language is what you want, there are far
>better alternatives to both the C shell and the Bourne shell.  They are `rc'
>and `es'.

It's nice to be able to write scripts using the same language one uses in the
interactive shell of their choice, but I think such scripting is probably not
well suited to serious programming.  The novice user can write simple shell
scripts without learning a new language, and, in most cases, performance is not
an issue.

For advanced application and system programming, where performance does matter,
it's unlikely that the same features that make a good interactive shell will
also be suitable.  The tool of choice for this work, today, seems to be PERL.

I've used bash interactively for more than three years, and I've never had any
complaint with it's responsiveness.  As a user, I couldn't care less whether it
was written with 1000 lines of code or a million--it does everything I ask it to
do, promptly and correctly.

If it's not as fast as System V.2 Bourne shell or rc or Korn shell or ... on
scripts, so what?  It's primarily a shell, and it's usability as a programming
language is convenient, but secondary.

--

Martin Marietta Energy Systems           expect them to, and one day they will.
Workstation Support                                                -- Ted Nelson

 
 
 

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

Post by David J. MacKenz » Fri, 14 May 1993 19:28:37



Michael> 7th edition /bin/sh  : ~4100 lines of code

Michael> System V.2 /bin/sh   : ~8500 lines of code.
Michael>     [ the System V.2 /bin/sh added functions and builtin echo, builtin test ]

Michael> Almquist Net2 /bin/sh: ~13100 lines of code.

Michael> GNU bash 1.12        : ~27300 lines of code
Michael>     [ excluding builtins, glob, and malloc, readline.
Michael>       ~48200 lines counting everything. ]

Michael> Out of curiosity, I also tried zsh (for which I do not have source code
Michael> line counts, unfortunately.)  Although zsh weighs in almost twice as
Michael> fast as bash, it's still 6 times slower than /bin/sh!  I guess zsh
Michael> is botched too.

zsh 2.3.1 has 25538 lines of code.

 
 
 

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

Post by David J. MacKenz » Fri, 14 May 1993 19:39:48



Michael> As you can see, the Net2 /bin/sh does slightly better than
Michael> both Unix /bin/sh and rc-1.4.  As far as quality of implementation,
Michael> it is perhaps a bit large (but not nearly so bloated as bash or zsh),
Michael> and the code is littered with annoying #ifdefs, but on the whole
Michael> it has far less of that "unfocused" quality that is so characteristic
Michael> of poorly written software.  The performance is certainly adequate.

I've seen some posts that say that ash's quoting is messed up, so
that, for example, it doesn't run GNU configure scripts correctly.
Several people in comp.os.386bsd have advised others to avoid ash and
use bash if they want a correctly working sh.

I wonder how much of the lines-per-code differences are due to
comments and programming style differences like putting braces on
separate lines.  Judging from the binary sizes, obviously there are
big differences, but I wonder if the minimalist Unix C programming
style (comment?  what's a comment?)  biases the line-count comparisons.

 
 
 

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

Post by Nate Willia » Sat, 15 May 1993 01:26:09




>Michael> As you can see, the Net2 /bin/sh does slightly better than
>Michael> both Unix /bin/sh and rc-1.4.  As far as quality of implementation,
>Michael> it is perhaps a bit large (but not nearly so bloated as bash or zsh),
>Michael> and the code is littered with annoying #ifdefs, but on the whole
>Michael> it has far less of that "unfocused" quality that is so characteristic
>Michael> of poorly written software.  The performance is certainly adequate.

>I've seen some posts that say that ash's quoting is messed up, so
>that, for example, it doesn't run GNU configure scripts correctly.
>Several people in comp.os.386bsd have advised others to avoid ash and
>use bash if they want a correctly working sh.

There are patches that Jim Wilson at Cygnus made to ash that fix most (??)
of the problems that were found in ash.

For those of you who are familiar with 386BSD, they will be releases with
the new patchkit.

Nate

--


work #: (406) 994-4836       |  I don't think they'll catch on -
home #: (406) 586-0579       |                            Don Hammerstrom

 
 
 

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

Post by Harald.Eik.. » Sat, 15 May 1993 07:38:58


! zsh 2.3.1 has 25538 lines of code.

zsh 2.4.93 has 31750 lines (30594 save for comments).  Still less than
bash....

  ~~h

 
 
 

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

Post by Tony Porcz » Sat, 15 May 1993 06:20:21



>> 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?

t.

 
 
 

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

Post by Harald.Eik.. » Sat, 15 May 1993 10:32:55


! >> 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?

I'd guess no .)    ~~h

 
 
 

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

Post by Tom Culliton x22 » Sat, 15 May 1993 08:12:52


The simple scripts that Mike used for speed benchmarks for various
Bourne style shells and rc were to 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.  First a disclaimer,
the only real benchmark of anything is the performance for what you do,
Mike's scripts are completley artifical.  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, it weighs in at 96500 bytes vs. 53504 for sh, and the 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 stuggled 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 Michael John Haert » Sat, 15 May 1993 11:15:26



>! >> 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?
>I'd guess no .)    ~~h

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.

2) As I argued earlier, shell performance for fork/exec is often
   linear in the binary image size.

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.

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. :-)