@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 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
