On 3/27/21 11:07 AM, Zeke Williams wrote:
> If someone could compile a list of scripts that require ksh to run I
could take a look at them.
I don't know exactly how helpful this information I'm providing will
be, but I'm hoping it's useful. I used grep --recursive "ksh" * and
grep --recursive "sh" * in the root directory of autotools-conversion
to find anything I hope would be useful. Let me know if there's
anything you can do with the results.
git is your friend - try this:
git grep bin/ksh
The ksh references in cde/admin could be probably ignored as that will
mostly all go away in autotools
doc/ would be trickier, for example doc/util/dttoman would need fixing,
but the documentation text itself could be ignored for a later date.
programs/* would be good to fix, though localized/ would need to be
treated with care
...
-jon
On Fri, Mar 26, 2021 at 10:31 PM Chase <nicetry...@protonmail.ch
<mailto:nicetry...@protonmail.ch>> 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/
<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 <mailto: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
<mailto: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
--
Jon Trulson
"Entropy. It isn't what it used to be."
-- Sheldon
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
