Date: Fri, 25 Jan 2019 14:21:58 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Baptiste Daroussin <bapt@FreeBSD.org> Cc: freebsd-arch@freebsd.org,arch@freebsd.org Subject: Re: Importing mksh in base Message-ID: <5D1014CC-5CFB-435C-890D-33F9EB0B5245@cschubert.com> In-Reply-To: <42367007-C290-42C9-9F44-2A8F48665E7C@FreeBSD.org> References: <201901252129.x0PLTQAn008365@slippy.cwsent.com> <42367007-C290-42C9-9F44-2A8F48665E7C@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
On January 25, 2019 1:39:47 PM PST, Baptiste Daroussin <bapt@FreeBSD.org> wrote: > > >Le 25 janvier 2019 22:29:26 GMT+01:00, Cy Schubert ><Cy.Schubert@cschubert.com> a écrit : >>In message <20190125210346.xzvrvuvr4rj3guov@ivaldir.net>, Baptiste >>Daroussin wr >>ites: >>> >>> >>> --l7d7rf235ll3lmav >>> Content-Type: text/plain; charset=iso-8859-1 >>> Content-Disposition: inline >>> Content-Transfer-Encoding: quoted-printable >>> >>> On Fri, Jan 25, 2019 at 11:24:26AM -0800, Cy Schubert wrote: >>> > First time I've tried replying inline on this newer phone. Bear >>with me a= >>> s this reply may not look like I intend it to. >>> >=20 >>> > On January 25, 2019 11:07:55 AM PST, Baptiste Daroussin >><bapt@FreeBSD.org= >>> > wrote: >>> > > >>> > > >>> > >Le 25 janvier 2019 18:12:58 GMT+01:00, Cy Schubert >>> > ><Cy.Schubert@cschubert.com> a =E9crit : >>> > >>On January 25, 2019 8:57:51 AM PST, Baptiste Daroussin >>> > >><bapt@FreeBSD.org> wrote: >>> > >>>Hi everyone, >>> > >>> >>> > >>>I would like to import mksh in base, >>https://www.mirbsd.org/mksh.htm >>> > >>>And make it the default root shell (not necessary in one step) >>> > >>> >>> > >>>Why: >>> > >>>1/ it is tiny 400k (in the packaged version) all other shells >>fitting >>> > >>>the >>> > >>>expectation are bigger >>> > >>>2/ it's default frontend in interactive mode is very close to >>what >>> > >>most >>> > >>>people >>> > >>>are used to with bash and shells as default root shell on other >>BSD >>> > >>and >>> > >>>most >>> > >>>linuxes >>> > >>>3/ from my narrow window csh as a default root shell is one of >>the >>> > >>>major >>> > >>>complaint (usually the first thing a user get faced to) from >new >>> > >>comers >>> > >>>and >>> > >>>also for some long timers who are reinstalling a machine and >>have not >>> > >>>yet >>> > >>>installed/configured a bourne compatible shell >>> > >>> >>> > >>>What this proposal is _NOT_ about: >>> > >>>1/ the removal of tcsh from base >>> > >>>2/ any kid of denial of the quality and interest or features of >>csh >>> > >>> >>> > >>>What do you think? >>> > >>>Best regards, >>> > >>>Bapt >>> > >> >>> > >>Why not ksh93 instead? It is the original and authoritative Korn >>> > >shell. >>> > >>EPL is compatible with the BSD license. Personally, I've been >>toying >>> > >>with the idea of importing ksh93 for a while now. >>> > >> >>> > > >>> > >The reason I chose mksh is because it is heavily maintained and >>from >>> > >the testing I have done it was the "nicer" interface >>> > > >>> >=20 >>> > Ksh93 is also heavily maintained. Look at their github activity. >>My ksh9= >>> 3-devel port has been tracking updates (I consider important). >>> >>> I gave a chance to ksh93-devel, my first impression are the >>following, as an >>> interactive shell, it looks nicer than I remembered (still prefer >>mksh thou= >>> gh) >> >>Interactively ksh93's command completion listing looks unconventional >>but it functions the same. >> >>However programmatically it's the standard. Large commercial vendors, >>like Oracle, still require ksh for its array handling among other >>things. >> >>> the completion looks "unexpected" but interesting I bet that can >>probably be >>> tuned (having a numbered list with fullpath of application I can do >>complet= >>> ion >>> on is not what I did expect) >> >>Completion is different. >> >>> >>> In emacs mode, the history search does not look great, (not it does >>not look >>> great as well in mksh, but less worse :)) >>> >>> In vi mode both seem to behave the same >>> >>> Manpages in both sides looks pretty complete >>> >>> mksh only depends on libc while ksh93 depends on libc, libexecinfo >>and libm >>> >>> on amd64: >>> ksh93 is 1.2M >>> mksh is 331k >> >>It has that advantage. For embedded this is an advantage. However if >>embedded is using ksh as a scripting language mksh and pdksh aren't >>100% compatible. Just so we know, It's interactive only and people >>would be well advised to install the port if doing any serious shell >>scripting. >> >>I think the size difference doesn't make up for the differences in >>scripting capability. (Yes, you can do arrays in bash but the syntax >is >> >>different.) It really depends on what we want here. A full featured >>shell that can be used for ksh93 scripts or strictly as an interactive > >>shell with incomplete support of the ksh88 standard. >> >>> >>> Overall I still think mksh is a better choice there >> >>Though I still disagree, a knob to disable it, WITHOUT_MKSH, would be >a >> >>must as those who symlink to /usr/bin/ksh or /bin/ksh would be >>affected. And, > > >The goal of the import is not about providing a new scripting shell but >an interactive which closer to csh to what seems basic default >expectation of most (which still needs to be validated as such) > >I didn t intent to add it as /bin/ksh but as /bin/mksh > >Best regards >Bapt That's fine. Juxtaposed, one of the ports, pdksh, installs itself as ksh. A totally separate issue, it should install as pdksh. Then either a metaport or a bit of logic in /usr/ports/Mk adds the symlink. Or, leave it to the user to create manually. I haven't had the time to really look at this except to acknowledge it's a problem. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5D1014CC-5CFB-435C-890D-33F9EB0B5245>