Rename this shell to krsh (or similar)

[ghost]

Someone on the Google Groups for this shell raised a very good point: https://groups.google.com/d/msg/korn-shell/NGmU63HZMbU/E1Qnx5YlBwAJ

if ksh starts to be modified beyond recognition it just is no longer ksh proper. than better call it krsh for obvious reasons, I'd say. really. not joking...

As this shell begins to diverge from what people want and expect from a shell with the name "ksh", perhaps giving it a new name would make things less confusing for everyone involved. There's nothing wrong with doing so, and it could be done at the same time as the github repo fork mentioned here: https://github.com/att/ast/issues/1441#issuecomment-554691923

@siteshwar, I'm wondering if it isn't time to talk again about forking and changing the README.md of this project to point people at the fork.

This would also make life easier for people using package managers. pkg install ksh versus pkg install krsh is a lot easier to understand, both for people who want ksh and for people who want krsh. Right now, this is what I get when searching for ksh on FreeBSD:

ast-ksh-20141224_1             KornShell 93
ksh93-2020.0.0.b1,1            AT&T KornShell 93
ksh93-devel-2019.09.20         Development branch of AT&T KornShell 93

n.b. the ksh93 package used to be ksh93u+ before it was switched to 2020.0.0.b1 and the separate ast-ksh package was created simultaneously

[krader1961]

This is not constructive.

[kdudka]

This proposal would make perfect sense if ksh93 was still maintained somewhere. This is, however, not the case. While the current release of ksh93-2020 might not fit everybody's needs, the original release of ksh93 became unmaintanable already (speaking as someone who has first-hand experience with downstream maintenance of ksh93 in Fedora and RHEL).

I think I understand your position as I also disagreed with many decisions done by @krader1961. But it does not change the fact that, if downstream distributions did not upgrade ksh to 2020, they would sooner or later have to drop ksh completely. Hence renaming this project now would hardly be useful in the end.

[ghost]

This proposal would make perfect sense if ksh93 was still maintained somewhere. This is, however, not the case. While the current release of ksh93-2020 might not fit everybody's needs, the original release of ksh93 became unmaintanable already (speaking as someone who has first-hand experience with downstream maintenance of ksh93 in Fedora and RHEL).

I think I understand your position as I also disagreed with many decisions done by @krader1961. But it does not change the fact that, if downstream distributions did not upgrade ksh to 2020, they would sooner or later have to drop ksh completely. Hence renaming this project now would hardly be useful in the end.

I get what you mean, too, but that only makes sense if this shell wasn't buggy, and actually worked. When will this issue be fixed? Multiple people have asked for buggy stuff to be reverted. https://github.com/att/ast/issues/1445 People on the Google Groups are reporting similar stuff: https://groups.google.com/forum/#!topic/korn-shell/NGmU63HZMbU https://groups.google.com/d/msg/korn-shell/TVpHd5rrI5g/GWC1sDXuAwAJ I'm glad someone's trying to do something with ksh, but some people actually use ksh (instead of fish) and need it to actually work...

I never had bugs until FreeBSD switched the package over to this shell from ksh. I won't deny that bugs have been fixed, too. Good things have been done. But overall, things feel worse rather than better.

[kdudka]

I get what you mean, too, but that only makes sense if this shell wasn't buggy, and actually worked.

Would you have fewer bugs if ksh was removed from your distribution and you had to switch to a different shell interpreter?

When will this issue be fixed? Multiple people have asked for buggy stuff to be reverted.

Sure, I also asked for it. But this is how open source works. People who volunteer to do work make decisions. If anyone does not like the decisions, they are free to fork the project, revert commits, rewrite history, whatever.

If someone volunteered to maintain the original ksh93 in a bugfix-only mode, I would be more than happy. But it will not happen unless someone else starts working on it. It is impossible to convince @krader1961 to do this work for us. Hi did something else and he did it for free (as far as I know). Take it or leave it.

Anybody is free to pick the original code of ksh93 and start fixing the outstanding bugs. There is no need to rename or fork this repo first. Once someone shows us maintainable code of ksh93, I will certainly support the rename/fork idea. But doing it proactively does not make any sense to me.

[ghost]

True, true.

[jghub]

