Tim Foster wrote:
Now, as to the problem of #!/bin/sh being bash or sh, or #!/bin/ksh being
ksh88, 93, etc. I had initially been thinking about a 'personality zone' (in
the same ilk as we now have branded zones) - but that's pretty heavyweight. A
more elegant solution might be to teach intp.c about a proposed $OS_PERSONALITY
environment variable. Based on this variable, while executing an interpreter,
we'd go digging for the right personality.conf file, which would in turn alias
us to the desired executable for that personality.
- just a suggestion - could this work at all?
One problem with personalities is the following:
Say I set my preferred $OS_PERSONALITY to /usr/ucb [*]. Then I run some
add-on software package such as firefox that includes shell scripts.
How to tell the system that I want ucb for commands that *I* type at the
command line, but not necessarily for scripts embedded in software packages?
There are already tell-tale cases where this can be seen to be failing
(including binaries as well as scripts) where it's clear people say
things like system("ps -ef") without a full path and thereby generate
bad argument errors.
You can tell people to use full paths in scripts, but not everyone does,
plus commands get moved around, e.g. the /usr/sfw/bin -> /usr/bin thing.
Perhaps (for scripts) one other option to consider is a modification to
the "install" command to replace "#!/bin/ksh" with
"#!/personality/bin/ksh" or whatever based on a personality specified in
the packaging info.
Now, potentially there are solution to this. but it seems that if you
introduce more variation into the OS you'd need to consider what happens
if a user installs multiple software packages each of which wants a
different personality. And note that BrandZ punted on essentially this
question and just said "each brand (aka personality) runs in it's own
zone". Although this is a less than ideal solution for users who want
to mix software.
Hugh.
[*] not saying this is recommended - just an example. /bin/awk versus
gnu/bin/awk would be another.
_______________________________________________
opensolaris-discuss mailing list
[email protected]
