Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-Id: <200312292334.hBTNYuqd024130@guild.plethora.net> From: seebs AT plethora DOT net (Peter Seebach) Reply-To: seebs AT plethora DOT net (Peter Seebach) To: Cygwin List Subject: Re: Question about ash and getopts In-reply-to: Your message of "Mon, 29 Dec 2003 17:10:24 EST." <6.0.1.1.0.20031229161810.03bbd940@127.0.0.1> Date: Mon, 29 Dec 2003 17:34:56 -0600 X-IsSubscribed: yes 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/