Garrett D'Amore wrote:
> Sorry, one more set of questions:
> > This project is an amendment to the Korn Shell 93 Integration project
> > update 1 ARC case (PSARC/2008/094) specifying the following additional
> > interfaces:
> > 1) Update of ksh93 from upstream release ast-ksh.2007-12-15 to
> > ast-ksh-2008-05-22
> > 1.1) Update of ksh93
> > 1.2) New "typeset" variable storage qualifier for function
> > 1.3) New floating-point datatype "hexfloat" ("typeset -X varname)
> > 1.4) New reserved options for "typeset".
> > 1.5) New ksh93 math functions "ceil":
> > 1.5) New reserved builtin "enum"
>
> As you now have created a new keyword and function name, ("ceil" and
> "enum"), what will happen to scripts that may already have used these words?
"ceil" won't cause trouble since it's a math function and right now
ksh93 has no way to define your own math functions - if you want to use
shell code in math functions you have to use $(myfunction arg1 arg2
arg3) but (( myfunction(arg1, arg2, arg3)+0.5 )) does not work (yet -
we're working a solution for that).
> Have the upstream providers given thought to dealing with changes like
> this and their impact on already-deployed scripts? (Maybe there aren't
> any that we care about yet, since our ksh93 is still so new.)
IMO it's hard to belive that anyone uses "enum" as function name - those
who are used to write C/C++ applications have a different view of "enum"
and the possibilty that there is a shell function with the same name
(you get the same kind of problems if you define a shell function called
"typeset" in a Bourne shell script and then assume that this script runs
properly in bash/ksh88/ksh93/etc.).
BTW: In the worse case people can just delete the builtin via $ builtin
-d enum #
> I'm concerned, going forward, as ksh93 syntax becomes more prevalent,
> that bringing in changes like the above may have unintended consequences
> in scripts or even ON delivered components, which we cannot easily find
> or test.
Right... but crawling down the changelog of ksh93 I think this is the
_first_ new language-specific builtin (= which means "not bound to a
specifc path") since 1993 (David may correct me). Such additions seem to
appear rarely and AFAIK having such a thing appear every ten years can't
hurt much assuming we want that the shell langauge is allowed to evolve.
Maybe Irek's idea of making rules like
http://www.opensolaris.org/os/project/shell/shellstyle/#do_not_reserved_keywords_for_function_names
mandatory and provide something like "shlint" or "shappcert" (or a
module for "appcert") to test for such things could avoid the risk
you're worrying about... would that work ?
> It would be nice (and maybe this is advice to send upstream) if there
> was a way for script authors to be sure that their namespace was not
> going to change underneath them. As one possible solution (and this is
> just for illustrative), imagine a flag for ksh, -N2008.05.28, which
> script authors could put in their #!/usr/bin/ksh line which ksh would
> take to mean that only the language features available in ksh version
> 2008.05.28 should be exported.
>
> Another solution, might be to reserve some portion of the namespace
> (e.g. with a prefix identifier such as an underscore) for either new
> names in the language, or to reserve it for script author use (e.g.
> names with a certain prefix are guaranteed to be "safe".)
I don't like the flag idea because it will add massive amounts of |if()
... else ...|-code almost everywhere in the libshell codebase which will
make the code harder to maintain&&test and drains lots of performance.
And the "prefix" thing... how should that look like ? Almost everything
I can imagine looks horrible from a stylistic point of view... ;-(
I really would prefer to just say "don't use C/C++/JAVA keywords for
function names and you're safe".
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
