Please find below the content of .cshrc file under location /oracle/C38
0:root@dehensv215:/oracle/C38 # cat .cshrc
# @(#) $Id: //bc/701-1_REL/src/ins/SAPINST/impl/tpls/ind/ind/SAPSRC.CSH#1 $ SAP
# necessary to get hostname without domain (AIX, OS/390 and NOT sun)
switch (`uname`)
case AIX*:
alias hostname 'hostname -s'
breaksw
case OS/390*:
setenv _BPXK_AUTOCVT ON
setenv _TAG_REDIR_IN TXT
set _TAG_REDIR_IN=TXT
setenv _TAG_REDIR_OUT TXT
set _TAG_REDIR_OUT=TXT
setenv _TAG_REDIR_ERR TXT
set _TAG_REDIR_ERR=TXT
alias hostname 'hostname -s'
breaksw
endsw
# SAP environment
if ( -e $HOME/.sapenv_`hostname`.csh ) then
source $HOME/.sapenv_`hostname`.csh
else if ( -e $HOME/.sapenv.csh ) then
source $HOME/.sapenv.csh
endif
# APO environment
if ( -e $HOME/.apoenv_`hostname`.csh ) then
source $HOME/.apoenv_`hostname`.csh
endif
# LiveCache environment
if ( -e $HOME/.lcenv_`hostname`.csh ) then
source $HOME/.lcenv_`hostname`.csh
else if ( -e $HOME/.lcenv.csh ) then
source $HOME/.lcenv.csh
endif
# JAVA environment
if ( -e $HOME/.j2eeenv_`hostname`.csh ) then
source $HOME/.j2eeenv_`hostname`.csh
else if ( -e $HOME/.j2eeenv.csh ) then
source $HOME/.j2eeenv.csh
endif
# XI environment
if ( -e $HOME/.xienv_`hostname`.csh ) then
source $HOME/.xienv_`hostname`.csh
else if ( -e $HOME/.xienv.csh ) then
source $HOME/.xienv.csh
endif
# RDBMS environment
# @(#) $Id: //bc/701-1_REL/src/ins/SAPINST/impl/tpls/ind/ind/DBSRC.CSH#1 $ SAP
if ( -e $HOME/.dbenv_`hostname`.csh ) then
source $HOME/.dbenv_`hostname`.csh
else if ( -e $HOME/.dbenv.csh ) then
source $HOME/.dbenv.csh
endif
citroen is correct: the error doesn't come from "su" but from the login process of the user. Possible candidates are: the file "~/.profile" and the file "~/.cshrc".
The difference between "su - user" and "su user" is that "su - user" sets the complete environment for the new user you switch to while "su user" just changes the "effective user ID" and not the environment. If userA does a "su - userB" the session will still have the environment of "userA", but all the privileges of "userB".
This could be everything and is hard to tell from here. For instance, one conceivable reason: The user in question is not in a group which is necessary to source one of the files you mentioned.
I suggest you do as citroen said and try to nail down the problem by testing good one part of the login process after the other: rename all the files involved as citroen said, then reenable one after the other until the error happens again. Then you have found the culprit. Now repeat the process inside this file to find the offending line, etc..
This is less a technical question than a question of how well your debugging skills are developed. As you need these daily as a systems administrator i suggest you start immediately developing them.
I would expect su command to be fine, default prompt.
Now, move regualr files and directories from /home/idsldap.save back to /home/idsldap
$ exit
# mv /home/idsldap.save/* /home/idsldap
# su - idsldap
$ exit
# ls -lRa /home/idsldap.save
This will show a number of files beginning with a . . One by one move them back to the original home directory - after each file, try a su - idsldap . When that gives the original error message - you have found the file with the error.