How do I find help for point command `.` in *nix?

First of all you should invoke type ., you will probably get something like:

. is a shell builtin

Builtins are parts of your shell, they don't have their own manual pages. Some of them may seem to have them though, e.g. echo is a builtin in Bash but most likely there is a separate executable like /bin/echo in your system and in this case man echo refers to the latter. These two echos are probably not strictly equivalent.

Your shell may provide information about any builtin via help builtin; try help help, help type and finally:

help .

Builtins may also be listed in your shell's manual page. E.g. (in my Debian) Bash builtins are covered directly in man bash, yet for Zsh builtins man zsh tells me to run man zshbuiltins. In general shells may or may not explain their builtins.

Try using man sh or man bash or the man page for whatever shell you are using. (Maybe man $SHELL.)

This is officially not called the "point" command, but the source command. Searching for the word source may be helpful.

e.g., bash man page (search for "each builtin command"), and you'll quickly find the documentation.

As for explaining the use, I can do that right here. I will just refer to this as the source command, recognizing that it can be abbreviated to just a period when you're using some shells, and with some shells that command might need to be (because dot might be recognized but the entire word source might not be).

If you use the source command, your shell will read each line from the script file, and try to execute it. You need "read" permissions on the file. (It doesn't matter if you have "execute" permissions.) If you modify a variable, that is prone to affecting your current shell.

If, on the other hand, you just try to execute the file, then your shell will ask the operating system to take care of this request. This will require "execute" permissions. (On some systems, like OpenBSD, you won't need "read" permissions for this. On other systems, including many Unix variations, you will.) The file may need to start with an appropriate header (e.g., #!/bin/sh) so the operating system recognizes this to be a script file. The operating system will execute a copy of the requested shell, and tell that shell to run the contents of the script. If the shell environment is changed (e.g., a variable gets a new value, the working directory is changed (with cd), a file descriptor is redirected (with exec), etc.), it will impact only the sub-shell that was called for the script, and can't modify the environment in the parent shell that called the script file.

No one else has mentioned it, as it's often forgotten.

Your biggest clue would of come from the helpful command whatis.

tim@musha ~ $ whatis .
builtins (1)         - bash built-in commands, see bash(1)
tim@musha ~ $ whatis source
builtins (1)         - bash built-in commands, see bash(1)
tim@musha ~ $ whatis bash
bash (1)             - GNU Bourne-Again SHell
tim@musha ~ $ whatis lynx
lynx (1)             - a general purpose distributed information browser for the World Wide Web
tim@musha ~ $ whatis linux
linux: nothing appropriate.
tim@musha ~ $ whatis whatis
whatis (1)           - display one-line manual page descriptions

EDIT:

Some people have pointed out in the comments that this isn't in some distrobutions - maybe it's an installable package, or enabled some how - I had it by default in gentoo ;)

It includes the wonderful which - which tells you which executable is called, and whereis which gives you all the paths to a executable you name, and it's man pages (if it exists in multiple paths).