Hello group, please help.

When I login to Redhat 9 as root I have no problem accessing the man pages but if I login as myself I get the following error

"man: No such file or directory" "failed to open the message catalog man on the path NLSPATH=<none>"

I have done some reading and poking around and this is what I have got;

-If I run "manpath" the result is a blank line before the command line is returned
-If I "echo $MANPATH" I get "/usr/bin/man"
- running "setenv MANPATH" solves my problem, I can now access the man pages.
- Now if I "manpath" I get "/usr/local/share/man:/usr/share/man:/usr/X11R6/man" which is the result if I run the same command as root.

My question, what do I need to change to eliminate the need to run "setenv MANPATH" from the command line and if this is not even the correct fix, what should I be doing.

Thanks
John

Just edit the file .bashrc in your home directory. If you don't have one, make one. Then put setenv manpath in the .bashrc file. It'll run that command each time you login.

linuxgeekery:
setenv suggests that he uses tcsh, not bash... changing
.bashrc won't help.

To the original poster:
If it works for root: what shell is root using? If it's the
same that the normal user has check permissions on
/etc/profile (and the files it pulls for tcsh).



Cheers,
Tink

Root is using csh as well. On the initial install the default was bash but I changed it for my user and the root a couple weeks ago.

Permissions on profile are -rw-r--r-- (644 I think). I tried chmod 666 profile (as root) and then logged in again as my user but it did not make a difference. I looked at the contents of "profile" but cannot tell what other files it would call in this regard.

May I ask why? It's just that I personally can't stand csh ;)

My bad, I got a bash-specific file there as well ...

Check /etc/csh.login instead.


Cheers,
Tink

Currently, our prime motivation for moving to Linux is to gain performance improvements while using a specific piece of software if the PCB fabrication business. The install scripts as well as many of the canned scripts for this software are C-Shell. It is for this reason that I switched the default shell from bash to csh.


Permissions for csh.login are the same as "profile", 644 . Changing to 666 has no effect. If I change the shell back to bash and login again, then I have no problem with accessing the man pages so it is definitely (I think??) related to csh in some manner. I have looked at bashrc, csh.cshrc, profile, csh.login but I can't really see anything, not that I know what I am looking for anyway - not too good at this programming stuff yet.

Also, how come when I switch to bash and then "echo $shell" the response is a blank line. I also mentioned blank line responses in one of the previous messages - please educate me!

Thanks for your patience - John

If it's not too long you could post /etc/csh.login here
(and maybe check whether there's something in
/etc dealing with tcsh explicitly... ) ... also check
the scripts csh will evaluate in home for NLSPATH
statements. Not that I have any experience with that
messing up man, it's just what the error message suggests.

Because Unix/Linux are case-sensitive.
Try echo $SHELL instead.


Cheers,
Tink

OK, here they are,

# /etc/csh.login
# System wide environment and startup programs, for login setup
if ($?PATH) then
setenv PATH "${PATH}:/usr/X11R6/bin"
else
setenv PATH "/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin"
endif
limit coredumpsize unlimited
setenv HOSTNAME `/bin/hostname`
set history=1000
if ( -f $HOME/.inputrc ) then
setenv INPUTRC /etc/inputrc
endif
if ( $?tcsh ) then
bindkey "^[[3~" delete-char
endif

Also have this file

# /etc/cshrc
#
# csh configuration for all shell invocations.
# by default, we want this to get set.
# Even for non-interactive, non-login shells.
[ "`id -gn`" = "`id -un`" -a `id -u` -gt 99 ]
if $status then
umask 022
else
umask 002
endif

if ($?prompt) then
if ($?tcsh) then
set prompt='[%n@%m %c]$ '
else
set prompt=\[`id -nu`@`hostname -s`\]\$\
endif
endif

if ( -d /etc/profile.d ) then
set nonomatch
foreach i ( /etc/profile.d/*.csh )
if ( -r $i ) then
source $i
endif
end
unset i nonomatch
endif

With respect to the "echo $shell" command, thanks for suggesting the case sensitivity idea. Lower case "shell" worked for csh which is why I was trying it. Seems that both lower and upper case work in csh but in bash only upper case worked.

John

Looks sane to me... the perms with 644 btw were
what you want, 666 is a bad idea.

I'd be looking at the *.csh files in /etc/profile.d right
now if I had that problem ...

Another reason not to use csh ;)


Cheers,
Tink

[jparsons@redhat1 profile.d]$ ls -l *.csh
-rwxr-xr-x 1 root root 724 Feb 18 2003 colorls.csh
-rwxr-xr-x 1 root root 192 Feb 2 2003 glib2.csh
-rwxr-xr-x 1 root root 58 Feb 14 2003 gnome-ssh-askpass.csh
-rwxr-xr-x 1 root root 41 Feb 7 2003 lam.csh
-rwxr-xr-x 1 root root 2379 Mar 12 2003 lang.csh
-rwxr-xr-x 1 root root 317 Feb 4 2003 less.csh
-rwxr-xr-x 1 root root 60 Feb 19 2003 pvm.csh
-rwxr-xr-x 1 root root 102 Jan 29 2003 qt.csh
-rwxr-xr-x 1 root root 13 Feb 12 2003 vim.csh

Tink, not wanting to waste anyones time should I give up on this? For the times I use "man" I guess I could just "setenv MANPATH" but I sure would like to learn what is wrong with the basic set-up and correct it. I find this is the best way to learn. If you can keep helping I would appreciate it but I do realize that it can be difficult when you are not sitting in front of the terminal.

John

Just moments ago I solved this little dilemma and I just wanted to post back thanking those who tried to help. I set aside this problem and carried on and just moments ago while troubleshooting another problem it all became clear. I obtained a script (.cshrc) from a fellow Genesis software user that set some software specific system variables and in this script the MANPATH variable was also set to a directory that does not exist on my system. Change that and everything appears to work fine - big surprise! :^) . Learned something new and on a Friday no less.

Anyway, thanks again!
John