Re: su - doesn't source .profile

[Mike Castle]

Please note I've added bug-sh-utils just in case.

On Tue, Oct 31, 2000 at 03:09:46PM -0500, Chet Ramey wrote:
> > Machine Type: i386-pc-linux-gnu
> > 
> > Bash Version: 2.04
> > Patch Level: 0
> > Release Status: release
> > 
> > Description:
> > su - user -c 'echo foo' does not source .profile.
> 
> If this is important to you, uncomment the definition of
> NON_INTERACTIVE_LOGIN_SHELLS in config-bot.h and rebuild bash.

First, thanks for getting back to me, especially so quickly.  I thought for 
sure I'd messed up my email address on the bug report.

Second, just for archive's sake, it's config-top.h.

While this is important to me, it is also what the documenation suggests:

Invoked as an interactive login shell, or with `--login'
........................................................
   
   When Bash is invoked as an interactive login shell, or as a
non-interactive shell with the `--login' option, it first reads and
executes commands from the file `/etc/profile', if that file exists.
After reading that file, it looks for `~/.bash_profile',
`~/.bash_login', and `~/.profile', in that order, and reads and
executes commands from the first one that exists and is readable.  The
`--noprofile' option may be used when the shell is started to inhibit
this behavior.



Similar wording exists slightly below that for when called as /bin/sh.

Since GNU su makes an explicit decision not to call itself as -su, and this
makes bash work incorrectly, there is a bug somewhere.

I hate to suggest it, but perhaps GNU su should set up another mechanism
for indicating itself for bash.  Then again, what happens when GNU su does
not use "-su" on a system that uses traditional Bourne shell?  (Hmm.. I
guess I could look at the ksh source to see if it causes any problems).

The following code from shell.c definitely makes bash behave differently
depending on if it's running on a system with GNU su or not:

set_shell_name (argv0)
     char *argv0;
{ 
  /* Here's a hack.  If the name of this shell is "sh", then don't do
     any startup files; just try to be more like /bin/sh. */
  shell_name = base_pathname (argv0);
  if (*shell_name == '-')
    shell_name++;
  if (shell_name[0] == 's' && shell_name[1] == 'h' && shell_name[2] == '\0')
    act_like_sh++;
  if (shell_name[0] == 's' && shell_name[1] == 'u' && shell_name[2] == '\0')
    su_shell++;

This behavorial difference could cause potential porting problems of
scripts.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen