On 3/27/21 7:39 PM, Zeke Williams wrote:
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/ <https://pandoc.org/>
You might want to get a good idea about the current doc system before you make suggestions like that :)
I think an upgrade to docbook (which this pandoc can support) to version 4 or 5 is the way to go. Oh, and kill dthelp - generate html instead and fire up a browser to the correct page :)
I had actually attempted some of this - at least conversion to utf-8, but in the end, the help system killed that idea because it is ancient crufy shit, using a help format no one else on the planet uses. This SDL format is generated via docbook in CDE. Take a cruise through the parsers in dthelp/parser. Bring some drugs. Every time I look at it, I say to myself: "This has got to go".
So we would need to start there. Scripts aren't going to solve anything except perhaps by the end user who can then ignore CDE's doc system :) It's a hack that does not solve the underlying problems.
-jon
On Sat, Mar 27, 2021, 9:20 PM Jon Trulson <j...@radscan.com <mailto: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. -jonOn 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-jonOn 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
--
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
