Pandoc can convert to many different formats. Perhaps conversion to html with the scripts and then conversion to a desired format with pandoc could be a possibility. https://pandoc.org/
On Sat, Mar 27, 2021, 9:20 PM Jon Trulson <j...@radscan.com> wrote: > 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> 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 >> > > -- > 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
