Migrating shell scripts
Home > IT Answers > Microsoft Windows > Migrating shell scripts
Chunter
110 pts.
0
Q:
Migrating shell scripts
Migration, SQL, Unix, Shell scripts, Scripts, SQL scripts
We have to move more than 250 shell scripts from a unix to a linux environment, and also 100 sql scripts.

Could you please give me some steps or a check list to follow to migrate these from unix to linux?
ASKED: Jul 29 2008  4:35 PM GMT
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
RELATED QUESTIONS
0
Nopius
115 pts.
0
A:
 RATE THIS ANSWER
0
Click to Vote:
  •   0
  •  0
  • AddThis Social Bookmark Button
The problem with shell scripts usually in that they have too many dependencies on external programs, their output, OS specific behavior. The shell syntax itself is hardly a problem.

There is no easy way to migrate. My scenario would include:

1) Learn syntax of the shell (man shellname). You should understand everything in your shell script before migrating. What, why and how every command works and what do you get in result.
2) Determine what shell was used in previous unix (BTW what kind of Unix)? It can be CSH, TCSH, SH, BASH, ...
3) Determine what external programs where used in every script (every command that is not described in manual page for that shell is an external program). Do they exist on target system? Do they have the same output/return codes? If not, you should either find a substitution for the command, change shell code or even write your own command (when no substitution available).
4) Some external commands are very OS dependent. I.e. 'sysctl', 'pbind'. You should find either existing analogs or try to redesign your scripts for new OS.
5) Test every script (after reviewing and fixing all dependencies) on target OS.

For SQL scripts if they should be executed on the same type of SQL server there is no much problems. They will work. If the target SQL RDBMS is different, some scripts will probably fail. The sequence of migrating still the same: learn old SQL syntax used in script - learn new SQL RDBMS syntax - understand what script is doing - rewrite it - test it. Not easy and not quick.

For complex 250 shell scripts all the process can take months or even failure to migrate (when no substitutions for commands or no SQL functionality exists on Linux).
Last Answered: Aug 3 2008  10:32 PM GMT by Nopius   115 pts.
  •   
0
0
RSS - Discussions Help
Discuss This Answer:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _



_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Petkoa   1005 pts.  |   Aug 4 2008  10:39PM GMT

Hi Chunter,

You got a nice advice from Nopius - I’d underline the importance of the last step (#5 :o)).

Some points where I recently got problems:

(1) It’s frequent practice to place /bin/sh in the she-bang (#! … in the first line of the script) of the shell scripts. /bin/sh is usually a link to the default shell and the default shells are different under different unix and linux flavors. Couple weeks ago I hit such a problem with an installation module of a commercial package with code suitable for SGI Irix and linux - it appeared that the /bin/sh in Irix (and I believe in some other unices too) points to ksh (Korn shell) which is quite unusual under linux and some distributions lack it (mine too :o((). So be sure to find out what /bin/sh is and to download and install the actual shell if your distribution does not have it.

(2) Directory structures could differ - and even worse, one can decide to optimize directory structures for some reason and forget to change scripts which depend on these structures - this happened to me couple of days ago (btw, without any migration).

Good luck,

Petko

 
0