Casper.Dik at sun.com wrote:
> >In general I am requesting the ARC people to burry this issue and let
> >the project team come up with a solution in peace - which means don't
> >rip out pfksh93 from this ARC case - there are at least three existing
> >ways to deal with the problem (see my other email) and IMO we have
> >plenty of time with deal with the problem since the intial putback
> >commits ksh93s-_alpha to OS/Net anyway - which means there will be a
> >couple of putbacks between now and the final version of ksh93s where we
> >can revisit this issue and hack a working solution together...
>
> The pf*sh issue is somewhat broader than just the builtins.
>
> In the ideal world the pf*sh would just have a flag bit set and the
> kernel would take care of most of the rest. (So a pf*sh would not
> involve changing the code in the shell).
>
> For now, the easiest route I think is disabling all "non-standard"
> builtins for pfksh93.
Erm... this is not that easy since this would break the AST/ksh93 test
suite (for example disabling the builtin "test" command is a very bad
idea) when ksh93 has launched as "pfksh93" and I really like to avoid
that.
However there are multiple workarounds (already described in other
postings here (e.g. use fully qualified path, an alias to the full path
etc.)) and AFAIK at least the following solutions:
1. "pfksh93" checks whether there is a RBAC entry for the matching
command and disables the use of the builtin in this case (the problem is
that we "randomly" use either the builtin or the native OS version which
may or may not be predictable for the script author).
2. A new wrapper gets created ("pfkshexec", based on libshell which gets
called by ksh93 and copies-over the whole shell environment) which
executes the builtin command in the matching RBAC context
In general it would be my preference to avoid a "TCR" and let us develop
a propper solution in peace (without pressure), otherwise I fear we may
accidently "rush in" something which later turns-out to be a totally
useless monstrosity (note that we're initially putting back ksh93s-
alpha - which means we have much time left until ksh93s reaches the
"final" status...).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
