[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: interactive shell is incorrect

From: David Thompson
Subject: RE: interactive shell is incorrect
Date: Thu, 5 Jun 2003 10:27:23 -0700

> From: Paul D. Smith [mailto:address@hidden
> %% David Thompson <address@hidden> writes:
>   dt> BASH_ENV is no, but ENV is yes.
>   dt>   $ echo $BASE_ENV
>   dt>   $ echo $ENV
>   dt>   /home/davidt/.kshrc
>   dt> My login shell is ksh93, so naturally I'm using ENV
>   dt> with ksh, not bash.
> Doesn't matter.  ENV handling is a requirement of the POSIX
> Bourne shell, not only ksh, and when bash is invoked as "sh"
> it behaves like a POSIX Bourne shell, which means it reads ENV.

In this case, Makefile.a invokes make recursively using Makefile.b,
inside Makefile.a I have SHELL=/usr/local/bin/bash on the resursive
make command line, so it is not /bin/sh, it is bash here, I don't
understand why bash reads the ENV in my case.

>   dt> I still think there is a bug.  From my original email, note
>   dt> how this command,
>   dt>     50  $ make -s -f Makefile.b
>   dt>     51  TOPDIR = /home/davidt/tmp/foo
>   dt> is correct, but this recursive make shows incorrect output,
>   dt>     47  $ make -s -f Makefile.a
>   dt>     48  Hello bashrc
>   dt>     49  TOPDIR = Hello bashrc /home/davidt/tmp/foo
>   dt> I don't understand what explains *that* difference.
> Well, one difference is that when you invoke make on Makefile.b, SHELL
> is set to /bin/sh (the default).  When you invoke it recursively from
> Makefile.a, you set it to /usr/local/bin/bash, which is not the same
> thing at all (even if /bin/sh is really bash, bash behaves differently
> when invoked as "sh"--see the bash man pages).
> What is /bin/sh on your system?

On my system, /bin/sh is a symbolic link to bash.

    $ /bin/sh --version
    GNU bash, version 2.05.8(1)-release (i386-redhat-linux-gnu)
    Copyright 2000 Free Software Foundation, Inc.

    $ witch -l bash
    -rwxr-xr-x  1 root  root  1690546 Dec  7  2001 /usr/local/bin/bash
    -rwxr-xr-x  1 root  root   519964 Jul  9  2001 /bin/bash

    $ which bash
    bash is a tracked alias for /usr/local/bin/bash

    $ /usr/local/bin/bash --version
    GNU bash, version 2.05.0(1)-release (i686-pc-linux-gnu)
    Copyright 2000 Free Software Foundation, Inc.

    $ /bin/bash --version
    GNU bash, version 2.05.8(1)-release (i386-redhat-linux-gnu)
    Copyright 2000 Free Software Foundation, Inc.

    $ ls -l /bin/sh
    lrwxrwxrwx  1 root  root        4 Aug 29  2002 /bin/sh -> bash

>   dt> Can you reproduce that behavior?
> No.  I added a line to my ~/.bashrc file:
>   echo "in bashrc"
> Now I run make -f Makefile.a:
>   $ make -s -f /tmp/Makefile.a
>   TOPDIR = /home/psmith
>   $ make -s -f /tmp/Makefile.b
>   TOPDIR = /home/psmith
>   $ ENV=$HOME/.bashrc make -s -f /tmp/Makefile.a
>   TOPDIR = /home/psmith
>   $ ENV=$HOME/.bashrc make -s -f /tmp/Makefile.b
>   TOPDIR = /home/psmith

Interesting, what is your login shell?

> All identical.  But if I set BASH_ENV I see behavior similar to yours:
>   $ BASH_ENV=$HOME/.bashrc make -s -f /tmp/Makefile.a
>   in bashrc
>   TOPDIR = in bashrc /home/psmith
>   $ BASH_ENV=$HOME/.bashrc make -s -f /tmp/Makefile.b
>   TOPDIR = /home/psmith
> Note that on my system, /bin/sh is really bash in disguise.

Yes, my system, too.

>   dt> But I contend that a bug exists (somewhere) because 
>   dt> bash thinks it is invoked as an interactive shell,
>   dt> even with BASH_ENV and ENV unset, so bash sources
>   dt> ~/.bashrc.  Clearly bash is not supposed to be doing
>   dt> that.
> There's definitely a problem somewhere but I suspect it's with your
> environment rather than make.

It seems that if ~/.bashrc exists and produces output, it is the
problem.  I'm not convinced it should be a problem.  I will have to
investigate more to discover why.

> Make very simply invokes "$(SHELL) -c '<command>'", there's nothing at
> all fancy about what it does.  It does not force interactive shells or
> anything else.

Good to know, thanks.

>   dt> I also contend the bug is with make since the behavior is only
>   dt> seen in recursive invocations of make.
> I don't agree with this, necessarily, since you are changing the value
> of SHELL on the recursion.  That could very likely cause the different
> behavior.  If you use identical values of SHELL in both the top-level
> and recursive invocations of make and you still see different 
> behavior, _then_ we might have something to talk about here.

Start talking!  ;)

    $ make -s -f Makefile.a SHELL=/usr/local/bin/bash
    Hello bashrc
    TOPDIR = /home/davidt/tmp/foo

Isn't that wrong?

I'm not a bash user, and this makefile I'm invoking recursively
is not under my control.  I only discovered this because I had
an echo in my ~/.bashrc file.  Forgive me, Paul, but this still
looks like a problem.  Perhaps the problem is bash?

I will look harder at why my results are not identical to yours.
Can you help suggest experiments?

David Thompson
Foster City, CA

reply via email to

[Prev in Thread] Current Thread [Next in Thread]