On Sun, 10 Aug 2014 18:21:16 -0700 "G. Richard Bellamy" <rbellamy@pteradigm.com> wrote:

Not sure if this is the correct venue for this comment, and apologies if it's already been mentioned, but why wouldn't mksh [1] provide ksh?

This would alleviate some AUR dependency weirdness, specifically with the oracle-sqldeveloper [2] package, which currently forces an install of ksh [3], even though it'll work just fine with mksh.

-rb

[1] https://www.archlinux.org/packages/community/x86_64/mksh/ [2] https://aur.archlinux.org/packages/oracle-sqldeveloper/ [3] https://aur.archlinux.org/packages/ksh/

Hello, that's because mksh by default does not provide a ksh binary, nor did it contain a mode to behave exactly like the ksh if called by this name, the extensions are always active. (It's been some years since I took the package and took a glance at the init code, maybe I'm wrong with this, feel free to correct me.) I think it's wrong to place this extended shell in the place of the original ksh. My intention is simply to give users the possibility to install the mksh and the original ksh parallel on the same machine, as they don't collide on the filesystem. If they want to call the mksh as ksh, people can still create a plain symlink for the binary. Also there is only one package that depends on mksh in the repos, kwalletcli. Sven-Hendrik makes no modifications regarding the shell in this PKGBUILD so I assume it's fine. As long as I don't make a problem for another TU or a developer I stay to the current setup of the package, when I add a ksh symlink to the package stating it also provides the ksh I take users the chance to install the original ksh and the mksh. There are users who don't want an extended shell because they work with the original since a lot of years on different systems. Best Regards, Thorsten