Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

In my .bash_profile, executed for both my interactive and non-interactive logins are

BASH_ENV=$HOME/.myinteractivestuff
export BASH_ENV

doing this for bash on Linux works fine, but on Solaris is not sourced:

bash --version
GNU bash, version 3.00.16(1)-release (sparc-sun-solaris2.10)

Curiously, if I invoke screen within my login shell, BASH_ENV is then read. Are any restrictions on when $BASH_ENV is respected on Solaris? In my case I'm logging in with ssh using putty, but also tried unix to unix ssh, and telnet and see the same.

Note that I know that my BASH_ENV variable assignment is being executed since I can echo this variable after login without any trouble (ie: ruling out the obvious possibility that my .bash_profile is also not being read).

share|improve this question

2 Answers 2

up vote 1 down vote accepted

It's not entirely clear what your expectations are. The bash manual says that the value of $BASH_ENV is only used when executing a shell script but your example suggests you are putting interactive commands in it BASH_ENV=$HOME/.myinteractivestuff.

BASH_ENV

          If  this parameter is set when bash is executing a shell script,
          its value is interpreted as a filename  containing  commands  to
          initialize the shell, as in ~/.bashrc...
share|improve this answer
    
Ah, thanks. So BASH_ENV isn't like ENV in ksh, where it specifies the path that one can use for aliases and other interactive stuff. –  Peeter Joot Nov 15 '11 at 18:31
    
@Peeter Joot: BASH_ENV was designed to provide the same features and usage than ksh ENV, i.e. you certainly can put functions and aliases here. However, setting BASH_ENV isn't going to have any effect on the existing shell. It will only affect subsequent shells. This is true for both ksh (ENV) and bash (BASH_ENV). On the other hand, there is a discrepancy between ksh and bash: ksh runs ~/.kshrc automatically in your login shell while bash doesn't run .bashrc in the same context. An annoyance that is usually corrected by sourcing it (if it exists) in .bash_profile. –  jlliagre Nov 17 '11 at 23:06

You are saying the BASH_ENV variable is set under Solaris, which means the two lines you posted are working correctly. The only thing they do is setting an exported variable and you confirm it's done.

If set, BASH_ENV is run when launching a bash shell script. That means if ~/.myinteractivestuff is run under your Linux environment, either you run some script elsewhere after BASH_ENV is set or you explicitly source it somewhere in your startup script.

By the way, you could have written the simpler:

export BASH_ENV=~/.myinteractivestuff

share|improve this answer
    
You are right. It looks like I had (on linux) a .bashrc symlink to the path specified in my $BASH_ENV and removing that on Linux I see the same thing. The new question is why solaris doesn't source my .bashrc, since I'd also done that there. –  Peeter Joot Nov 15 '11 at 18:34
1  
.bashrc is not executed for login shells or if bash is called sh. How do you starts your shell sessions ? –  jlliagre Nov 15 '11 at 21:01
    
It does appear to be executed for login shells on Linux though (in both cases, I'm logging in with putty over ssh, but Unix-Solaris ssh or telnet shows the same no .bashrc execution). –  Peeter Joot Nov 16 '11 at 14:20
    
That would be a bug on the linux side then. As documented, .bashrc is not to be run during the initialization that occurs for example with an ssh login. After being logged in on the Solaris box, enter the bash command to start an interactive shell which is not a login shell and .bashrc will be sourced. –  jlliagre Nov 16 '11 at 15:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.