Where is that ksh2020 development happening?
t doesn't seem to be linked from your account.

Sadly, due to circumstances out of my control (for the time being), the forked code base is behind a corporate high security zone and not (yet) readily available to get out of there and onto a GitHub account. Hopefully, I will be able to do that at some point. It is all patched up with the latest from the old ksh2020 project and I intend to add any new bug fixes that you (@McDutchie) have made or will make to your own KSH code base also. But contrary to what people here or elsewhere might want (not everyone can be satisfied) it has already had very substantial enhancements made to it, and more actively being made as we speak. So it will foster a different development philosophy than the other efforts currently under way.

Some of the major philosophical elements of this forked ksh2020 project are:

likely continue to the use the name 'ksh2020', but this is not really carved in stone
POSIX compatibility will be retained as very much as possible
also compatibility with the existing documented and undocumented features of KSH will be (strictly) maintained, as much as humanly possible
the MESON-NINJA build system, which originally was there, has been (essentially) abandoned and just basically a hierarchical MAKE system has been put in place
the build is back to an enterprise deliverable configuration with the shell code residing entirely inside the shared object library 'libshell.so'
LIBAST and LIBDLL (as well as all of SFIO) are integrated into the final LIBSHELL build and are not separately available (I consider these dead on their own merit and have no plans to make them separately available); they are still all separate in the code base; note though that at the moment (and NOT at all likely to continue indefinitely), the following can be done to create what appear to be independent shared object libraries for all of the former libraries (or just link against 'libshell.so' to get them):

$ ln -s ibshell.so libast.so
$ ln -s libshell.so libdll.so
$ ln -s libshell.so libsfio.so
external dynamically loaded built-ins have been restored by building w/ the header file 'shell.h' and linking against 'libshell.so' (that is all that is needed); sadly, this occurred in two steps that wasted some time due to the two stages of the original ksh2020 code, actively developed and abandoned; this step was largely also associated with restoring C++ code compatibility with the KSH code base
currently the SFIO code (which was once available as an independent library) is absorbed within the LIBAST code; this is how the old ksh2020 project put it and left it; there is no plan to make the SFIO code an independent library again (at least not by myself)
the KSH code base has been fixed (restored) to allow for integration of C++ both as part of the base code and for built-ins (plug-ins), either statically linked or dynamically linked to the base KSH code (as now embodied within the 'libshell.so' shared object library)
the KSH base code now requires at least C99 and C++11 to build; the previous ksh2020 code
required just C99; in this new project at first only C99 and C++03 were required, but just recently (a few days ago) some C++11 code was added, now raising the requirement for the whole base to C++11; it is expected that likely C11 will also be required, but this has not actually happened as yet

Comment:
There will likely be many who are cursing right now that C++11 is required. I know where you are coming from (I feel your pain, I do), but you were going to have to stomach C++03 anyway (due to code additions in that) and now (just due to recent new code additions) have to have C++11. Now if we all had our way, we would indeed (happily) allow for C18 and C++20 code in the base! I know that we all have our own constraints on what code can be used within certain projects, but in all fairness, C++11 is already nine years old (it is now the year 2020 if you have not yet noticed). Those who will not be able to handle C++ at all or C++11 in particular will have to use one of the other KSH projects underway. Incidentally, C++ has been used for some third-party built-ins (plug-ins) as far back as probably twenty (20) years ago already. C++ itself is not new, at least not for built-ins, but its use in being built and linked against the recent ksh2020 base got regressed. That issue has been fixed (through a good bit of grunt work) and C++ code can now be used anywhere, both in the base KSH code and in any statically or dynamically linked code.

Other major elements that have been enhanced:

