I have to write an addendum to my first post. Upon further inspection, if I
have read all the posts correctly, it seems that the project was being directed
by two men who didn't care much for backwards compatibility with posix and have
had their commit privileges revoked. However since they were some of the only
ones working on the project, it has effectively been killed off with AT&T
stating that they plan to archive the project and have the community fork it on
their own. What an absolute mess...
However, some good has come out of it, we have a shell that we can integrate
that isn't far off from the one we have now which will make porting much
easier, and the hash library is back (I may still attempt to remove it in favor
of our own but its no longer a top priority). The meson version is effectively
dead as well. I think the most promising community version is this one:
https://github.com/ksh93/ksh they state that they plan to fix all the bugs
before they try for any new features, and I might be able to submit a patch
with our dtksh modifications protected by ifdefs, meaning that we no longer
have to use the super sloppy method of removing objects and inserting our own
and instead just specify -DBUILD_DTKSH. Thoughts?
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, July 3, 2020 11:27 PM, Chase via cdesktopenv-devel
<cdesktopenv-devel@lists.sourceforge.net> wrote:
> Hi all,
> Recently I was attempting to fix and old patch of mine that switches ksh's
> hash for DtHash, our builtin substitution in order to import upstream ksh. I
> looked at ksh's github and everything seems to have imploded there. AT&T have
> stepped in and reverted all major commits since 2012, a number of community
> devs have quit and the project seems to be at a complete standstill. The
> branches seems to have split into a ksh2020 branch (new commits by
> contributors) and a ksh93v branch (2012 with few additions). How should we
> proceed with importing a new ksh? Personally, I think ksh2020 had the right
> idea (at least in terms of moving away from the mamfile build system), we
> could probably take it, autotool it and hard fork from there. I will probably
> continue to work on the patch because using our internal tools will be a lot
> better than taking from an extremely volatile upstream, but thats not for me
> to decide, your thoughts Jon?
>
> Marcin your input would also be appreciated as well.
>
> Thank you for your time,
> -Chase
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
