Conference turris::digital_unix

The first thing I do when I install any system is to change root's shell to 
/bin/ksh and put "set -o emacs" in /.profile. The only side effect I've ever 
seen is that single-user mode (with /bin/sh) doesn't like the "set -o emacs", 
but who cares?

As far as POSIX goes, the top of sh(1) says:

  sh - Shell, the standard command language interpreter

STANDARDS

  Interfaces documented on this reference page conform to industry standards
  as follows:

  sh:  XPG4, XPG4-UNIX, POSIX.2

  Refer to the standards(5) reference page for more information about indus-
  try standards and associated tags.

DESCRIPTION

  [Digital]  Digital UNIX provides two command interpreters with the name sh.
  The XPG4 and POSIX.2 compliant command interpreter sh is available in the
  file /usr/bin/posix/sh and is described in the sh(1p) reference page.  The
  Bourne shell, historically known as sh, is available in the file
  /usr/bin/sh and is described in the sh(1b) reference page.

and the top of sh(1p) says

  sh - Shell, the standard command language interpreter (POSIX Shell)

whereas the only mention of POSIX in the ksh man page is a reference to POSIX 
shell sh(1p).

PJDM

    Peter,
    
    Thanks for your reply but it does not answer my question
    satisfactorily.  What I want to hear is any reasoning as to why it is
    either a good or bad idea to have the root users shell something other
    than the default of sh.
    
    Under ULTRIX, a system which did not have sh as the root shell would
    break.  Although there does not seem to be any obviously broken
    behaviour under Digital UNIX, I would like some more proof this is the
    case.
    
    The assumption the /usr filesystem is always available is not a good
    idea, as you yourself point out in single user mode, an error message
    is produced.  Who cares you ask?  I do.  A new customer who is
    umnfamiliar with this system has then been given reason to think
    something is broken.  This I can live without.
    
    Examining the man pages on the various sh references and the setting of
    the BIN_SH environment variable add additional complexities.  For
    example, if the root shell (as defined in the /etc/passwd file) is set
    to /bin/ksh, then it is actually not possible to have a real /bin/sh as
    the behaviour is modified to select the ksh instead.
    
    I would like to be convinced that this situation will not break a
    system either now or later down the track.
    
    Cheers,
    
    Harry E.
     
                                      

>    The assumption the /usr filesystem is always available is not a good
>    idea, as you yourself point out in single user mode, an error message
>    is produced.

/bin is actually a softlink to /usr/bin so sh and ksh are on equal 
footing here. I too have always used ksh for root as do the production 
systems at my site.
			Pete

        Pete,
    
        True and I do not disagree.  It is interesting to note the system
        startup scripts are flagged as #!/sbin/sh as their invokation
        environment.  /sbin contains static images; the only shell to
        reside in here is sh.
    
        Harry E.
    

Concerning ksh and startup

By the time any startup script is executed bcheckrc has mounted all the file
systems at the start of run level 2 so you can use ksh for startup though I
would what it going the otherway down.

Concerning root's shell in /etc/passwd

When the system is in single user it is not the entry in /etc/passwd that 
determines the shell. /sbin/init forks/execs only one shell that is hard coded
in the binary as /sbin/sh. So do what you like to /etc/passwd even deleted it
and you will still get /sbin/sh


All of the scripts supplied in Digital UNIX will run the script that was
intended by the author as determined by the magic for shell interpreters
and not your current shell it does not matter two hoots what shell root is,
unless the script is written to force shell execution via a fork/exec/kill $$
or you explicetly type $SHELL <scriptname>

	The only thing that really break this is BIN_SH refer to my recent
reply in this notes conference which makes sh run either the real sh or ksh
or the sysV sh. There is a bug in ksh that will cause BIN_SH=xpg4 (run ksh)
to fail setld and probably others. It appears to be fixed in 4.x

	Cheers
		Mark :)

> Examining man pages on the various sh references and the setting of
> the BIN_SH environment variable add additional complexities.  For
> example, if the root shell (as defined in the /etc/passwd file) is set
> to /bin/ksh, then it is actually not possible to have a real /bin/sh as
> the behaviour is modified to select the ksh instead.
>
Your example is wrong. The root shell set to ksh does not result in there
being no real /bin/sh  it is the setting of BIN_SH=xpg4 or BIN_SH=sysv
that looses the real /bin/sh behavour since runing /bin/sh or /sbin/sh
with that variable set tells shell to exec /bin/ksh or the sysV shell. 

> Under ULTRIX, a system which did not have sh as the root shell would
> break.

For those of us that may still run ultrix from time to time could you
please elaberate "would break" "Under ULTRIX" this has not been my 
experience and I have been sysadm on ultrix from 3.0 to 4.5 and as long
as there has been ksh it has been my root shell in /etc/passwd


	Cheers
		Mark :)

I've been using /bin/csh as my root interactive shell for longer than I can
remember with no ill effects.  That would seem to imply there's no problem
using ksh the same way.