On 3/27/21 5:25 PM, Zeke Williams wrote:
What is your opinion, Jon, on the shell and sed scripts Edmond posted
hours ago? You think this will help out a lot?
I haven't looked at them as they are not patches I could apply or use.
The whole doc system is another issue - It's based on docbook 2.x, and
needs to be:
- converted to a modern xml and utf-8 format
- upgraded to modern version of docbook (4.x or 5.x).
- something needs to be done about the dthelp system, which uses 'SDL'
which no one else seems to use.
With that, we could easily generate html, pdf, man pages, and a pile of
other well known formats from the documentation. And get rid of dthelp.
-jon
On Sat, Mar 27, 2021 at 1:45 PM Jon Trulson <j...@radscan.com
<mailto:j...@radscan.com>> wrote:
On 3/27/21 11:31 AM, Jon Trulson wrote:
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
...
Looking further at this stuff, it doesn't look that bad. Some of
the scripts I've looked at should work fine in something like
bash, and maybe even just a modern /bin/sh... The databases and
admin/IntegTools could just be ignored. same with docs (except
the actual scripts there, etc...)
I guess a question would be what should replace it?
I would think /bin/sh should be used where ever possible as
everyone already has that, but I am not sure about where the BSD's
are WRT /bin/sh and how modern/posix-y they are. Otherwise from
what I see, /bin/bash would seem to probably work fine instead of
/bin/ksh*
-jon
-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
<mailto:cdesktopenv-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
<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
<mailto:cdesktopenv-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
<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
<mailto:cdesktopenv-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
<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
