Importing mksh in base

[Cy Schubert]

In message <20190125210346.xzvrvuvr4rj3guov at 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 at FreeBSD.org=
> > wrote:
> > >
> > >
> > >Le 25 janvier 2019 18:12:58 GMT+01:00, Cy Schubert
> > ><Cy.Schubert at cschubert.com> a =E9crit :
> > >>On January 25, 2019 8:57:51 AM PST, Baptiste Daroussin
> > >><bapt at 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,
-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.
 altering the order of PATH may put some between a rock and a hard 
place. A knob would be an absolute must.