I full-heartedly support/share the opionions voiced here that something bad is happening to the ksh93 legacy in this project. (after now having closely watched, tried out this "kr(a)sh" shell (sorry for bad pun) and tried to make rader aware of what is going wrong here and on the mailing list to and after going back through the last 2 years of issue history I conclude what others have before: rader will not listen and will proceed on his decided way. which is OK, but not if he claims that the result is "ksh93w+" to stay with the old versioning scheme...

this is gross and wrong. whatever bugs there remain in 93u+ they never seem to have been of the decisive "must fix NOW" variety. like is the regular case with krsh.

regarding maintainable/compilable code: I raised this question on the mailing list, got answers:

https://groups.google.com/d/msg/korn-shell/6nT_DIh27K4/abhQqjZcAAAJ

so it seems this project -- with I have come to believe is a sort of a personal "fight" of rader against Korn's code and driven by a reductionist/obsessive/compulsive urge to weed out perceived "superfluous" stuff and enforce "improvements/features" (which are really bugs) -- has one positive thing to offer it seems: availability of ready-to-compile ksh93u+ using the new build system. if this turns out to be true (and it really still is a true 93u+ binary afterwards w/o hidden "tidy up" by rader, that would be good enough to use: 93u+ was stable and predictable. remaining bugs or not.

so I believe many people would be happy to go back to that version.

this project should fork and not hijack the "ast" legacy any more.

[kdudka]

regarding maintainable/compilable code: I raised this question on the mailing list, got answers:

You asked how to get the source code of ksh93. The fact that the source code is available does not automatically mean that you are able to build a usable ksh93 binary out of it on a modern operating system.

this project should fork and not hijack the "ast" legacy any more.

I do not think that it would help on its own.

[jghub]

You asked how to get the source code of ksh93. The fact that the source code is available does not automatically mean that you are able to build a usable ksh93 binary out of it on a modern operating system.

my understanding so far is, that one indeed can build from the given linked locations. but I have not done that myself so far, true.

I do not think that it would help on its own.

agreed. that does not solve the primary objective to get a stable curated ksh93u+ with possibly carefully thought over real fixes of real bugs.

what it would solve in my view is the misconception that the present project is in some way formally or by qualification of the project head the future of ksh93. personally, I fell exactly in that trap by naively assuming it must be so. only after closer inspection I realised how wrong I was. and it seems, quite naturally, that package maintainers are making the same mistake by providing this shell rather than ksh93 proper. so harm is done here I would say. and that would go away if this project would be labeled adequately as no-longer-ksh93 (calling its release ksh2020 does not solve the misconception issue, obviously)

[kdudka]

my understanding so far is, that one indeed can build from the given linked locations. but I have not done that myself so far, true.

I would suggest you to first try to build the original ksh93 code before further commenting on this.

and it seems, quite naturally, that package maintainers are making the same mistake by providing this shell rather than ksh93 proper.

You are still missing the fact that there is currently no sustainable way to provide ksh93 proper on a modern operating system. Once you try to build the original ksh93 code, you will realize it. Package maintainers did not do any mistake because they had simply no better choice. Would removal of ksh93 from downstream distributions be a better solution from your point of view?

[jghub]

I would suggest you to first try to build the original ksh93 code before further commenting on this.

we have done that here ("we" being a (in these matters) more capable colleague, not me, to be clear ...) a couple of years ago. yes, it was cumbersome. but successful (in this case for 93u+ and 93v- and OSX).

but the links to ksh93u+ I referred to earlier at least partly point to an early phase of the present project, thus after migration to the meson/ninja build system if I am not mistaken. I will put it onto my todo list to see whether that enables easy building of 93u+.

you are still missing the fact that there is currently no sustainable way to provide ksh93 proper on a modern operating system. Once you try to build the original ksh93 code, you will realize it. Package maintainers did not do any mistake because they had simply no better choice. Would removal of ksh93 from downstream distributions be a better solution from your point of view?

I'm not missing that the the old build system is not a sound basis for the future and makes life difficult. see above: we have struggled (successfully, thank god) with that.

distros/no choice: that is undecided in my view. it seems the early phase of this project (after new build system introduction and hopefully before touching the ksh93 code notably otherwise) might solve that. I understand that this still would need someone sufficiently competent volunteering to make it happen. maybe the second person seemingly really involved in this project (siteshwar) could be that person, e.g., since he seems to have a clearer grasp of the situation and problems than rader?

removing ksh93 from downstream: I sincerely hope the alternative will not remain "ksh2020 or nothing". ksh2020 simply is not a usable ksh93 drop-in replacement. you probably know that, too, right?

and to be clear: I am not against this project, not against providing packages for it (if named as "something new, but no longer ksh93 proper"). what I am against is, that it replaces ksh93 proper since the project mostly equals rader and his approach, sadly, is doing harm by not caring for backward compatibility, carelessly throwing out stuff or modifying crucial behaviour etc etc etc.