[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shell script migration from Unix to Linux
Re: Shell script migration from Unix to Linux
Sat, 28 Apr 2012 15:38:58 -0600
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
> Users may be ok to modify the first line in the scripts.
> #!/bin/csh -f
> #!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.