Re: bash exit command should be unconditional

[Bob Proulx]

Greg Wooledge wrote:
> Vadym Chepkov wrote:
> > A company I work for is trying to migrate their applications to
> > Linux platform and have selected RedHat as the vendor. Redhat
> > installs bash as the standard shell :
> 
> > $ ls -l /bin/sh
> > lrwxrwxrwx 1 root root 4 Jul  7  2009 /bin/sh -> bash
> 
> Migrating FROM something that used Korn shell, I presume?  Why not
> just install Korn shell and use #!/bin/ksh on your scripts, if you need
> to rely on Korn shell features?  It would probably be easier than porting
> all your scripts from Korn to POSIX/bash.

When I read this I was torn about suggesting that ksh should be
installed.  It would almost certainly allow the legacy scripts to
work.  But then you would probably have system scripts that have come
to expect bash as the /bin/sh and now don't have it.  Those would need
to be patched.  Probably fewer of them though and all of them are also
buggy by definition and could be fixed.  From personal experience I
know that there might even be more support in fixing them than fixing
a companies own scripts.  Free software gets publicly review while
company scripts do not.

What Vadym describes is the work of "porting" an application to a new
system.  Fixing scripts and C code and all of those things are what
the job of porting entails.  And I say this from experience.  I have
ported applications from one system to another many times.  I favor
porting the application so that it then runs on either platform.  This
makes the application better.  Conversely I have often modified the
system to make it more like another so that applications can run.
Making 'basename' appear in both /bin and /usr/bin so that hard coded
applications calling it with a full path can run on either system.  It
is sometimes the easiest way to go.

But this is a pretty heavy system modification and requirement.  What
if there is another large set of scripts that requires that /bin/sh be
a different shell?  Which one gets to be the immovable object and
which gets to be the irresistible force?  Because it can't be both
ways.

But having said all of that I guess installing ksh as /bin/sh is
probably the path of least resistance here.  Because if you are
hitting this problem then you will almost certainly hit other problems
such as the one of bash echo not expanding escape sequences.  (Bash
FAQ E5.)  Legacy scripts coming from a SysV environment often depend
upon that too.  (Fortunately that is an easy mechanical change to fix.)

Also, with this new information about the goal, my previous suggestion
of using a bash specific redirection isn't good.  I suggested it for
/bin/bash specifically and not /bin/sh linked to bash.  The redirect
syntax would fail if /bin/sh is linked to either a POSIX shell or
Bourne shell.

Unfortunately when porting applications there are no paths available
that don't entail some amount of work.

Bob