"tr" command not working properly in test environm

mdbatra · Post by **mdbatra** » Sat Oct 27, 2012 9:59 am

Hi All
we are having an issue in one of the DS env(test) where in "tr" commands in scripts are not getting parsed correctly causing failures.

To deal with that, I made a trivial script that inputs an argument and converts it into uppercase using "tr" (like in actual scripts) as below:

COUNTRY_CODE=$1
which tr
set
echo $COUNTRY_CODE
COUNTRY_CODE=`echo ${COUNTRY_CODE} | tr [a-z] [A-Z]`
echo $COUNTRY_CODE

and it's giving the same error in log, as below:

_=tr
ab
Usage: tr [ -cds ] [ String1 [ String2 ] --where "ab" was the input argument to script.

"tr" works fine as such on unix. Also, exported job to UAT and it works fine there. The only difference i could see is that in UAT, it runs as bourne shell(sh) while in test, it runs as ksh. Default shell on both servers is ksh but dsenv file is setting the default as bourne(using and both dsenv files are same(being generic).

Have couple of questions here:
1. what could be the reason that shell is not set to bourne in test env?
2. when i see the 'enviornment variable settings' event in log: I see shell only in test(as ksh) but SHELL variable is not thrown in UAT. I had to use "set" in the test script(as above) to see what shell is being used. why is it so ?

any help would be appriciated.

ray.wurlod · Post by **ray.wurlod** » Sat Oct 27, 2012 4:15 pm

Try using the [:lower:] and [:upper:] classes instead.

The default shell is set in the operating system, via the SHELL environment variable and via the login process (in which case the SHELL environment variable may not be set). Check the .profile script for the user under which connections are made, as well as the global /etc/profile file. Presumably your two systems have been set up differently.

Different UNIXes have different defaults, too, for example the Linux default is bash (Bourne again shell). So, if your environments are different UNIXes...

mdbatra · Post by **mdbatra** » Sun Oct 28, 2012 4:47 am

Hi Ray

problems are:
1. already, around 70-80 scripts are in place which use the "tr" in some or the other way. Hence, even in [:lower/:upper] works in that trivial script, it would be a pain to do same in all the others existing. Looking if something could be done w/o change in scripts, at unix or DS level.

2. Changing of scripts would leave the test env out of sync as compared to UAT/PROD environment , unless all scripts are migrated and tested again in both the later environments.

On a different note: guess, have survived on free membership for quite long but high time for premium membership now

please let me know within how much time it could be acquired?

mdbatra · Post by **mdbatra** » Sun Oct 28, 2012 5:06 am

ah, i see it as 48 hrs, fine with me

have applied for it now. waiting eagerly

tonystark622 · Post by **tonystark622** » Sun Oct 28, 2012 10:28 am

You can set the shell that will execute the script by putting a line at the top of the script.
#!/bin/sh
Or
#!/bin/ksh

mdbatra · Post by **mdbatra** » Sun Oct 28, 2012 10:46 am

hi Tony...surprisingly, that line is already there...but somehow not not being able to set

tonystark622 · Post by **tonystark622** » Sun Oct 28, 2012 11:15 am

Are you saying that even though it's there, it's not using that shell? Or that you cannot change the line in the file? Or something else?

chulett · Post by **chulett** » Sun Oct 28, 2012 3:55 pm

For grins, verify that that is indeed the actual location of the shell on your O/S.

mdbatra · Post by **mdbatra** » Mon Oct 29, 2012 12:31 pm

Hi Tony-- yes, I meant it's not using that line ( to set to bash shell) somehow even though it's present there(as a standard it's there in each and every script for the project )

few other observations:
1. .profile and .dsenv are same across all the projects (ST/UAT/PROD)
2. few other ST projects exist on the same server as of the problematic project. If I login to a different project but using same generic user id and run the same job/script (after importing from the actual ST project) , it runs perfectly fine

so it has come narrowed down to a project level issue rather than a server/login/shell related issue.

any clues, why ?

mdbatra · Post by **mdbatra** » Mon Oct 29, 2012 12:34 pm

Hi Craig...i verified that as well...it is indeed.

rameshrr3 · Post by **rameshrr3** » Tue Oct 30, 2012 3:55 pm

did you check if there is anything in the $HOME/.profile file of the user id ( unix id ) used to run jobs in the troublesome project ?