James Carlson wrote:
> Alan Hargreaves writes:
> > Unlike other built-in commands named in PSARC/2006/550, the "print"
> > built-in in ksh93 will _not_ be bound to the /usr/bin/ pathname to
> > ensure backwards-compatiblity to existing ksh93 scripts (for example
> > scripts running in "restricted" shell mode expect that some shell
> > builtins are available independently from the value of ${PATH}).
>
> Could someone on the ksh93 team explain this bit in a little more
> detail? It might be just a nit, but I don't follow the logic above:
> what usage case requires that this path isn't bound?
The usage cases are:
1. "Legacy"/"Compatibilty" issue: Existing ksh88 and ksh93 scripts
assume that "print" is _always_ available, independetly how the value of
${PATH} looks like (the same applies to "sleep" and "printf" for ksh93
scripts (e.g. these are the only three non-special [1] shell builtin
commands which _must_ be there)).
2. Restricted shell scripts (e.g. "rsh", "rksh", "pfrksh" [2] etc.) need
a way to output data (e.g. counterpart to "read") and therefore "print"
was never bound to a PATH element since the korn shell exists. Otherwise
you have shell scripts which can't output anything except syntax errors
when running in "restricted" shell mode.
Or short: Binding the "print" builtin to a PATH element would blow-up
lots of scripts
[1]="special builtins" refers to shell builtin commands like "read"
which are part of the shell language and must run within the shell
process itself (e.g. to write information back into variables or change
the shell's status (e.g. "set", "unset", "shift", "alias", "exec" etc.
fall into the same category))
[2]="pfrksh" doesn't exist yet but ksh93 now has support for such a
chimera made from profile+restricted shells
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
