Old UNIX shell code may never die
We recently started a project to move our BW landscape out of our datacenter, and go from an Oracle database to that SAP one. It is inevitable, based on SAP’s road map, though the timing of system migrations depends on factors well beyond me. This post concerns UNIX code that runs in support of our flat file data transfers, among other utilty purposes.
When I started in the SAP world, my company had just migrated from the Digital Equipment Corporation VAX VMS environment on Oracle to Digital UNIX. As I had background in both database and UNIX administration, I straddled both camps, and became somewhat knowlegeable about the Basis team. Our company had set a standard for UNIX shell code to be ksh. Not plain old sh, not that other coast csh, ksh only. I had already had experience in obscure UNIX platforms such as PrimeOS, Unisys (System VR2 and VR3), SCO UNIX, and my still-favorite free operating system NetBSD, with its cousin-in-fork FreeBSD.
It wasn’t too long after I got my feet wet and my head wrapped around SAP on Oracle on Tru64, that I started writing shell scripts. Not many, but enough to help in my role. I also asked for, and was granted, the chance to build and deploy the bash shell. Not too many others adopted that, but occasionally I will see a bash process running.
The ksh standard seemed to be fine, up until a few weeks ago, as we prepared our plans to move the OS underneath BW from AIX to SUSE Linux. I have also used a few different Linux flavors in roles outside the office, or in beta testing of enterprise software such as AutoSys. We discovered the typical Linux distribution does not include ksh. You can get it, but bash is the usual suspect.
So, what are the choices? Do nothing seemed to be one option. Get a ksh source code and ask the hosting company to deploy it was another. That did not seem like a great idea in these times of “return to standard”, and my new favorite acronym “CCLM”.
Here is the problem:
#!/bin/ksh # rest of code
The “rest of code” does not matter if the first line kills the shell script, which is what happened in our test Linux host (not necessarily SUSE, but a similar level kernel).
As we had already deployed bash in our environment, changing the code to run that instead seems like the expedient approach.
#!/bin/bash # rest of code