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
