GCC is working but it isn't in my path

I am very newbie, and I want to use RH 8.0 to do some C++ programming. I have gcc, I am positive. when I do a "whereis gcc" I get

/usr/bin/gcc /usr/share/man/man1/gcc.1.gz

I am guess that means that's where gcc is. Then when I do a gcc -v I get

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --with-system-zlib --enable-__cxa_atexit
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
[1]+ Done xemacs .bashrc (wd: ~)
(wd now: /usr/sbin)


I don't know what any of that stuff means. If somebody wants to waste their time explaining it to me, I'd love to listen, I'm all ears. Some of it I can guess like the mandir or the wd...but my guess is that the mandir means where the man file is, which says /usr/share/man which confuses me, because I thought it was in
/usr/share/man/man1/gcc.1.gz. The second thing that confuses me is wd, which I take to mean working directory (?), but if that is the working directory, I don't see any gcc file in there. On top of which, I do see a gcc file in /usr/bin/ though, but that path isn't in my .bashrc, still the gcc command works, can somebody explain this?

You don't really need to know anything that gcc -v returns. It just returns how the RedHat guys configured it when they compiled it. However, the last two lines weren't returned by gcc, so don't worry about the working directory (but yes, wd is working directory). They were returned by the shell to indicate that you had exited xemacs.
The mandir is /usr/share/man, not the man file. The man file is installed in the man1 directory under the mandir (since the gcc manpage is a section 1 manpage), and called gcc.1.gz in the /usr/share/man/man1 directory. The man1 and gcc.1.gz are standardized whatever mandir you use.
The reason that /usr/bin isn't in your .bashrc file is that it needn't be; it has already been specified when the shell launches by the program that launched the shell. Run "echo $PATH" to see everything that is in your binary search path.

Quote:

---

The reason that /usr/bin isn't in your .bashrc file is that it needn't be; it has already been specified when the shell launches by the program that launched the shell. Run "echo $PATH" to see everything that is in your binary search path.

---

Dolda can you rephrase that, I'm not sure what you are saying. If you are saying that when I launch my shell, my xterm, or something, that program automatically sets my path, then I get it. But can I see what path that is, that this program is setting, just in case I'd like to alter it myself sometime.

OK, let's take this from the beginning. Sorry for my inclarity, but I was _really_ tired when I wrote that. The binary search path is in the PATH environment variable. To see what it currently is, type "echo $PATH" in a shell.
Let's get down to environment variables. Each process in the system has its own collection of them, they are freely modifiable by any process and any modification to them do not affect other processes. When a new process is created, it inherits the environment variables. In this case, PATH was set to /usr/local/bin:/bin:/usr/bin while the system booted, and then all processes that you use have that PATH. The X server has it, the display manager has it, the window manager has it, and when you started your xterm, it got it from the process that started it, and then the shell got it from the xterm. I'm not sure exactly where PATH is set to this, but it's very possible that init(8) does it. It could also be done by the X session setup scripts or by the display manager.
So /usr/local/bin:/bin:/usr/bin is the _standard_ PATH. All else in .bashrc files and the like are usually just modifications of that standard PATH.

Is there a source online, that specifies all/a lot of the initiation files that set paths at any given point? Basically...maybe this is the control freak in me, I want to know which initiation files are running at which point, setting which paths.

I am very new, so I thought .bashrc did all the path initiation, or at least was the first to set the path initiations. But I guess .bashrc is one of the last. Does .bashrc, set the paths that are set when the shell runs? I'll see what init(8) looks like. Thanks for all the info. Tired of answering my questions yet...hope not, I really think I'm learning a lot.

What did people do before forums...

It's very easy to see what files are run, you just have to follow the chain of source and docs.
First, look at init(8) and you'll find that init sets PATH to /usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin. Then you can see that it launches processes using the information in /etc/inittab, and thus if you interpret /etc/inittab using inittab(5), you'll see that the last thing init does when entering runlevel 5 is to start /etc/X11/prefdm. If you look in prefdm, you'll see that it sets PATH to /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin, thus overriding what init previously set. prefdm then execs gdm (if you're using gdm, which I guess you are). If you then look in the gdm docs (I don't remember where they are, though; sorry), you'll see that it launches the selected session file from /etc/X11/gdm/Sessions. By default, the file "default" is started. It execs /etc/X11/xdm/Xsession, and then execs /usr/share/apps/switchdesc/Xclients.gnome (if you're using GNOME, that is), which execs gnome-session. gnome-session is the binary program that takes of the rest of GNOME initialization.
I'm not sure where /usr/local/bin is added, though. I think the shell adds it itself if there is no PATH variable set when it's invoked.