Importing mksh in base

[Baptiste Daroussin]

Le 25 janvier 2019 22:29:26 GMT+01:00, Cy Schubert <Cy.Schubert at cschubert.com> a écrit :
>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,


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