Garrett D'Amore wrote: > John Plocher wrote: > > I think it is time for an updated spec/issue roll up. > > > > Here is where I think things stand - please correct any > > misunderstandings: [snip] > > 2) Relationship of "t-, t, t+" versioning scheme and C-Team > > integration rules. > > > > Commentary: > > The upstream convention seems to be "no incompatible changes", > > "run API conformance test suites rigorously to ensure no > > regressions" and "moderate new feature additions based on > > [- +] release state" > > > > The boogie man is whether or not incompatible changes would show > > up in a "-" release, or if bugs would show up there that would > > cause equivalent breakage. Given the external team's almost > > obsessive focus on compatibility, I for one am not concerned > > about this at all. > > > > Resolution: > > Not a problem. > > Agreed. Can the project team confirm your statement that no other such > additions are planned?
As said on IRC: For ksh93 version "t" and "t+" there won't AFAIK be any new keywords. Beyond that we don't have any plans for new keywords right now, however I can't rule it out that we may come up with new ideas in the next couple of years. Note: _YEARS_. For ksh93t we're pretty much occupied with getting bugfixes and testing done (which includes many sleepless nights and I even turned my current main work related to automating license extraction into a giant ksh93 testbed (erm... technically the only two suiteable languages with efficient variable tree support were JAVA and ksh93) to find more bugs (as a result we developed testcases like http://svn.genunix.org/repos/on/branches/ksh93/gisburn/scripts/tests/test_vartree002.sh or http://svn.genunix.org/repos/on/branches/ksh93/gisburn/scripts/tests/test_staticvariables.sh to hunt down the remaining bugs)). And before someone complains: The reserved "-T" and "-h" flags for "typeset" (marked as "reserved for future usage" in this case) are for a new type system, e.g. user-defineable types. It's there right now in the shipping ksh93 binary and the update will stabilize it but we are going to ARC that later in detail (likely when ksh93 version "t+" comes out), not now (and it won't add new keywords and the matching flags for "typeset" are "reserved" in this ARC case). > > 3) Creation of /usr/lib/shell as Project Private [snip] > > Create /usr/lib/shell as a Volatile playground with the > > following initial expectations: > > > > A place to bundle shell function libraries _toegether_ in > > one common base directory, have them share functions > > via ${BASEDIR}/sh/ if the functions are in the POSIX > > shell syntax and in interpreter-specfic (e.g. > > ${BASEDIR}/zsh/..., ${BASEDIR}/ksh/...) if they use > > extended syntax... and handle the modules (one module > > may contain multiple functions) and functions in a > > DNS-like hieracy and allow pattern to be used as > > selectors. > > > > The intent is that shells will contain a builtin > > variable which points to the base directory so that > > consuming shell scripts do not need to know the > > absolute location where the library files are stored. > > I would prefer to have the above slightly better specified... including, > what the variable name is, and how consumers will be able to use this. > (Including perhaps some examples of the hierarchy, and references to > what the file content is -- parsed scripts, precompiled shellcode, > shared objects, what?) The issue is that this is a new idea and I've crafted-up such details... but if we ARC that now we just end-up with a theoretically perfect design which turns out to be a pain to use in real-world applications. That's why I had the idea to make it "private" (as a lesson learned I'll ask John Plocher next time to check an ARC case before posting it - it seems getting the interface stabilty level wrong ("Private" vs. "Volatile") quickly leads to hell and beyond...)) - to make sure we can test the design in the real world and make adjustments and _then_ ARC it. I don't want to end-up with a design like SMF's UTF-8 property strings - which are _theoretically_ a good idea (I'm explictly excluding the Unicode issues around Han unification (which could lead to the conclusion that using UTF-8 for property storage in SMF wasn't a good idea either)) until you realise that adding UTF-8 data to non-UTF-8 encoded multibyte data results in an invalid character sequence which no utilty can read at character level (therefore using any property values with charcters outside ASCII is currently impossible with SMF - the consuming tools/shell scripts just choke and collapse when they try to deal with it) ... perfect theoretical design, zero practical value. > Also, how will we get things like zsh or bash to > use these? (See David Comay's response and commentary on zsh's > /usr/share repository.) Erm... where did David Comay post to this thread ? Which posting do you mean ? > HOWEVER, I recognize that this is Volatile, subject to change, and I > won't press too heavily for the above details. (I still think it would > be a good idea to have a more complete specification. Even if it is > going to change soon.) Umpf... for now I would prefer to go the way of "the code is the documentation" (or ask in shell-discuss at opensolaris.org) and if the code works in the real world start writing documentation, let others contribute and then later move it to ARC when everyone is happy. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
