On 3/26/21 7:31 PM, Chase via cdesktopenv-devel wrote: > @zeke it seems like you are conflating the submodule with the ksh program > itself. The submodule is not going anywhere and it not required to build CDE > as a whole but is a program that helps give CDE it's value. Requiring ksh as > a standalone program however, was originally required to run ksh's > installation script among other things, but yet another thing that autotools > solves for us, is that we no longer have to use the install script plus > databases as autotools can install for us. If someone could compile a list of > scripts that require ksh to run I could take a look at them. I know that our docbook to manpage converter needs ksh, but strangely enough debian has their own copy of this program that they maintain separately from us which doesn't use ksh, maybe we could use it: https://sources.debian.org/src/docbook-to-man/1:2.0.0-45/ > > @marcin In terms of getting a ksh library distributed, I really wouldn't hold > my breath about it. Right or wrong, and good for the CDE project or not, it > turns out that deleting your entire repo history due to a
Actually, they didn't delete the entire history. They moved it to the ksh2020 branch. A simple git switch or git checkout will expose the alternate work. > few debatably bad actors and then telling everyone to simply fork ksh and > finally abandoning it really shakes people's confidence in ksh. Not to mention the preferred fork at the time, ksh-community, immediately falling on it's face and dying right out of the gate. It would probably take years of convincing that ksh93u+m is a worthy successor to ksh, and Martijn himself has said he still considers the project to be an alpha. Getting linux distros to agree on making it the new distributed ksh, let alone the libraries that no one except us would even use as most forks of ksh are actually in house implementations, or do anything for that matter would be like trying to herd cats. One thing that would be helpful though in this regard, we need to import pmain.o from upstream, which means that technically, dtksh is EPLv1 licensed, as we have our main() from pmain.c which is EPL licensed, and all other assets are EPLv1 with the exception of our builtins and environment variables tacked on to init.c which are LGPL, so basically an extra lgpl library. If we were to make our own main(), that would mean that the main program is LGPL and all the libraries it calls are EPL, so therefor it would be a LGPL program. There are only two issues: 1. How do we write a main() that is different enough from pmain.c to be considered its own work? I doubt that AT&T would ever sue, but you never know... 2. I've tried to do this an it complains about missing symbols. I am not going to work on this since I am happy that it works at all, but if you really want to pursue this whole library idea, that would probably be step 1. > > Thank you for your time, > -Chase > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Friday, March 26, 2021 2:56 PM, Zeke Williams <lakele...@gmail.com> wrote: > >>> There was some progress made recently towards (1) - big thanks to Chase >> for taking up ksh93 upgrade. >> Very nice. You think we should maintain a CDE only version of ksh93 to avoid having to deal with the freebsd example that was provided and to maintain it better so it can work with CDE? Call it something else so it can co-exist with the OS version of ksh93. Just a thought I had. >> >> On Fri, Mar 26, 2021 at 3:44 PM Marcin Cieslak <sa...@saper.info> wrote: >> >>> On Fri, 26 Mar 2021, Zeke Williams wrote: >>> >>>> Can we remove it and just have the already installed ksh do the work >>>> instead? >>> In addition to what others said - ksh93 should be embeddable, so in theory >>> one day it should be possible to build dtksh which depends on already installed >>> ksh93 libraries. >>> >>> Two things need to be done for that: >>> >>> 1. dtksh build system needs to be rebuild to allow that (if at all >>> possible). >>> 2. operating systems need to start shipping not only ksh binary but also >>> its shared libraries. >>> >>> There was some progress made recently towards (1) - big thanks to Chase >>> for taking up ksh93 upgrade. >>> >>> Marcin >>> >>> >>> _______________________________________________ >>> cdesktopenv-devel mailing list >>> cdesktopenv-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org NTP: <c...@nwtime.org> Web: https://nwtime.org The need of the many outweighs the greed of the few.
_______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
