is there a way to alias PATHs?

[highcountry]

maybe this isn't the right way to phrase the question, so here goes the problem.

I'm attempting to port quite a few custom ksh (scripts) code from an AIX platform to Redhat/Centos. I do NOT want to make a lot of changes to the Redhat/Centos base OS system(s), because I want this to work on any Redhat/Centos that I put it on. I'd rather write an 'alias' script that I can place in /etc/profile.d/ that will solve the PATH difference problems.

The problem is PATHs is that the AIX ksh script(s) have hardcoded paths for the unix commands (ie. /usr/bin/date) that they run. I have a list of about 15-20 command paths that I'd like to write an 'alias' script to handle.

I'd like any script on the Redhat/Centos system to resolve that /usr/bin/date is really at /bin/date.. (as well as dozens of other PATH differences). I was hoping that I could write a /etc/profile.d/ script to handle these conditions, so that any user logging in could run the AIX ksh scripts. I DO NOT want to manually make links for every command (ie. ln -s /bin/date /usr/bin/date).

Is there a way to do this?

[Irithori]

hi

I agree on your decision not to mess with the system.
This would be just plain ugly and -as you have written- you would need to do it on every redhat/centos again.

Unfortunately, re-defining $PATH will not help either, because your scripts use absolute paths.

I would suggest to re-write these scripts a little bit.

grep them for "bin" and create a list of any binary called.
Then define variables for each binary, aka

DATE=`which date`

and replace any call to /usr/bin/date with $DATE

And while you are at it, it might be worth checking if the tools support the same arguments and options on both platforms.

Definitely not a fun job.

[highcountry]

I understand what you mean about cross platform command arguments, but I'll have to cross that bridge when it crops up.

Your solution is certainly a valid option, but not in my case. You see, the AIX ksh scripts are all in svn. My boss doesn't want wholesale modifications on the AIX side, because people will still be using these on the AIX side.

So I'll save the option of modifying the AIX scripts, as a last resort. Besides that are hundreds of scripts.

thanks,....

[Irithori]

Well, what options are there?

1) copy each AIX script and write a CentOS/RedHat variant.
- huge effort, as any script needs to be analyzed.
- *for sure* the "twins" will diverge over time. Not good.

2) softlink the tools into the expected location. But via RPM package.
You would still need to modify each CentOS/Redhat, but at least in a controlled and simple way.

yum install highcountrys-aix-transitional.rpm

And it is easy to clean up. Just de-install the RPM.

That said: The "mess the system" idea is still ugly as hell.

Also, you will enter the Catch-Up contest:
Whenever someone changes a AIX script, there is a chance, that you also need to modify that RPM. (aka new tool used)

3) rewrite the scripts in a portable way.
That would of course mean: keep the AIX compatibility.

You have svn. Good.
So it is always possible to have a working version.
Maybe branch a "portable tree" and use it on both AIX and RedHat/CentOS test systems.
I understand that this doubles the test effort, but 3) would be my choice.

[highcountry]

you make valid points ... but I think I'll still search for a 'work-around'

I'll elaborate a bit;

1). the AIX scripts (hundreds of them) are all in a mutually avalaible svn repository (available to both AIX and Redhat/Centos). There are also multiple svn respositories (on different servers).

2). There is one 'master' build script (that I've fixed the PATHs for Redhat/Centos) that will be used to install any one of the hundreds of AIX scripts.

3). The 'master' build script accepts arguments for the svn server's name and for the repository name. There are also command line arguments 'piped-in' to the 'master' build script that specifies which of the hundreds of scripts to download (from svn), and build/make/ant.

The task of making a separate "Redhat/Centos" version is out of the question. I hope this makes sense.

I was really hoping that there was an easy way of accepting /usr/bin/data as vailid path.