future of ksh package

[Ryan Schmidt]

On Jan 14, 2020, at 03:35, joerg van den hoff wrote:


> 1.
> would you consider to alter the naming/description of the current `ksh' package to reflect that it is actually _not_ ksh93 any more (in terms of stability, performance etc)?

I already did change the name of the port from ksh93 to ksh and adjusted the description at that time to remove references to ksh93.

https://github.com/macports/macports-ports/commit/a73585c5b6cd957d71e5a5bb6277c11104a6e229


> AFAIAC it should also install under that name (ksh2020) rather than ksh in order to not mask /bin/ksh (which we luckily still have: so Apple still gets it compiled at least ;)).

I am not convinced that the port should install a program named "ksh2020". Are you suggesting that it should continue to install "ksh2020" next year and forever into the future, or are you proposing that each year we should change the name of the program that the port installs? Wouldn't that be chaotic for users who want to use this port and possibly reference its programs from their scripts?

As far as I understand it, it is the intention of the current developers that this ksh is ksh. Their build system installs it as ksh. So it is not unreasonable for MacPorts to allow the build system to do so.

I know that you disagree extensively with the current developers of ksh about the direction they are taking, and have read some of the issues you have filed with them about that, but I don't want to get drawn into those arguments here.


> 2.
> would you consider to include a ksh93u+ package (under the package name ksh93, e.g,  and installing as 'ksh' since it _should_ mask /bin/ksh provided bug fixes are included) if someone gets it to compile under OSX (with the original nmake system or otherwise) and can provide this on github or elsewhere?

Anybody can submit a pull request, including one that re-adds ksh93 if desired. If you like, I could fairly easily resurrect the old ksh93 port from before I updated it, though since it would only work on 10.8 and earlier I'm not sure how useful that would be today.

I think it was mentioned in one of the upstream issues I read that if anyone else wants to fork ksh93 and continue its development in a different direction from the one the current developers of ksh are pursuing, they are free to do that, but to my knowledge nobody has done so. If someone someday does, we can certainly follow that development in a ksh93 port.