Hello,
I'm having a problem, and while I've gotten hits by searching the error, "MANPATH: Undefined variable" I'm not sure which solution pertains to me.

I'm running Fedora V.7.

I was trying to install something called novell-iprint-xclient.i586.rpm from http://umppa1.medicine.umaryland.edu so that I could attempt to print from my Linux onto my work printers. (It actually didn't even work.) But worse, after downloading it, whatever it is, the error occurs everytime I open up an empty shell, and I cannot execute any .coms from my shell.

I think the process may have deleted a line from somewhere, but I'm not sure what to add back.

I hope that no one will suggest that I contact my IT department. Although they seemed to have Linux software for downloading, in general they only support Windows computers (inadequate for my computing needs) and thus usually can't help.

Anyone have any suggestions? With your suggestion, could you please comment on how "safe" the suggestion is...or am I potentially going down an irreversible road? I don't really have any irreplacable data on this computer, but I also would not want to recreate the computer to its current state, with all the applications and files I have installed on it. Although backups exist for what I have, I have never "backed up the computer, and don't know how.

Thanks a bunch!

-Andrea

MANPATH defines where the Linux or Unix manual (man) pages are found. It is NOT a critical variable so I'd be surprised if it were breaking your installation.

The fact you're seeing the message suggests the script is trying to append a new path to your existing MANPATH variable but there is no existing variable.

On Linux by default MANPATH isn't used because of the /etc/man.config setup. (Type "man man" for more detailon MANPATH).

You can probably get around the error by setting a MANPATH before the start of the program then seeing what it added after the fact and adding that to /etc/man.config.

e.g.
export MANPATH=/usr/share/man:/usr/local/share/man:/usr/X11R6/man

After the export type "echo $MANPATH" to see what the value is.
After the install type the "echo $MANPATH" to see if it changed the value. Record the difference.

Hello Andrea Can you give a bit more detail on that?

The package may have added a line to one of the shell initialsation files, a line that references MANPATH.

Please post the contents of /etc/bash.bashrc, /etc/profile, ~/.bash_profile, ~/.bash_login and ~/.profile (they may not all exist).

Best

Charles

Hello,

Thanks for your replies.

To be clear, I can accept if I can't get the printing on my work printer to ever work, but it's the inability to execute any of my .com programs from within my shell that has my work ground to a halt. The attempt to download the print client was the last thing I did before I noticed the errors, that is "MANPATH: Undefined variable." showing up each time I open a shell, and inability to run a .com or other executable file from the shell.

jlightner, I tried the command that you listed, however, the error I got was "export: Command not found". I also tried echo $MANPATH and got "MANPATH: Undefined variable", so you're right in that MANPATH hasn't been set anywhere, right?

Charles, I tried searching for "MANPATH" for each of the files you listed above (some existed, some did not), but none had "MANPATH" in them. Using "ps", I found am working in the cshell, by the way (necessary for some of my executables), except when I execute my own text manipulation scripts, which I write in bash. Do you still need to see the contents of each one? If so I'll send, but it will take more time.

Thanks,
Andrea

export command is built into most of the Bourne based shells like bash.

It sounds like you're not running one of those. Are you running csh (C shell)? It has a separate way of setting variables as follows:
setenv MANPATH /usr/share/man:/usr/local/share/man:/usr/X11R6/man

If that gives you an error like export then type "ps" at command line and post output so we can see what you're running.

Also .com is a DOS/Windows suffix. Programs on Linux/UNIX don't require suffixes but it is OK to have .com in a file name even though it would be unusual to do so.

Finally note that you likely wouldn't be able to run a .com file created for DOS/Windows on Linux/UNIX natively so be sure this .com is actually one written for the Linux.

Hello Andrea Ooops! Sorry. That will teach me not to assume everyone is using a Bourne shell derivative!

I understand you have two issues, one being the MANPATH error message and the other being "inability to run a .com or other executable file from the shell".

