is not an identifier - ERROR

[Vijayakumar S]

Dear Friends,

I have a script which exit whith the following
error in the log.

./WLAutoLoad.sh: PATH=/usr/oracle/920/bin:/usr/oracle/920/lib:/usr/WebSphere/prd/AppServer/bin:/usr/tm/prd/Alchemist:/usr/oracle/920/bin:/usr/j2se/bin:/usr/tm/prd/Alchemist/nm/bin:/opt/CA/dmscript/bin:/usr/bin:/usr/bin::/usr/local/bin::/opt/gems/CA/atech/services/bin:/opt/gems/CA/atech/services/tools:/opt/gems/CA/atech/agents/bin: is not an identifier

Could anybody help me how to resovle this.

Best Regards
Vijay S

[Peter Godron]

Vijay,
you are using the PATH variable incorrectly within your script.

to debug your script, try:
sh -x WLAutoLoad.sh

[Vijayakumar S]

Peter,

It running perfect when I call it manually. But when i call it by control M automation it giving the error.

Any toughts

Cheers
Vijay S

[Eric Antunes]

Hi,

You have an invalid PATH:

"...:/usr/bin::/usr/local/bin::/opt..."

You should have:

"...:/usr/bin:/usr/local/bin:/opt..."

Best Regards,

Eric Antunes

[Vijayakumar S]

Hi,

But the same script runs on weekly in the Control M and not daily jobs. Is the :: in the path is only the issue.

Best REgards
Vijay S

[john korterman · Accepted solution]

Hi Vijay,

the reason for the error is probably environmental differences when compared to running the script manually. Is user and PATH the same?
Try echoing some variables in your script and compare the result when running it in the two different modes.

regards,
John K.

[rariasn]

Hi,

Verify "sysout" job.

rgs,

ran

[Kenan Erdey]

hi;

cron's and user's environment variables are different. you can trying setting env. variables of your user's env. in your script.

regards.

[Tom Henning]

As I recall when logged in as root under 10.20 the default root shell would not allow lines in the form of:

export PATH=$PATH:/usr/sbin

It displayed the same error message, because the shell did not understand the setting of the variable and exporting it on the same line. These lines were always seperated into two seperate lines:

PATH=$PATH:/usr/sbin
export PATH

Since you did not provide details like HP-UX revision and an extract from the shell script producing the error, this is only a guess.

[Bill Hassell]

As far as: export PATH=
this has been functional in both the POSIX shell as well as ksh long before 10.anything. However, the :: is a very big problem. It means: current working directory, and it should NEVER appear in a PATH statement, especially one that is run from cron or other batch scheduler. The reason is that time-scheduled do not login so they do not inherit any of the the user's environment including the directory at the end of all profiles. Whenever a script works at a login prompt but does not work in a batch job, it is due to missing environment changes that are present when that user logs in.

The quick-fix method is to source all the profiles (for POSIX sh and ksh, /etc/profile and $HOME/.profile) but many sysadmins do not cleanup profiles to protect interactive terminal commands such as tabs, ttytype, tput, etc. This creates extra error messages when the script runs from cron.

The second problem with :: in *ANY* PATH statement is that it is a serious security and reliability risk. Consider what happens if a hacker creates a program and names it su, then stores it in several common directories (accessible by all users). An accidental cd to one of these directories could compromise the root user's password.

As far as the "... is not an identifier" message, this is from the shell and occurs when a string of characters appears on a line in a script that is not a function or variable name. To find the exact failure location in the script, add this:

set -x

just after the first line in the script. When the script runs, it will trace each line of execution to stderr. In cron, the output of the script will be emailed to the user unless redirected.

[Peter Godron]

Vijay,
if you re-read my first posting, you may see my suggestion to debug run your script with -x, which may give you an idea about the PATH problem. Can you please update this thread. If the -x help identify the solution, please details where the problem was.

[Frank_Kortekaas]

Add #!/bin/ksh at the beginning of your script. This should do the trick.

Regards,
Frank