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