Date: Fri, 25 Jan 2019 22:39:47 +0100 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: freebsd-arch@freebsd.org,arch@freebsd.org Subject: Re: Importing mksh in base Message-ID: <42367007-C290-42C9-9F44-2A8F48665E7C@FreeBSD.org> In-Reply-To: <201901252129.x0PLTQAn008365@slippy.cwsent.com> References: <201901252129.x0PLTQAn008365@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Le 25 janvier 2019 22:29:26 GMT+01:00, Cy Schubert <Cy=2ESchubert@cschuber= t=2Ecom> a =C3=A9crit : >In message <20190125210346=2Exzvrvuvr4rj3guov@ivaldir=2Enet>, Baptiste=20 >Daroussin wr >ites: >>=20 >> >> --l7d7rf235ll3lmav >> Content-Type: text/plain; charset=3Diso-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=2E Bear >with me a=3D >> s this reply may not look like I intend it to=2E >> >=3D20 >> > On January 25, 2019 11:07:55 AM PST, Baptiste Daroussin ><bapt@FreeBSD=2Eorg=3D >> > wrote: >> > > >> > > >> > >Le 25 janvier 2019 18:12:58 GMT+01:00, Cy Schubert >> > ><Cy=2ESchubert@cschubert=2Ecom> a =3DE9crit : >> > >>On January 25, 2019 8:57:51 AM PST, Baptiste Daroussin >> > >><bapt@FreeBSD=2Eorg> wrote: >> > >>>Hi everyone, >> > >>> >> > >>>I would like to import mksh in base, >https://www=2Emirbsd=2Eorg/mksh=2Ehtm >> > >>>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=2E >> > >>EPL is compatible with the BSD license=2E Personally, I've been >toying >> > >>with the idea of importing ksh93 for a while now=2E >> > >> >> > > >> > >The reason I chose mksh is because it is heavily maintained and >from >> > >the testing I have done it was the "nicer" interface >> > > >> >=3D20 >> > Ksh93 is also heavily maintained=2E Look at their github activity=2E >My ksh9=3D >> 3-devel port has been tracking updates (I consider important)=2E >> >> 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=3D >> gh) > >Interactively ksh93's command completion listing looks unconventional=20 >but it functions the same=2E > >However programmatically it's the standard=2E Large commercial vendors,= =20 >like Oracle, still require ksh for its array handling among other=20 >things=2E > >> 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=3D >> ion >> on is not what I did expect) > >Completion is different=2E > >> >> 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=2E2M >> mksh is 331k > >It has that advantage=2E For embedded this is an advantage=2E However if= =20 >embedded is using ksh as a scripting language mksh and pdksh aren't=20 >100% compatible=2E Just so we know, It's interactive only and people=20 >would be well advised to install the port if doing any serious shell=20 >scripting=2E > >I think the size difference doesn't make up for the differences in=20 >scripting capability=2E (Yes, you can do arrays in bash but the syntax is > >different=2E) It really depends on what we want here=2E A full featured= =20 >shell that can be used for ksh93 scripts or strictly as an interactive=20 >shell with incomplete support of the ksh88 standard=2E > >> >> 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=20 >affected=2E 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42367007-C290-42C9-9F44-2A8F48665E7C>