"tr" command not working properly in test environm
Moderators: chulett, rschirm, roy
"tr" command not working properly in test environm
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.
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.
Rgds,
MB
MB
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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...
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...
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
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?
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?
Rgds,
MB
MB
-
- Premium Member
- Posts: 483
- Joined: Thu Jun 12, 2003 4:47 pm
- Location: St. Louis, Missouri USA
-
- Premium Member
- Posts: 483
- Joined: Thu Jun 12, 2003 4:47 pm
- Location: St. Louis, Missouri USA
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 ?
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 ?
Rgds,
MB
MB