future of ksh package

[joerg van den hoff]

On 14.01.20 03:12, Ryan Schmidt wrote:
> 
> 
> On Jan 13, 2020, at 03:52, joerg van den hoff wrote:
> 
>> hi there,
>>
>> not that long ago I asked for updating the ksh package and ryan thankfully did that and interacted a bit with the ast/ksh project ("ksh2020") at github in the process.
>>
>> in the intervening months I had to learn, however, (by working with the "new" ksh and by interacting with the maintainers on github) that what has happened to ksh93 in that project (and so far continues to happen) is not altogether good (to say the least): serious regressions (and trivial, easily triggerable ones made it into their "stable" first release), strange decisions by the main "coder" like insisting to change default cd behaviour, performance breakdown compared to ksh93u+ by 200-300% (and no solution or attempt to seriously address this issue apart from reverting some compiler flags in sight).
>>
>> against this background, the second maintainer of the k2020 project now conceded on IRC that it might be wise to provide not only ksh2020 but also legacy ksh93u+ packages for fedora (he's working for RedHat and in charge of the ksh package(s) there it seems), while the mksh author yesterday opened this issue at debian:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948745
>>
>> which basically states the same request there which I herewith would raise for macports as well:
>>
>> please reanimate a "real" ksh93 package of that name containing the last release from ast/Korn (i.e. ksh93u+ 2012-08-01) and rename the current ksh package to ksh2020 or similar. also if possible, make them _both_ installable side by side (and maybe "select"able to being assessed under the canonical 'ksh' name).
>>
>> the situation for osx is currently not as grave as with debian (and, seemingly (I have been told), for FreeBSD) in that we still have /bin/ksh available (which is 93u+) -- while those distros now only have ksh2020 --  but I believe it would be good if macports would also have its own ksh93u+ package just in case apple decides to get rid of it, e.g.
>>
>> in my view, for the time being, it is very clear that ksh2020 is not a viable drop-in replacement for ksh93u+. if it ever gets there, remains to be seen.
>>
>> thank you for macports
>>
>> joerg
> 
> 
> ksh93 was unbuildable in MacPorts for years, starting with OS X 10.9.
> 
> https://trac.macports.org/ticket/43392

I forgot about how long this is the case (actually, I myself opened that ticket I see now...)

> 
> And on earlier OS versions where it was buildable, its peculiar build system made it impossible for MacPorts to supply the build system with vital variables to tell it how we needed it to build.
> 
> https://trac.macports.org/ticket/32182

understood.

> 
> I was only able to resolve those issues by updating to the version which has now evolved into ksh 2020, because that version replaced the ancient problematic build system with meson.
> 

yes. it builds easily now. problem is, _what_ it builds: ksh2020 started off from ksh93v- which was 
in manifest beta state when Korn and colleagues had to give up work on it (so it was buggy, quite in 
contrast to ksh93u+). and (part of) the current problems with ksh2020 (not least the performance 
breakdown, but it's not only that...) I have mentioned come on top of that. so it is not fit at all 
in my view to act as a drop-in for ksh93u+ (=/bin/ksh) at the moment. could change in the long run 
(one would hope, but personally i am very sceptical ...) but it is not there yet. so the 
idea/request to provide ksh93u+ in parallel to ksh2020 (and to make the distinction clear!) seems 
very sensible/necessary.

2 questions:

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)? 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 ;)).

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?