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.


> 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 

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.

Reply via email to