Stephane Chazelas wrote:
> However note that the file pointed to by the BASH_ENV
> environment variable is sourced even by non-interactive shells
And while that feature can be useful it can also break working
scripts. Therefore I try to ignore that this feature exists and hope
that no one (ab)uses it.
The AT&T ksh uses $ENV for the same purpose but does not automatically
source a kshrc file. Therefore a very common configuration for the
typical user in their profile is to set ENV=$HOME/.kshrc and use it
for all of the same things that we use a bashrc file. But this
creates problems for '#!/bin/ksh' scripts that then have $ENV set
because for ksh even non-interactive scripts source $ENV.
The documented way to avoid this problem is to conditionally set the
value of ENV. The Bolsky & Korn, The KornShell documents this
following snippet.
export ENV='${FILE[(_$-=0)+(_=1)-_${-%%*i*}]}'
export FILE=$HOME/.kshrc
That version had some problems though and I used this alternative to
work around them.
export ENV='${START[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}'
export START=$HOME/.kshrc
The worst part is that the user is responsible to configure this
correctly. Incorrectly done and this breaks scripts that would
otherwise work fine. Because $ENV is sourced before the script is
executed it is quite difficult for the script to workaround.
The point of all of this is that this particular feature may sound
like a good idea but in practice has caused problems and we have the
experience of using these other shells to learn from here. Look at
the complexity added by the above. The experience was not good and
IMNHO it is better to avoid the feature.
> (as long as bash is not called as "sh" or with --posix or with
> POSIXLY_CORRECT or SHELLOPTS=posix in its environment)
One reason that although I prefer bash as my command shell I always
use '#!/bin/sh' for scripts. The benefits of a standard environment
outweigh the benefits of nice features most of the time. When I need
or want the feature then of course I use '#!/bin/bash' as required.
> So, putting function definitions in /some/file will make those
> function available to all non-posix bash instances that receive
> BASH_ENV=/some/file in their environment.
Shh... Don't tell anyone. Someone will (ab)use it. :-)
> Now, I'd agree with you you probably don't want to do that, and
> the most sensible thing is to source your shell function library
> file from your script.
Agreed.
Bob
