George Thomas Irimben (georgeti) wrote: > Due to incompatibility of commands/arguments and behavior, shell script > migration from Unix to Linux OS is a nightmare for many.
This really isn't specific to a Unix to GNU/Linux migration. This is an old problem that has been around forever. Note all of the years when System V and BSD systems were different. And all of the years of SunOS, Solaris, HP-UX, IBM AIX, and many others were all slightly different. It is the same thing because people are still writing software and even though details have changed, people are people and people haven't changed any. These differences were the entire reason that POSIX came to exist. It was meant to document the existing practice such that it could be understood. By standarizing on behavior it would prevent future systems from being yet again different in incompatible ways. If you programmed to the portable layer then you could have some hope that it would work across systems. And having participated in the discussions over the years I know that systems would have diverged uniquely all over the place if POSIX had not existed to keep them mostly the same. > Is there any Wrapper Shell or other utilities existing in Linux, to help > script migration from Unix to Linux? > > This unix2linux shell should hide the behavior/output differences and > make the Unix scripts run seamless on Linux. As far as I know there isn't any magic shell to help you in this task. Perhaps you might be motivated to make one? There are some best practices that will help you. But there isn't a wrapper layer that will help. > Users may be ok to modify the first line in the scripts. > Example: > #!/bin/csh -f > to > #!unix2linuxsh /bin/csh -f I think that would be quite hard and invasive to require a modification of every shell script. And then of course that shell script could not run on your previous Unix system. For example right up front here you have specified two arguments on the #! line. Most Unix kernels will only accept exactly one argument. Therefore this can't work on a Unix system. And here you are using a csh script! (shudder) Please save me from that sight. In which case your "sh" ending should be "csh" instead since csh is quite different from sh. Also let me remind you that Linux is a kernel. Most shell scripts have little interaction with the kernel. Therefore saying something like "unix2linux" really makes no sense. I am not even sure it is possible to do this. On a first idea some type of LD_PRELOAD library might be able to adapt some of the behavior. But it would be very tedious and would introduce yet another layer of uniqueness. By the time you have done this it is better simply to have fixed the script to be portable in the first place. I wouldn't do it. > Any pointers? I have done a *lot* of shell script porting over the years. Personally I find it easier in the long run to improve the scripts to be portable shell. It is more work up front but less work in the long run. Then it works here, there, everywhere. Of course I know there are several large problems with porting legacy Unix programs forward. Let me list some of them. * The original authors are long gone. No one left around knows anything about the existing program. They would need to learn them the hard way by reading the scripts source code. * If anyone is skilled enough to do this port they will find terrible things in the legacy code that need to be rewritten. For anyone skilled enough to do this they will be compelled to rewrite large sections of the code. This is good. But it takes effort and it opens the project to a large number of new bugs. * There aren't any tests. This is the biggest problem. Because any change you make is risky without tests to help verify that the result is as desired. * Remove any hard coded path. Call programs using PATH. I have seen many portability problems due soley to "/usr/bin/grep" being used instead of "grep". Even simple things like "basename" is trouble. Use PATH and avoid hard coded paths. * The differences really are not in the shell. The shell is pretty simple and it is easy to have code that runs in a multitude of shells. Your example above is csh and you would simply install csh and use it. That isn't the problem. * The differences are in the utilities and other commands called from the shell script. Options are different. For example 'cat -s'. On some systems the -s is for silent. On others it is for squeeze. Even 'echo' the simplest of commands is very unportable. If you ever see an escape sequence, a "\c", a -e, a -n, or anything like that then you should remove it from echo and use 'printf' instead. The echo command is only portable when used simply. These are simply classic problems that must be avoided but people trip up into them again and again and again. You didn't list any specific problems. If you have any specific issues please feel free to post them. Perhaps we can suggest a good solution for you as you go along. But there isn't any solution other than to work through it. Bob
