I need to find help for point command
. such as in
. ./my_script.sh (I mean the first point.)
I have already tried to find a man page using
man . and
man \.. How can I display a man page in which it explains the use of command
Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.Sign up to join this community
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 type and finally:
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.
man sh or
man bash or the man page for whatever shell you are using. (Maybe
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
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
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).
. is a synonym for the shell
source command and so in bash, its syntax is displayed by...
It functions exactly like the
import commands in other languages in that it reads the target file and interprets it as if it were part of the current script. Thus, that file will execute in its entirety before the commands in the rest of the current script.
It should usually be at the beginning of the current script and is most often used to load variables and/or function definitions.