Regards the fist, csh uses different files for shell initialisation. These are (you don't need to read all this -- here for completeness), according to http://linux.about.com/library/cmd/blcmdl1_csh.htm, A login shell begins by executing commands from the system files /etc/csh.cshrc and /etc/csh.login. It then executes commands from files in the user's home directory: first ~/.tcshrc (+) or, if ~/.tcshrc is not found, ~/.cshrc, then ~/.history (or the value of the histfile shell variable), then ~/.login, and finally ~/.cshdirs (or the value of the dirsfile shell variable) (+). The shell may read /etc/csh.login before instead of after /etc/csh.cshrc, and ~/.login before instead of after ~/.tcshrc or ~/.cshrc and ~/.history, if so compiled; see the version shell variable.

Wow, that's complicated! I guess for present purposes it's the /etc/csh.cshrc, /etc/csh.login, ~/.cshrc, ~/.tcshrc and ~/.login that you need to look at. Again, they may not all exist. Chances are the installation added line(s) at the end of one of them.

Regards the second issue, *n*x does not use the Windows mechanism of using an executable's .extension (in your case .com -- and which others?) to determine how to run the file, rather it examines a "magic number" at the beginning of the file.

Please give the output of The "file" command reports the significance of the magic numbers. It does not use the $PATH value to find files, hence you need to give it the full path, beginning with /. There is a table of magic numbers somewhere; perhaps the installation changed this for the magic numbers of the executables you can no longer run.

Can you tell us where these .com and other executable files that no longer work come from?

Incidentally, regards "I found am working in the cshell, by the way (necessary for some of my executables), except when I execute my own text manipulation scripts, which I write in bash.". it is unusual for executables to require launching from a particular shell; perhaps they use environment variables that are only set by csh. If you want to change shells you could simulate those. Similarly you don't need to be working in bash to run a bash script; beginning the script with #!/bin/bash will allow it to be run from any shell.

Best

Charles

Thanks to everyone for their help. Still not quite working though...

jlightner, I tried your setenv command. I typed it directly into the shell, and I put it into my ~/.cshrc file. There were no error messages, but the MANPATH error persists each time I open a new shell, and the same executable are still not able to run. Using "ps" I am working in the cshell.

Re. my comment about .com files, I think that it is the convention of some people to use ".com" to signify an executable. So, copying others, I have often named my own executable text manipulation scripts, "test.com", etc. Also, I write the scripts in bash and precede with "#!/bin/bash". That is to say, that the text manipulation scripts that no longer work are ones that I wrote for Linux, and not things for Windows. I put an example below.

Charles, I found the following files on my computer, but none of them had MANPATH when I searched:
/etc/csh.cshrc
~/.cshrc
/etc/csh.login

By the way, these are all programs for working with protein structures that I have downloaded from the internet. They are totally legit programs that work on other computers I have. Also, two of the programs (the two biggest programs) that no longer work were installed onto my computer under separate usernames (I think so that if they ever needed to be updated, that was supposed to make it easier.) I honestly don't even know the path to get to them but I figure if I can get the other ones working again, maybe those two would work too. One program has continued to work throughout all this, not sure what is different about it.

Below are some examples of programs that I used to be able to run, but now cannot run, including one I made up today called "test". By the way, for each of these, I tried the file command from within the folder where the program was. I also tried "file /wholepathname", and got the same result, as in the first example.

(by the way, this pymol program above works when I click on the icon to execute it, using the GUI)

Thanks again for your help!
Andrea

If you're still getting the MANPATH error after explicitly setting it then it appears to be a bug in what you're executing that is spitting out the error.

By convention in UNIX/Linux .com is NOT used. For shell scripts the convention (if any) you'll see is .sh (or maybe .ksh if korn shell or .csh if cshell).

None of this is required however. You could name a file "this.is.my.favorite.script" and it would run fine so long as you made it executable. Linux doesn't require suffixes at all - a dot is just another character in a file name so you could just as easily name it as "thisismyfavoritescript". It is the contents and the permissions that make it executable not the name.

jlightner, thanks for your reply. "MANPATH: Undefined variable." appears as soon as I open the shell, with an exception, below. Except for the scripts that I have written (mostly simple bash text manipulation scripts), none of the other programs have a suffix or end in .com.

The specific error that occurs when I type the executable from within the folder where it's located is:

However, I just tried typing the WHOLE pathname of the program, and it did execute (!?!)

Then I tried another, and this is what I got:
This is the first time I've gotten the MANPATH error during the session (rather than upon opening the shell). This executable is written in .csh and basically has modifiers for running the pales program. I think the error is because inside the script, I don't have the entire pathname of pales.

I just tried my "test" script again, and got it to work, but only when typing in the whole pathname.

So, now, it turns out I can get programs to run, but only when typing in the whole pathname, even when I'm in the folder the program is located in. And this is a change from previously.

This actually means I can run all but my two biggest programs, which are located in their own usernames, and I don't know the entire pathnames to get to them.

Therefore, my two remaining questions are:
1. How do I get things back the way they were, in which I was not required to type in the whole pathname if I were in the folder where the executable is?
2. Is there a way to figure out where a program is if it were installed in a different username on my computer?

I hope that makes sense.
Thanks in advance for your help.

Andrea

The PATH variable determines where to look for executables. If you check your PATH variable by doing "echo $PATH" or "env |grep PATH" you should see a list of directories delimited by colons (":") similar to the way MANPATH was shown above.

If the PATH variable does not contain "." or "./" then it is not set to look in your current directory as the dot (.) is a reference to the current directory (in this context). However, many people don't like having "." in their PATH as they see it as a security issue. You can append the full path to the directory to your existing PATH variable by typing:
Alternatively if you're just in a directory to run a program there and don't need it in your PATH all the time you can simply type the "./" at invocation to tell it executable is in the directory you're in:
If the command is already in your PATH then typing "which <command>" will tell you which directory it is in. If the command is not in your PATH you can try using the find command. This requires you to have permissions to the location. So if you did something like:
It would look for that file anywhere on the system (from root down). If you knew it was in /home somewhere you'd instead type:
Logged in as aberry you likely do not have permission to search the entire system but you may have permission to search /home.

Hello Andrea Regards "How do I get things back the way they were", that would require knowledge of what changed and the only practicable way I can think of to determine that is to inspect the installation procedure in novell-iprint-xclient.i586.rpm. It may be easier to fix the breakage, or could you ask the creators of that package ... ?

Continuing, for now, with fixing the breakage ...

jlightner has given a great explanation of how $PATH is used to allow commands to be run by name only which leaves the MANPATH problem.

Please tell how you "open up an empty shell".

Assuming you are doing something that triggers csh initialisation then, because you told us there are no MANPATH references in /etc/csh.cshrc, ~/.cshrc and /etc/csh.login then either the MANPATH problem arises a) in a less commonly used csh initialisation file (please check ~/.tcshrc, ~/.login and ~/.cshdirs) or b) indirectly by something that is run from a csh initialisation file (please check them all for something that is specific to the specialised programs you run).

Finally, we can investigate the one executable that triggers the same error message, /home/aberry/pales/pales/linux/pales072209.com. What sort of file is this (what is the output from file /home/aberry/pales/pales/linux/pales072209.com)? If it's something you can read as opposed to a binary (for example if it's bash or perl as opposed to and ELF 32-bit LSB executable), please search it for MANPATH and post any lines around MANPATH with the hope we can see what it's doing with MANPATH that could generate the error.

Best

Charles