> Yes... and IMO it would be useless to document that because then
> everyone could step-up and demand the documentation of every single
> "easter egg" in ksh93, too. Currently the only purpose of these bits
I'm not sure if I want to even know what other sorts of "easter eggs"
might be present in the shell.... ;-|
But it's important to realize that ARCed does not imply documented at
least in terms of user documentation.
> mapped to /usr/ast/bin/ are to have a quick&easy way to diagnose
> problems within scripts (for example such a script may redice in a
> read-only location and may therefore not be editable but may still honor
> the externally-defined ${PATH} variable) which may depend on features
> only available in the ksh93 builtins (for example the AST "msgcc" was
> such an example).
Perhaps I'm confused about what /usr/ast/bin is for. Can you please
provide a clarification or pointer to some documentation or an email
thread where this might have been discussed? I would have said that
I'll wait for the ARC material but if that's missing details like this,
then I think that's an issue.
In general, any sort of interface (including ones like command line
options or environment variables) which change the behavior of ksh93
should be ARCed. If they're not intended to be used by general users
or documented, they they can be ARCed as Project Private although with
an explanation of what behavior they control.
By the way, is the .paths mechanism described by David Korn in
http://www.opensolaris.org/jive/thread.jspa?messageID=32986胚
also going to be documented?
dsc
