Re: Question about ash and getopts

[seebs at plethora dot net (Peter Seebach)]

Okay, some real data.

This is done using ash as of 20031007.  The only change made is this:

*** builtins.def.orig	Mon Dec 29 17:23:28 2003
--- builtins.def	Mon Dec 29 17:23:33 2003
***************
*** 66,72 ****
  falsecmd	false
  histcmd -h	fc
  fgcmd -j	fg
! getoptscmd -j	getopts
  hashcmd		hash
  jobidcmd -j	jobid
  jobscmd	-j	jobs
--- 66,72 ----
  falsecmd	false
  histcmd -h	fc
  fgcmd -j	fg
! getoptscmd	getopts
  hashcmd		hash
  jobidcmd -j	jobid
  jobscmd	-j	jobs

With that source, the shells are:
-rwxr-xr-x  1 seebs  wheel  91364 Dec 29 17:25 /tmp/sh.g
-rwxr-xr-x  1 seebs  wheel  91364 Dec 29 17:25 /tmp/sh.nog

I am unable to measure any performance difference between them.  Running
a sample configure script produces times between 10.35 and 10.44 seconds,
showing no apparent preference.  If you want pages and pages of 'time' output,
I could provide them, but the marginal benefit seems to be roughly nil.  If
there is a difference between the shells, it is smaller than the random
noise.  The variance between runs of the same configure script using the
same shell is one or two seconds of wall clock time; the variance between
the two shells, if there is one at all, is probably under a hundredth of a
second.

>From carefully comparing these two shells to the NetBSD /bin/sh they appear
to be related to (judging by the _RCSID strings in several of the files),
it looks very much as though the "13k" size number corresponds to the
overall removal of job control and related features from the shell.  In
fact, the difference on my system (which has a somewhat more "bloated"
/bin/sh) is a whole 16k.  The decision to mark getopts as "a job control
feature" (that's what -j means) appears to have no effect on either the
size, or teh performance, of the shell.

The decision to strip out job control features strikes me as a fairly
well-supported one; /bin/sh is a scripting shell, and it is understandable
if it doesn't have all the interactive bells and whistles.  Removing the
history commands is likewise reasonable.

However, getopts was never an interactive feature, a job control feature, or
a history feature.  It is a scripting feature, and the goal of /bin/sh is to
provide a standardized, portable, scripting environment.

There's the patch.  It's all of one line.  This has been a recurring issue
on this list as far back as 1999, when it was first pointed out that removing
that "-j" from the builtins file would "fix" the shell.  In all that time,
the only argument for disabling getopts has been "the shell is smaller and
faster as a result of these changes", but the changes in question appear to be
the removal of all job control and history features, not just getopts.

Can we just kill this now?  Take out the "-j", leave the support for getopts
in the shell, and all the shell scripters will be happy.  The configure
scripts will run at exactly the same speed, and I will happily join in
defending the decision to trim the job control and history features from the
shell to make a minimalist shell designed for scripting, leaving people the
option of using bash or pdksh if they want an interactive shell.

-s

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/