What is your opinion, Jon, on the shell and sed scripts Edmond posted hours ago? You think this will help out a lot?
On Sat, Mar 27, 2021 at 1:45 PM Jon Trulson <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> 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 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 > listcdesktopenv-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > > > -- > Jon Trulson > > "Entropy. It isn't what it used to be." > -- Sheldon > > > > _______________________________________________ > cdesktopenv-devel mailing > listcdesktopenv-devel@lists.sourceforge.nethttps://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 >
_______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
