>Do you mean replacing "root"'s login shell in /etc/passwd with any shell
>? Where is this documented (AFAIK the recommentation over all the years
>was "... don't do that. Never. Don't touch it or your system will
>explode (sooner or later) ...") ?
No, there was no documentation stipulating that fact.
The only potential problem was for those people stupid enough to
split / & /usr; well, the *real* problem was people changing
/sbin/sh to /sbin/csh which, of course, does not work.
But we've addressed that issue.
This is somewhat of a rehash of the argument against no longer
shipping a statically linked "/sbin/sh", which the external folks
may have missed.
In the end, having /sbin/sh dynamically linked adds about 10 files
to the list of 100s of files needed to successfully boot to single
user mode so the whole statically linked issue was declared moot.
*Nothing* happens when you change root's shell.
>Is any of { bash, zsh, tcsh, csh } POSIX-conformant by default (ksh93
>isn't perfect in this case either but at least it is one of the choices
>which is very close to the specs) ?
This is relevant, how?
Root's shell needs to be POSIX compliant because?
>It is still the default configuration in the installer to create a
>seperate "/usr" filesystem (and still needed for diskless client setups
>or when /usr should live on ZFS/QFS or simply another physical disk).
>And you forgot the jumpstart case (like I did... and I usually try to
>forget this immediately again because it is usually a pain to deal with
>/sbin/sh when you write POSIX-like shell scripts most of the time) ...
If that's the case the installer is broken (and it probably is, I
don't doubt that).
><blink><marquee>DEFINATELY NO</marquee></blink>. At some point we will
>have followup projects and many of them (like SMF) simply need libshell
>in the root filesystem because the consumers live there, too. Moving
>libshell or any of the libraries needed by it to /usr/lib would kill
>most of the follow-up projects. And this would neither help programmers,
>users, admins or writers of jumpstart/startup scripts.
Why? Why do we want to burden these programs with libshell?
All the tools which currently use command line editing use
libtecla; it is installed in /usr/lib so it is clear that replacing
such functionality does not require a library in /lib.
I see no follow-on projects listed in the ARC case so I would
like to know what these are.
The ARC has traditionally resisted "frameworks" which did not
have consumers; I see no concrete examples of such consumers.
And what is preventing these followon projects to move the library?
What is the relevance of jumpstart here?
It's a crying shame that the miniroot is now 155MB and climbing; but
/usr is part of it and putting ksh93 in /sbin is not relevant.
Casper
