strange error after shell open

General support questions
Post Reply
chankim
Posts: 50
Joined: 2015/07/15 12:05:39

strange error after shell open

Post by chankim » 2018/08/29 07:52:26

Hi,
I'm using CentOS 6.9. Since some day last week, when I open a shell, (I'm using csh, which is linked to /bin/tcsh),
the system behaviour changed a little bit for an unknown reason and I get this strange error at the start of a shell.
test: Command not found.
test: Command not found.
QTDIR: Undefined variable.
[ckim@stph45 ~]$ source ~/.cshrc
I can see using echo command that even the first line of .cshrc had not been executed. and the prompt is $
I can do `source ~/.cshrch` and do my usual stuff after that.
But after sourcing .cshrc manually, there are two things unnormal.
When I open a shell by pressing `Ctrl-Shift t`, the shell opens in a new tab, but the font is a little smaller, so I press `Ctrl +` to make the fonts bigger. Also, in the vi (vim), when I press 'gf' on a file name, it doens't jump to the file as before.
There are these three strange phenoma and I want to make this normal.
What can be wrong? First I want to know what is processed before my .cshrc file so that I can look into it.

ADD : I checked https://kb.iu.edu/d/abdy but couldn't find any command called `test`.
Also when I do `echo $LANG`, it returns ko_KR.UTF-8 which is weird. how can I revert it to us_US.UTF-8 (I don't know what the original setting was, but definately not ko_KR.UTF-8), and this $LANG problem is not the cause of the problem but a result of it I guess.

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: strange error after shell open

Post by TrevorH » 2018/08/29 09:25:08

Something in one of the scripts that tcsh is executing at startup is wrong. If you grep QTDIR /etc/profile.d/* perhaps you can identify which file it comes from? Also repeat the grep against the files in your home directory that get sourced by tcsh (I have never used it sso have no idea what those are).
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

chankim
Posts: 50
Joined: 2015/07/15 12:05:39

Re: strange error after shell open

Post by chankim » 2018/08/29 12:14:09

Hi, TrevorH, Thank you for replying.

Ok, I checked the profile.d directory, and the 'test' command not found message was comming from /etc/profile.d/qt.csh file.
This file seems to be executed as a csh script but why is this 'test' command not working?
Below is the qt.csh file. (I have /usr/lib64/qt-3.3 directory, and echo lines were added by me.)
# Qt initialization script (csh)

# In multilib environments there is a preferred architecture, 64 bit over 32 bit in x86_64,
# When a conflict is found between two packages corresponding with different arches,
# the installed file is the one from the preferred arch. This is very common for executables
# in /usr/bin, for example. If the file /usr/bin/foo is found in an x86_64 package and in an
# i386 package, the executable from x86_64 will be installe

echo '### start qt.csh ###'
if ( $?QTDIR ) then
echo '### exit qt.csh ###'
exit
endif

switch (`uname -m`)
case x86_64:
case ia64:
case s390x:
case ppc64:
set QTPREFIXES = "/usr/lib64/qt-3.3 /usr/lib/qt-3.3"
breaksw
case *:
set QTPREFIXES = "/usr/lib/qt-3.3 /usr/lib64/qt-3.3"
endsw

foreach QTPREFIX ( $QTPREFIXES )
echo '### before test ###'
test -d "$QTPREFIX" && setenv QTDIR $QTPREFIX && break
echo '### after before test ###'
end
unset QTPREFIX QTPREFIXES

if ( "${path}" !~ *$QTDIR/bin* ) then
set path = ( $QTDIR/bin $path )
endif

setenv QTINC $QTDIR/include
setenv QTLIB $QTDIR/lib
echo '### end qt.csh ###'
The output when open a shell now looks like this :
### start qt.csh ###
### before test ###
test: Command not found.
### after before test ###
### before test ###
test: Command not found.
### after before test ###
QTDIR: Undefined variable.
and when I explicitly start csh by giving `csh` command, I just get
### start qt.csh ###
### exit qt.csh ###
Start of .CSHRC!
and normal .cshrc execution is done.

This is because I define QTDIR in my .cshrc file, so when I execute qt.csh after my .cshrc, it just exists with reponse shown above.
Can you tell what might have gone wrong? (I checked files starting with . under my home and saw only the .cshrc file contains it)

chankim
Posts: 50
Joined: 2015/07/15 12:05:39

Re: strange error after shell open

Post by chankim » 2018/09/21 06:21:24

I forgot about this problem and just before, I tried removing the /etc/profile.d/qt.csh file. (renamed it).
Now, the qt.csh file is not executed, and a new command shell opens without any complaint.
The g-f command works again in vim.
So I guess because of the qt.csh execution error, something after that didn't get throught and I had these weird problems.
I don't know what this 'test' command in the qt.csh file was doing before. ('test' doesn't seems to be a csh or bash command.
of course I can guess it tests if a file exists , or if it's a directory, .. something like that.)
I would appreciate any comments on my case. Thanks!

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: strange error after shell open

Post by TrevorH » 2018/09/21 07:26:58

The test command is /usr/bin/test and should be on all installs as it's supplied by the coreutils package. I suspect it's also a bash built-in.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

Whoever
Posts: 1357
Joined: 2013/09/06 03:12:10

Re: strange error after shell open

Post by Whoever » 2018/09/25 05:59:35

TrevorH wrote:
2018/09/21 07:26:58
The test command is /usr/bin/test and should be on all installs as it's supplied by the coreutils package. I suspect it's also a bash built-in.
Perhaps a script is breaking the $path variable so that the PATH no longer includes /usr/bin?

This would break almost everything, but running "source .cshrc" might set $path back to something useful again.

Post Reply