On Wed, Aug 26, 2009 at 05:45:18PM -0400, Stephen Adler wrote:
> I'm writing a bash script which I would like to execute the same script 
> on a linux and a solaris system. but my problem is that the bash 
> executable is in /usr on linux and /usr/bin on solaris. 

If your script does not make heavy use of bash-specific functionality,
you're almost always best off to *not* invoke bash as bash in a shell
script, especially if your script is intended to be used by others.
Here's an example of why:

Bash, when invoked as bash, looks for the variable $BASH_ENV and
sources this file whenever it starts in non-interactive mode (i.e., a
shell script).  Suppose you have a program that purges the invironment
of possibly dangerous environment variables, and in the course of
doing whatever it does, it runs a shell script.  Your script, invoked
as bash, finds the $BASH_ENV variable, and sources that file, quite
possibly re-setting the environment variables that were culled from
the environment.  In a security-sensitive context, this could
potentially be a serious problem...

But it's actually worse than that, even.  Suppose you implement the
"which" command as a bash script (as Debian sarge did, originally).
Then, a user puts something like this in his .profile:

export BASH_ENV="my_env_file"
vi=`which vi`

And in my_env_file, the user also has something like:

vi=`which vi`

Can you guess what happens?  I'll give you a hint:  The result is very
probably that the system will become unusable moments after the user
logs in, unless the system administrator has taken measures against
such problems.  I actually did this to two production servers in my
first week at my current employer.  

FWIW when bash is started, the specific files which it reads on
start-up, and the specific order in which they are read, varies in
different contexts, and can be extremely confusing.  See the
INVOCATION section of the bash man page for all the hairy details.
Also note that if your or .bashrc has commands in it that produce
output to your terminal, then very likely if you scp files to that
machine, the scp will fail.  Put such things in .profile or
.bash_profile instead.

On Fri, Aug 28, 2009 at 12:36:41AM -0400, Matthew Gillen wrote:
> On 08/26/2009 05:49 PM, David Rosenstrauch wrote:
> > Can't you just use:
> > 
> > #!/bin/sh
> 
> No, because that shell hasn't been bourne again! :-P Strictly
> speaking, 'bash' is a superset of 'sh'.  Some linux systems make
> 'sh' a symlink to 'bash', but not all (ubuntu IIRC is one that
> doesn't), and solaris certainly doesn't.

But you, as the system administrator, can do this (if indeed you are
the system administrator).  Ubuntu even has a semi-automatic way to do
this, though I forget off the top of my head what it is.

Speaking from a portability perspective, these days, most Unix systems
have the actual Bourne shell hidden away somewhere, and /bin/sh is
actually the vendor's implementation of the "Posix" shell, which is
very bash-like (and often enough is actually bash).  Debian and
debian-derived Linux distros are notable exceptions; one of many
reasons I generally prefer not to use such systems: In my experience,
Redhat-derived systems tend to behave more similarly to other Unix
variants, whereas Debian always seems to do its own thing, evidently
just to be different (one sometimes wonders if the maintainers are
disgruntled former Microsoft employees)...  But I digress.  As I
mentioned, you can change the default shell easily enough on Debian
(even if you can't figure out the "debian way" you can do it manually
with one command).

> From the school of hard knocks: unless you're an expert 'sh'
> programmer, don't develop scripts that start with #!/bin/sh on
> fedora and the like, since you can't be sure they'll work on systems
> that actually use the shell you're telling it to use.

Obviously, I disagree. :)  The better option IMO is to learn to write
portable shell scripts, and use /bin/sh.  But, it depends on what your
goals are...

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.