the code safety around the MALLOC subsystem has been substantially enhanced with a more vigorous lock-out semaphore and also the use of disabling all signals during MALLOC code execution; this is all due to a basic architectural weakness within the original KSH base code design (it has to be said); in the future there will be no code executed during a caught signal (including, for example, no job reaping from signal-handling context); this will take a (relatively) long time to re-architect though
all environment-variable related subroutines (LIBC or otherwise) are now emulated and exported by the KSH base code so that any linked objects, either statically linked or dynamically linked to KSH, will get the interposed environment variable subroutines; this allows all linked code to access the NV dictionary tree within KSH for its view of exported environment variables using the standard or otherwise subroutine interfaces for that (other than through the special context pointer passed to built-ins)
all other dependencies that the LIBAST and LIBDLL code had back to the KSH base code have been removed (those libraries are now independent again of any KSH code); this step was not really philosophically needed to meet the project end goals, but was done anyway out respect for the once-independent old libraries (and if they ever want to be independently available again in the future)

All other (totally backwardly compatible) enhancements so far:

in short, there are way too many to enumerate; these will all (hopefully) someday be documented though

Future directions:

the main future element that needs to be addressed is to get all code that does anything significant (like job reaping -- and anything else of significance) out of any and all signal-handling contexts; this was a major design deficiency (to put it mildly) of the original KSH code base; this goal will finally make KSH absolutely code-safe in the face of any and all high-volume signal bombardment toward KSH from external signal-generating sources; this step is also required to make normal (unadulterated) C++ libraries containing dynamic memory management totally safe to use within the KSH base code -- something that is likely going to be (very much?) required in future KSH development; the days of interfering with or even appearing to interfere with the normal unadulterated use of the normal system MALLOC facility will finally (long overdue) be over with!

Other possible future and (strictly) incompatible changes:

I will be totally honest here and tell you that at some point the required interface between the KSH base code and any built-ins designed to work w/ KSH, either being statically linked or dynamically linked, will be changed! Currently, all KSH built-ins REQUIRE that all standard-input and standard-output (and for completeness, likely standard-error) use the SFIO library interface for these activities. This is a BURDEN too great to continue indefinitely! It was a burden too great to really handle twenty (20) years ago already, but it was done out of necessity. The required use of SFIO for built-ins was way too restricted in its flexibility for more modern file-io requirements. It added in an undue burden of additional code to attempt to emulate enhanced features or to mask out the lack of features within SFIO. Consequently, the requirement for built-ins to use SFIO for STDIN and STDOUT will eventually be removed. The likely replacement (at this point in time being considered) is that raw file-descriptors will be passed between the base KSH code and any KSH built-in instead. The advantage of having raw file-descriptors as the interface is that, it is hoped, that ANY IO library could be used within KSH built-ins, including and not limited to: STDIO, SFIO, C++ standard-streams, corporate other, open-source other, other, et cetera. Comments are welcome here on what should replace SFIO for the interface to built-ins, but only from people who are familiar with this issue, and who have suffered under it when writing their own KSH built-ins. Note that this issue has NOTHING to do with the use of (or should have NOTHING to do with the use of) SFIO within the KSH code base itself (not necessarily its supplied built-ins though). Use of SFIO within the KSH (proper) code can and likely will continue. The issue of IO for built-ins is and should be a separate matter. The complete consequences of this change are not yet totally analyzed. But change along this line will eventually happen in order to remove the requirement of using SFIO within built-ins. Note that this will also open up the door for the possible removal of all of the SFIO code from KSH proper itself. But there is no necessity for that as of yet. It might be hoped though, that even after the requirement for SFIO (for built-ins) is removed, that any and all KSH built-ins will be ALLOWED to CONTINUE to use SFIO if they want to. We are not totalitarians here! And freedom of personal library choices are and will be respected as much as possible. But this is a longer term goal and not entirely analyzed out as of yet. All intelligent and constructive comments (please) on this issue are welcomed. Non-intelligent comments on this (like "you cannot do that" or " that is treason!" or "that is against the philosophy of xxx") will likely be totally ignored.

Uh oh!

Fix the bash compatibility mode #9

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions