From owner-freebsd-arch Thu Apr 20 1:16:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4E4A137B564 for ; Thu, 20 Apr 2000 01:16:08 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA07204 for ; Thu, 20 Apr 2000 10:16:06 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA00775 for freebsd-arch@freebsd.org; Thu, 20 Apr 2000 10:16:05 +0200 (CEST) Received: from gilgamesch.bik-gmbh.de (T1-Hansenet.BIK-GmbH.de [192.76.134.246]) by hub.freebsd.org (Postfix) with ESMTP id 43D6237B521 for ; Thu, 20 Apr 2000 01:15:55 -0700 (PDT) (envelope-from cracauer@gilgamesch.bik-gmbh.de) Received: (from cracauer@localhost) by gilgamesch.bik-gmbh.de (8.9.3/8.7.3) id KAA15594; Thu, 20 Apr 2000 10:15:18 +0200 (MET DST) Date: Thu, 20 Apr 2000 10:15:18 +0200 From: Martin Cracauer To: Christian Weisgerber Cc: Cy.Schubert@uumail.gov.bc.ca, freebsd-arch@freebsd.org Subject: Re: Shells Message-ID: <20000420101518.B14732@cons.org> References: <200004152356.e3FNup102274@cwsys.cwsent.com> <200004160306.FAA67856@bigeye.rhein-neckar.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004160306.FAA67856@bigeye.rhein-neckar.de>; from naddy@mips.rhein-neckar.de on Sun, Apr 16, 2000 at 05:06:01AM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In <200004160306.FAA67856@bigeye.rhein-neckar.de>, Christian Weisgerber wrote: > (Are shell wars really appropriate to -arch?) > > In article <200004152356.e3FNup102274@cwsys.cwsent.com> you write: > > > With commit of tcsh, I'd like to raise another question. Are there any > > plans to replace sh with bash. Granted they're not 100% compatible, > > though my only experience with bash vs sh incompatibility was over 6 > > years ago on a Linux system, > > bash is reputed to execute scripts rather slowly. I don't know if > this still holds true for the current version. It definitely is > rather large, though. bash2 is large, but I cannot support the slowness claim. I pushed lot of things through our sh and bash2 while fixing our sh and I never noticed bash2 being slow. I didn't do benchmarks and I don't beleive in benchmarks anyway, though. > (Side note: > Incompatibilities between bash and sh fall into two categories: > 1. Comparing a POSIX shell (bash) with a traditional Bourne shell. > This is a non-issue since our sh is a POSIX shell, too. I did a lot of testing, and bash2 is by far the most bugfree implementation of a bourne shell as specified by POSIX I found. > 2. General upwards compatibility issues, i.e. the existence of > additional pre-defined variables, commands, etc in the name > space. This was already rare those six years ago, and as Linux > has become _a_, if not _the_ major unix platform since, any > offending scripts have been fixed. bash2 is supposed to turn off extensions when called as 'sh'. I didn't investigate how thoroughly this is done. But in general I agree with your point: our /bin/sh should be a pure POSIX shell without extension unless you turn them on. If you replaced our /bin/sh with bash2, the first problem would be a manpage that describes the POSIX part of bash only, but tracks new bash2 development. > I don't think replacing sh by bash is an issue. If there's a > question, then that's whether bash should be _added_ alongside sh. > Note that bash's license (GPL) makes an inclusion into the tree > unattractive. > > Personally, I think the addition of a _Korn shell_ should be worth > some consideration. Candidates are pdksh, which is of similar size > to our sh and could quite possibly replace it as well (as done on > OpenBSD), or maybe ksh93, if AT&T's license should allow this. > > Some facts: > * {,/usr}/bin/ksh is widely provided on commercial unices and is > actually ksh88 there. I think there is no point in going to /bin/ksh compatibilty now that POSIX specifies the feature set of /bin/sh. /bin/sh is the thing that is in the standards, not /bin/ksh. Also, we have a hard time approaching the standard for /bin/sh. Doing the same for /bin/ksh would be *additional* effort, as we can't drop supporting /bin/sh when setting for /bin/ksh. > * pdksh implements a substantial subset of ksh88, with some deviations > for POSIX compatibility. It is in the public domain(!). As I said in a different message, I think our current sh makes a better /bin/sh than ksh does. > * ksh93 implements a superset of ksh88, with some deviations for > POSIX compatibility. It is under AT&T's open source(?) license > . > (If anybody has managed to actually understand this thing, please > provide details.) > * NetBSD uses pdksh for /bin/ksh (and a relative of our sh for > /bin/sh). > OpenBSD uses pdksh for /bin/sh and /bin/ksh. As I said, I see no point in adding to confusion by supporting /bin/ksh as the standard scripting shell. /bin/sh is what gets polished by POSIX. ksh is well placed in ports. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message