Please help - HP-UX 11.00 shell

[Albert Luong]

Hi all,

I have a script written in bourne-shell to create symbolic link to a file passed in as an arg.

The script is called repeatedly and works fine for anywhere between 12-24 hours; after which, the shell return an exit status of "1", with the following error msg captured on the stderr:

The specified number is not valid for this command

I changed the shell to "ksh" and get the same result, with a different msg:

bad number

The script ends with a "exit 0" command. I inserted msg logging in the script, a startup msg at the begining and an exit msg at the end, and I always get a matching msg pairs on the scipt execution. This means that when the shell fails, the script did not even get to execute at all.

Anyone got any ideas on what could cause this problem?

what cause the shells (bsh & ksh) to return 1 with a "bad number" or "invalid number" msg?

Any fix/patch on shell?

Thanks

Albert

[Trevor Dyson]

Hi Albert,

-> I have a script written in bourne-shell to create symbolic link to a file passed in as an arg.

Check the argument filename for embedded spaces or special characters.

->The script is called repeatedly and works fine for anywhere between 12-24 hours; after which, the shell return an exit status of "1", with the following error msg captured on the stderr:

->The specified number is not valid for this command

One condition where this error is generated is when in incorrect value type is assigned to a variable, eg assigning a string to an integer varable eg:

$ typeset -i var
$ var="text"


->I changed the shell to "ksh" and get the same result, with a different msg:

->bad number

->The script ends with a "exit 0" command. I inserted msg logging in the script, a startup msg at the begining and an exit msg at the end, and I always get a matching msg pairs on the scipt execution. This means that when the shell fails, the script did not even get to execute at all.

It may be a problem with the argument passed to the script.

->Anyone got any ideas on what could cause this problem?

If you post the script and the command line and arguments used to execute it then I can help further.

Cheers, Trevor Dyson

[Philip Chan_1]

Hi Albert,

Your program may have been running out of user limits (ulimit), try printing that out at the end of each call to your program then see what those values are for your last successful call.

Regards,
Philip

[Dan Hetzel]

Hi,

How is your arg generated? Are you using any 'date' function ??
It really seems that, at a given time, your argument is wrong or contains invalid characters.

Could you post the part of the script which is generating the argument?

Dan

[Albert Luong]

Thanks guys,

I am not sure what are the args values passed to the script when it fail.

The script is called by a 3rd party vendor application, which is designed to transfer file from a remote server onto the HP server.
The application periodically polls the remote server for existing file to be transferred; when a file is found, it FTPs the file over, and then invokes the script passing along 5 args, one of which is the transferred file.

I do not have access to the apllication source code.

I have attached copy of the scripts herein.

I checked the "ulimit" as Philip suggested, the value is "unlimited" on our system.

Thanks

[Adam Fairhall]

To find out what arguments are being used, try the following with your other logging.

echo "$@" >> somefile

If as you say the script is not being executed at all when it fails you may want to use a wrapper script to do your logging then call the actual script. ie rename your script, create a new script with the old name and move all your logging into the new script. Call the problem script with

<scriptname> "$@"

if you still get matching pairs on the log times and nothing wierd in the arguments then I would begin to suspect the calling application.

[Bill Hassell]

If you can modify the shell script, add the line:

set -x

and then when running the script, make sure stderr is redirected to stdout (ie, 2>&1) and now you will have a complete trace of the script's execution. Usually the 'bad number' message is found in a test such as an if statement where an all-numeric value is expected but instead the value is alphabetic or blank or mispelled. The trac will look something like this:

if [ = "ok" ]

AS you can see, the first parameter is missing which is exactly what happens if a mispelled parameter is used in a test. I avoid this completely by using:

set -u

which forces the script to stop running when an undefined variable name is used. (all scripts should use this option).

[Dan Hetzel]

Hi Albert,

You could place the following statement at the beginning of your script.

echo " Arg1: \"$1\"
Arg2: \"$2\"
Arg3: \"$3\"
Arg4: \"$4\"
Arg5: \"$5\" " > /tmp/script_args$$

Every time your script will be run, a new file will be created, containing the PID of your script (that's what $$ is used for)
Don't forget the double quotes to be able to see exactly what the arguments are.

One of your argument may contain white space, which could shift all the following arguments if it's not quoted properly.

example: prog a b c d e
is not the same as: prog a "b c" d e
First one has 5 args and second only has 4

My 2 cents...

Dan