Importing mksh in base
Cy Schubert
Cy.Schubert at cschubert.com
Fri Jan 25 22:22:32 UTC 2019
On January 25, 2019 1:39:47 PM PST, Baptiste Daroussin <bapt at FreeBSD.org> wrote:
>
>
>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
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 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.
More information about the freebsd-arch
mailing list