Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Apr 2000 10:15:18 +0200
From:      Martin Cracauer <cracauer@cons.org>
To:        Christian Weisgerber <naddy@mips.rhein-neckar.de>
Cc:        Cy.Schubert@uumail.gov.bc.ca, freebsd-arch@freebsd.org
Subject:   Re: Shells
Message-ID:  <20000420101518.B14732@cons.org>
In-Reply-To: <200004160306.FAA67856@bigeye.rhein-neckar.de>; from naddy@mips.rhein-neckar.de on Sun, Apr 16, 2000 at 05:06:01AM %2B0200
References:  <200004152356.e3FNup102274@cwsys.cwsent.com> <200004160306.FAA67856@bigeye.rhein-neckar.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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
>   <URL:http://www.research.att.com/sw/license/ast-open.html>.
>   (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 <cracauer@cons.org> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000420101518.B14732>