Shell commands

[simonk_1]

The issue is :-

We recently migrated an UNIX/Oracle app to a bigger more powerful alpha server.
The databses was imported and the home/app owner/ directory tarred and untarred. This contains all the profiles and s/w for the app.

A script which uses 'which' to confirm a ksh scripts location, and which runs in the live copied from environment, fails when run by the application.

cutting the commadn from the log and manually running the ksh script succeeds as does runnning the which comman form the commadn line.

Any ideas.

PS we have checked the environment, passwd file - no dif between the original env and the migration env.

[Ivan Ferreira]

If you run the script manually what is the error?

Use cat -e to verify that there are no non-printable characters and new lines that may be causing problems with the script.

Ensure that the path to the shell specified in the very first like of the shell is correct.

Ensure that the PATH variable is correct.

[Han Pilmeyer]

Did you do the un-tar with the "p" option?
It's likely that some of the protections are not the same. Which searches your PATH to find executables. If the transferred files are not executable, which won't find them. Also note that the Oracle binary normally has a sticky bit which may not have transferred correctly.

[simonk_1]

Thanks all who responded.

A little bit more has come to light.

It appears that the job is run by a management daemon which either doesnot set the SHELLvariable to /usr/bin/ksh or unsets the same.


Step 007 LOG + /usr/bin/which BatchLoader
Step 007 LOG SHELL: Undefined variable.

the same can be generated form teh commadn line by unsetting the SHELL

has anybody suffered similar?

[Ivan Ferreira]

Can you modify the script to specify the full path to the command and avoid the use of which or define the SHELL variable? Or do you already have it working by now?

[simonk_1]

We have a workaround which does just this Ivan. It's a stupid way of determining that a file which has been installed is there - test -n? would have been better.

Thanks for responding.