Re: Function visibility

[Stephane Chazelas]

On Tue, Oct 02, 2007 at 01:43:05PM -0600, Bob Proulx wrote:
[...]
> 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
[...]

Note however that it's no longer true of ksh93 and it's not true
of many newer versions of ksh88 as that is a POSIX
non-conformance, so you should no longer need that kludge
nowadays.

And note that POSIX shs are meant to handle $ENV when
interactive and the above code is not POSIX conformant (but it's
not likely to cause any problem).

[...]
> > (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.

When I need a feature that a POSIX shell can't provide, then
generally that means I need something more like perl or
python...

Note that #! /bin/sh will not always give you a POSIX shell.
Sometimes, it may give you an ancient shell that your Unix
vendor keeps there for backward compatibility. "sh" has been a
lot of different shells along Unix history...

-- 
Stéphane