Bug#683838: release-notes: transition: pdksh → mksh
Hi Thorsten,
On Sat, Apr 06, 2013 at 10:48:49AM +0000, Thorsten Glaser wrote:
> Joost van Baal-Ilić dixit:
>
> >I propose this text instead:
> >
> >-----------
> >
> ><section id="mksh">
> > <title>Pdksh to mksh transition</title>
> ^
> I’d not capitalise here, as it’s a name/“trade”mark.
>
> If you really must, I guess PDksh would make more sense.
I propose:
<section id="mksh">
<title>The pdksh to mksh transition</title>
> > <para>
> > The Public Domain Korn Shell (<systemitem role="package">pdksh</systemitem>)
> > package is being retired for the release after &releasename;, since
> > <command>pdksh</command> is no longer maintained (it has last seen active
> > development in 1999).
> > </para>
> > <para>
> > The MirBSD Korn Shell (<systemitem role="package">mksh</systemitem>)
> > package contains its successor; it has evolved from the Public Domain Korn Shell
> > and has been kept up to date with the POSIX standard on the shell.
> > In &debian; &releasename;,
> > <systemitem role="package">pdksh</systemitem> is a transitional package
> > using a variant of <systemitem role="package">mksh</systemitem> built with
> > special compatibility options to provide a <command>pdksh</command> binary
> > symlink. This compatibility binary behaves a bit more like the traditional
> > Public Domain Korn Shell then current <command>mksh</command>, it however
>
> Looking good so far.
>
> > contains bugfixes so differs a bit. Therefore, it is not a pure drop-in
> > replacement, and you'll have to check your Korn Shell scripts before running
> > them with current <command>pdksh</command> (or <command>mksh</command>).
>
> This lacks a suggestion to change the scripts to use #!/bin/mksh
> or at least #!/bin/lksh (the “compatibility binary”), because the
> transitional package will go away (and, if one invests effort into
> scripts, changing to mksh is better anyway, as that’s the one more
> closely aligned to POSIX).
I suggest:
contains bugfixes so differs a bit. Therefore, it is not a pure drop-in
replacement. So, you're advised to change your <code>#!/bin/pdksh</code> scripts to
<code>#!/bin/mksh</code> and test them. If the test fails, you're advised to fix
your scripts. If, for some reason, this is not possible, you can change
them to <code>#!/bin/lksh</code> scripts, and test them again. This test has more
chances of succeeding without changing a lot of your code. However,
be aware at some point in the future the transitional package will get
dropped from Debian.
</para>
(Note to self: check wether <code>#!/b/l</code> is sane DocBook XML.)
> ></para>
> ><para>
> > The compatibility binary is not suitable for interactive
> > use, so as system administrator, adjust the login shell of your Korn Shell
> > users. For minimal service interruption, do this before the upgrade of
> > the O.S: manually install the <systemitem role="package">mksh</systemitem>
> > package and change the login and/or interactive shells of users that use
> > <command>pdksh</command> to <command>mksh</command>. Furthermore, in order
> > to continue functionality like tab completion, copy
> > <filename>/etc/skel/.mkshrc</filename> into their home directories.
> ></para>
>
> Good, except tab completion always “just works”; the thing
> which /etc/skel/.mkshrc provides are some shell functions
> like pushd/popd/dirs and a nice PS1 (shell prompt). Neither
> of these is a regression, so “in order to continue” is also
> wrong.
<snip>
I suggest:
<command>pdksh</command> to <command>mksh</command>. Furthermore, you're
suggested to copy <filename>/etc/skel/.mkshrc</filename> into their home
directories: this provides some shell functions like <command>pushd</command>,
<command>popd</command> and <command>dirs</command> and a nice <code>PS1</code>
(shell prompt).
</para>
Thorsten: what do you think? Feel free to reply via IRC.
Bye,
Joost
--
there's a TON of people who breath air, but that doesn't mean they're qualified
professionals when it comes to wind-powered electric-generator engineering.
http://mdcc.cx/ --http://lwn.net/Articles/408052/
Reply to: