Actually there are not very many commands that would affect config files. Most commands just read their config files. This is very much dependant on what it is though. Some programs may in fact write to a config file if it's more of a tool used to configure something else. Like XFree's configure tools.

Almost all config files can be, and should be edited by hand for best results ( with exception of sendmail.cf - which can be done if your feeling lucky ).

I normally always configure everything using vi.

Dunbar, have you tried to run "strace" on the programs? Running the following will show you the files a program is using:

strace -o /tmp/strace.txt program

where "-o" is the option to store the output in a file.

You can then look at the output trace file "/tmp/strace.txt" and search for the "open" function. The trace output if pretty verbose, so you can run:

grep "^open" /tmp/strace.txt

to remove the unwanted data from the trace info, if you're not interested in anything other than which files are being used. That should list every config file the program is reading from.

Speck

Umm, this works only for programs that are currently running, yes? If so, consider me as greedy, I want to know every config file, not just the files for programs that are active in any given instant of time. It's pretty hard to use lsof and similar command to get a list of files for a command which has already terminated.

Would grepping C source code foror
do something like what I want (reading file accessing instructions from source code)?

Blah.
Any command that reads a config file has to have that information either built into the code (and thus the source code has the filename) or, is passed via environment variables. How else could any command ever know about the file?

I agree with you on some points. The more complex OS's and applications become the less written documentation there is and the less helpfull the so called on line documentation becomes.

There have been many of times where it has required looking through several 500 page plus manuals to find some answer.
I have bought lots of books because I found after the fact that another one detailed a particular item better.

Yes you could grep the source code. But it probably will not work on everything. I doubt that all the source code is written by exactly the same methods of documentation and programmers have different techniques. Here is your opportunity to create the ultimate guide.

To answer your question "Where can I on my 'crashed' linux box, find an explanation of 'what comands are affecting what configuration files'?" Probably nowhere.

But then what do you mean by 'crashed'?

grep for "*.conf" and "*.cf" filename occurences in the source...

michaelk: I am presenting the issue facing any and all newbies; postulating that I may have already suffered any and all crashes which are possible. Further assume that the infamous newbie has crashed all of each and every possible {service, command, tool, manager}, etc.

What common search could I make, assuming a lame rescue setup (CD or maybe even floppy)? I am certain that the config files must be named by something, somewhere, aside from simply residing in a directory as a file. When a {service, command, tool, manager} calls for the contents of the config file, it must already know the name (or possibly the name is passed by an environment string, which is simply grepping a few .logins and .*rc files).

I need to get an index of everything, no matter which distro, simply because I cannot trust {man pages, info entries, /usr/doc} to relate the proper locations and names of the actual config files being used by a given distros filesystem.

bulliver: Arch is my current distro; we already know that the /usr/doc files are gone. Do you post over at bbs.archlinux.org? Your solution is elegant; I will be looking forward to testing this!
Is it highly probable to work on other distros which you are aware of???

will you not be in the same situation figuring out what service is causing said problem?

For instance..

My computer hangs at boot right after I see "Finding module dependencies"

Now how will you know what to grep for config files.

I'm confused. I don't mean to be rude, but to me this is what it
sounds like you want:
"I want to have all the experiences of every guru written down in
one place so that I can look through there and find the answers I
need."
Well, LQ is gettting there, LDP is getting there, but you must
understand that very little of what any of us know about the
linux OS is from reading, it's from doing and failing. When I need
to find files that concern ssh, I do a .
That'll show that there are a bunch of files is /etc/ssh, and a
bunch in /usr/doc, /usr/bin, /blah/man,etc. I look through those
files and find what I need. If I need a config file, I look for
something that is obvously a config file (/etc/ssh/ssh_config,
/etc/ssh/sshd_config). If I want to know how to set up an
apache server, I'll do a .
Ok, so there's an /etc/apache directory. Maybe /etc is a good place to
look for config files. Next time I'll do a faster command: .
Look, there are config files concening cron in /etc too. Ok,
maybe I don't find what I need in there. Back to
.
I'm really not trying to be rude, but the truth is that there is no
such +5 Tome of Holy Documentation. Look for the files (on your
system) that are at all related (locate, man -k topic), and
you're pretty likely to find what you need. If you don't, it's time
to google, if that doesn't work, it's time to ask someone who might
know, which brings you to LQ or LDP, or whereever. You
simply cannot expect to be able to just absorb by osmosis all the
knowledge that so many people spend years learning, and they
simply can't write it down. They don't always remember what
was difficult, and you don't know which questions you have until
you've tried a few different things.

No I don't post there, allthough I registered. To be honest I have not had a problem with Arch that I couldn't figure out on my own. Either good luck, or perhaps good distro?

I am certainly not a programmer or anything, but it seems to me if a program is going to read/write a file there must be some reference to it in the source right? So grep the source for extensions which typically indicate config files ie: .conf,.cf,rc,config etc...

It was just a thought, I have no idea if it will work, but if it does I can assure you it will work on any distro.

I'm lost - you are referring to whom? Please use the little button on the lower left of each posted message - the button which says 'quote'.

I'll assume you intended to chastise my posts.Hello? Are you still at the level of Linux newbie, the level where you just crashed your box, and since you've been lobotomized by Microsoft and just left it behind, you do not know anything about the structure? Does a newbie know where all the config files are stored AND know what program created them? Grep is an elegant solution, IMO, if it works, because the desire is for nothing to evade its answers and with the correct syntax, grep might also spew things like bash reads config data from /etc/rc.local and ~.bashrc Glad you offered to help that goal :-\.Locate needs a functional OS, with an existing database which is already made prior to the crash. Not going to work unless they have a 90% functional system. XFree is only the last 10%, I'm postulating having blown away lilo.conf or XFconf.Raises the concept of "do all distros everywhere use only *config as a string".... not everything, from what I just read....same issues: this is not a newbie item because they must already know which file created the problem, which many newbies do not.Hence the concept of grepping sourcecode for commands which open and read and write configuration files, discern whatever they are called and spit out the answer; the souce has to have commands to open the files. ("+5 Tome of Holy Documentation"? Why mention Moriah? I do not play that game on this box...)Several times I have tried Debian Woody, on several platforms, and each time, I find that man -k does not work. I tried 'man -k ls', got the usual failure response, then I tried man ls and got the man page. Something didn't build the apropos database prior to me issuing the man -k command, and thus this is a non answer for a know nothing newbie.On a linux box which cannot surf because the man pages do not explain how to set up ppp? Exactly how far are you into your masters degree?You must have started your career with a degree, because you think as if each failure was already familiar to you, in the sense that you already know what cron does, what ssh does, etc. Step away from the keyboard, you are not helpful when you persist in that line of reasoning.

At this point, I have learned the following:

1] *fp= fopen("file", "r")
2] fopen(fp,"file","r")
and
3] grep for "*.conf" and "*.cf" filename occurences in the source.

Someone who has no idea of which configuration file to edit will get a lot further with the above 3 items than your piecemeal approach of 'learn which command' then 'man each command', because, as the thread opened up, I explained that the man pages failed to include a files section, my distro fails to include a /usr/doc section and some distros fail to build the apropos database.
Add in the concept that lilo.conf and configurations for ppp/ethernet can be trashed without the user knowing what caused the error (Mandrake wizards do not tell you the name of the file being edited, thus users rely on Mandrake to have the GUI tool to fix the problem), and now you have a recipe for one frustrated newbie. I repeat, go soak your heads, if this man -k and google stuff is the best you can come up with.

Lets revisit the issue, with a summary:
Assume the following: I am booting from a rescue floppy/CD. Doing so BECAUSE I cannot get into my Linux box any other way. I am not sure of the config file name, I can type a bit at the command line, I want as much of my problem answered as I can achieve. Man pages are off line or have no apropos database, I'm not in a GUI. What can I do, at a commandline, to get a listing of files that are user configurations for the OS?

EDIT:
moses: try reading this for a better idea of why you provided nothing useful to me.
/EDIT

EDIT:
corrected spellnig rerors and grammar
/EDIT