Date: Mon, 05 Mar 2001 11:18:44 -0800 (PST) From: "Duane H. Hesser" <dhh@androcles.com> To: "Jacques A. Vidrine" <n@nectar.com> Cc: obrien@nuxi.com, bde@zeta.org.au, FreeBSD Architecture <arch@FreeBSD.ORG>, Will Andrews <will@physics.purdue.edu>, "Brian F. Feldman" <green@FreeBSD.ORG>, Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> Subject: Re: ksh93 (was: Re: cvs commit: src/gnu/usr.bin/binutils/ar ...) Message-ID: <XFMail.010305111844.dhh@androcles.com> In-Reply-To: <20010304134155.A72948@spawn.nectar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04-Mar-01 Jacques A. Vidrine wrote: > On Sat, Mar 03, 2001 at 08:50:13AM -0800, Cy Schubert - ITSD Open Systems Group wrote: > [snip] >> If we are going to import ksh93 into the source tree, which I think is >> a good thing, my vote is # 4 or # 4a. For something as critical as a >> shell that is used virtually everywhere I think 100% backward >> compatibility must be maintained and therefore we should keep ash in >> FreeBSD. Boot scripts can reference #!/bin/ksh a short while after >> notifying people on -stable (a plan would be nice). /bin/sh should be >> renamed to /bin/ash with a /bin/sh hard link linked to it. Later we >> can change the /bin/sh hard link to /bin/ksh, while keeping /bin/ash >> for backward compatibility (if anyone has forgotten my point about >> compatibility by now see my print example above). >> >> Hopefully I covered it all. > > Thanks for your summary. I would not support the import of any new > shell unless it was (ultimately) for the replacement of /bin/tcsh or > /bin/sh. We don't need "another" shell, but I do think we need a > "better" shell. I'm a little sorry to hear you say this...I wonder if we could change your mind somehow. Ksh93 is a very nice shell, fast and powerful, but the incompatibilities with the ash-based /bin/sh are more extensive than just the "local vs typeset" problem (which is a sticky one) and the problem of name conflicts with builtins. Trap handling is somewhat different, as I recall, and there is a problem with variable scoping in functions in ksh93 unless a "special" syntax (incompatible with "ash") is used to declare them. There are other incompatibilities. I've attempted a partial description of incompatibilities between various "Bourne/Korn-style" shells (including pdksh, ksh93, ash, and various versions of bash and zsh) in a document written for my SHELLINIT distribution. You you can peruse the pertinent section at http://androcles.com/dist/shellinit/using/node56.html What you will find there is not comprehensive (and certainly not authoritative, by all means comment upon any inaccuracies you may find). Nonetheless, I expect that an attempt to replace "ash" with ksh93 would be a disaster so far as *script interpretation* is concerned. The ash-based shell currently known as "/bin/sh" appears to do a very good job of interpreting scripts written for the "real" Bourne shell. At the same time, ksh93 is a far more powerful shell for *interactive* use, and I believe that it would be a very good thing to provide a viable B/K-style shell in the base system. I also agree strongly with your suggestion (below) that ksh93 scripts could be profitably used to replace the non-Unix (perl) processes in the FreeBSD build procedure. None of this is intended to denegrate 'tcsh', either. It is a useful shell for interactive use (if it had functions, I'd probably use it) and should remain. So I guess I'm disagreeing with you mostly when you say 'We don't need "another" shell...'; I submit that FreeBSD could use a more powerful function shell for *interactive* use in the base system. I also submit that the extended facilities of ksh93 (discipline functions, name spaces, co-processes, etc.) will be available to the system in "#!/bin/ksh" scripts if it is in the base. That won't be true if ksh93 lives in "ports" rather than the base system. Summmary...I'd like to see: 1) Ksh 93 imported as "ksh" 2) the ash-based shell retained as "sh" 3) perl replaced in the build process (exec 3> /dev/controversy) It would be necessary, of course, to bikeshed the question of growth in the root filesystem for "minimal root" situations, but that could probably be handled by placing one of the shells in /usr/bin (or Pittsburg, or wherever). > > I don't expect builtins to be a significant issue. If someone is > unfortunate enough to be using a binary with the name of a shell > built-in in their scripts, and is not using a full path to that script, > then the script would need to be modified. I don't think that in > reality this will be much heartache. > > ksh is attractive because it is quite possibly the most standardized > shell in existence, and at the same time is one of the better shell > programming languages. Potentially it could make some uses of Perl > during the build go away (David Korn says: ``For the most part ksh93 has > the functionality of perl 5 and arguably a more readable syntax.'' I > don't agree, but it isn't that far off). > > Cheers, > -- > Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > -------------- Duane H. Hesser dhh@androcles.com 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?XFMail.010305111844.dhh>