https://major.io/2010/03/18/sigterm-vs-sigkill/
http://www.joshstaiger.org/archives/2005/07/bash_profile_vs.html
To do this, add the following lines to
How are shell variables different from environment variables? Whenever you start a new shell or a UNIX program, it inherits all of its parent's environment variables. However, it does not inherit any shell variables; it starts with a clean slate. If you're a programmer, you can think of environment variables as "global" variables, while shell variables are "local" variables. By convention, shell variables have lowercase names.
http://askubuntu.com/questions/26318/environment-variable-vs-shell-variable-whats-the-difference
We can see a list of all of our environmental variables by using the env or printenv commands.
env let's you modify the environment that programs run in by passing a set of variable definitions into a command like this:env VAR1="blahblah" command_to_run command_options
use set to see shell variables
_: The most recent previously executed command.
Unsetting Variables
export -n TEST_VAR
If we want to completely unset a variable, either shell or environmental, we can do so with the unset command:
unset TEST_VAR
The Difference between Login, Non-Login, Interactive, and Non-Interactive Shell Sessions
The bash shell reads different configuration files depending on how the session is started.
One distinction between different sessions is whether the shell is being spawned as a "login" or "non-login" session.
A login shell is a shell session that begins by authenticating the user. If you are signing into a terminal session or through SSH and authenticate, your shell session will be set as a "login" shell.
If you start a new shell session from within your authenticated session, like we did by calling the bash command from the terminal, a non-login shell session is started. You were were not asked for your authentication details when you started your child shell.
Another distinction that can be made is whether a shell session is interactive, or non-interactive.
An interactive shell session is a shell session that is attached to a terminal. A non-interactive shell session is one is not attached to a terminal session.
So each shell session is classified as either login or non-login and interactive or non-interactive.
A normal session that begins with SSH is usually an interactive login shell. A script run from the command line is usually run in a non-interactive, non-login shell. A terminal session can be any combination of these two properties.
Whether a shell session is classified as a login or non-login shell has implications on which files are read to initialize the shell session.
A session started as a login session will read configuration details from the /etc/profile file first. It will then look for the first login shell configuration file in the user's home directory to get user-specific configuration details.
It reads the first file that it can find out of ~/.bash_profile, ~/.bash_login, and ~/.profile and does not read any further files.
In contrast, a session defined as a non-login shell will read /etc/bash.bashrc and then the user-specific ~/.bashrc file to build its environment.
Non-interactive shells read the environmental variable called BASH_ENV and read the file specified to define the new environment.
http://www.cnblogs.com/chengmo/archive/2010/10/27/1862791.html
收获：whatis数据库，并且有makewhatis创建，whatis脚本是用作查询的
makewhatis是怎么样工作的呢？
[chengmo@centos5 ~]$ man makewhatis
#得到：
makewhatis reads all the manual pages contained in the given sections of manpath or the preformatted pages con-tained in the given sections of catpath. For each page, it writes a line in the whatis database; each line consists of the name of the page and a short description, separated by a dash. The description is extracted using the content of the NAME section of the manual page.
#大概意思是：makewhatis 从手册页配置的路径以及领域范围，搜集所有手册页索引信息，每个手册页在数据库加入一行，这行会包括手册页里面name,以及简单描述。
收获：知道这个数据库是建立是索引，并且每个数据库写入一行(a line) ,会不会这个数据库就是文本文件呢？现在到这里，我们不知道数据库保存地方，也不知道它结构，只有看看whatis命令，看它是不是有源码信息
whatis数据库是什么时候创建的呢？
有run-parts脚本运行/etc/cron.daily目录下面的文件
This would send a signal called SIGTERM to the process. Once the process receives the notice, a few different things can happen:
- the process may stop immediately
- the process may stop after a short delay after cleaning up resources
- the process may keep running indefinitely
The application can determine what it wants to do once a SIGTERM is received. While most applications will clean up their resources and stop, some may not. An application may be configured to do something completely different when a SIGTERM is received. Also, if the application is in a bad state, such as waiting for disk I/O, it may not be able to act on the signal that was sent.
Most system administrators will usually resort to the more abrupt signal when an application doesn’t respond to a SIGTERM:
The
-9 tells the kill command that you want to send signal #9, which is called SIGKILL. With a name like that, it’s obvious that this signal carries a little more weight.
Although SIGKILL is defined in the same signal header file as SIGTERM, it cannot be ignored by the process. In fact, the process isn’t even made aware of the SIGKILL signal since the signal goes straight to the kernel init. At that point, init will stop the process. The process never gets the opportunity to catch the signal and act on it.
However, the kernel may not be able to successfully kill the process in some situations. If the process is waiting for network or disk I/O, the kernel won’t be able to stop it. Zombie processes and processes caught in an uninterruptible sleep cannot be stopped by the kernel, either. A reboot is required to clear those processes from the system.
https://kb.iu.edu/d/abbe
A symbolic link, also termed a soft link, is a special kind of file that points to another file, much like a shortcut in Windows or a Macintosh alias. Unlike a hard link, a symbolic link does not contain the data in the target file. It simply points to another entry somewhere in the file system. This difference gives symbolic links certain qualities that hard links do not have, such as the ability to link to directories, or to files on remote computers networked through NFS. Also, when you delete a target file, symbolic links to that file become unusable, whereas hard links preserve the contents of the file.
To create a symbolic link in Unix, at the Unix prompt, enter:
ln -s source_file myfile
If you delete the source file or move it to a different location, your symbolic file will not function properly. You should either delete or move it. If you try to use it for other purposes (e.g., if you try to edit or execute it), the system will send a "file nonexistent" message.
According to the bash man page,
.bash_profile is executed for login shells, while .bashrc is executed for interactive non-login shells.What is a login or non-login shell?
When you login (type username and password) via console, either sitting at the machine, or remotely via ssh:
.bash_profile is executed to configure your shell before the initial command prompt.
But, if you’ve already logged into your machine and open a new terminal window (xterm) inside Gnome or KDE, then
.bashrc is executed before the window command prompt. .bashrc is also run when you start a new bash instance by typing /bin/bash in a terminal.Why two different files?
Say, you’d like to print some lengthy diagnostic information about your machine each time you login (load average, memory usage, current users, etc). You only want to see it on login, so you only want to place this in your
.bash_profile. If you put it in your .bashrc, you’d see it every time you open a new terminal window.Mac OS X — an exception
An exception to the terminal window guidelines is Mac OS X’s Terminal.app, which runs a login shell by default for each new terminal window, calling
.bash_profile instead of .bashrc. Other GUI terminal emulators may do the same, but most tend not to.Recommendation
Most of the time you don’t want to maintain two separate config files for login and non-login shells — when you set a
PATH, you want it to apply to both. You can fix this by sourcing .bashrc from your.bash_profile file, then putting PATH and common settings in .bashrc.To do this, add the following lines to
.bash_profile:https://www.digitalocean.com/community/tutorials/how-to-read-and-set-environmental-and-shell-variables-on-a-linux-vpsif [ -f ~/.bashrc ]; then source ~/.bashrc fi
Environmental variables are variables that are defined for the current shell and are inherited by any child shells or processes. Environmental variables are used to pass information into processes that are spawned from the shell.
Shell variables are variables that are contained exclusively within the shell in which they were set or defined. They are often used to keep track of ephemeral data, like the current working directory.
Common Environmental and Shell Variables
Common Environmental and Shell Variables
- SHELL: This describes the shell that will be interpreting any commands you type in. In most cases, this will be bash by default, but other values can be set if you prefer other options.
- TERM: This specifies the type of terminal to emulate when running the shell. Different hardware terminals can be emulated for different operating requirements. You usually won't need to worry about this though.
- USER: The current logged in user.
- PWD: The current working directory.
- OLDPWD: The previous working directory. This is kept by the shell in order to switch back to your previous directory by running
cd -. - LS_COLORS: This defines color codes that are used to optionally add colored output to the
lscommand. This is used to distinguish different file types and provide more info to the user at a glance. - MAIL: The path to the current user's mailbox.
- PATH: A list of directories that the system will check when looking for commands. When a user types in a command, the system will check directories in this order for the executable.
- LANG: The current language and localization settings, including character encoding.
- HOME: The current user's home directory.
- _: The most recent previously executed command.
In addition to these environmental variables, some shell variables that you'll often see are:
- BASHOPTS: The list of options that were used when bash was executed. This can be useful for finding out if the shell environment will operate in the way you want it to.
- BASH_VERSION: The version of bash being executed, in human-readable form.
- BASH_VERSINFO: The version of bash, in machine-readable output.
- COLUMNS: The number of columns wide that are being used to draw output on the screen.
- DIRSTACK: The stack of directories that are available with the
pushdandpopdcommands. - HISTFILESIZE: Number of lines of command history stored to a file.
- HISTSIZE: Number of lines of command history allowed in memory.
- HOSTNAME: The hostname of the computer at this time.
- IFS: The internal field separator to separate input on the command line. By default, this is a space.
- PS1: The primary command prompt definition. This is used to define what your prompt looks like when you start a shell session. The
PS2is used to declare secondary prompts for when a command spans multiple lines. - SHELLOPTS: Shell options that can be set with the
setoption. - UID: The UID of the current user.
How are shell variables different from environment variables? Whenever you start a new shell or a UNIX program, it inherits all of its parent's environment variables. However, it does not inherit any shell variables; it starts with a clean slate. If you're a programmer, you can think of environment variables as "global" variables, while shell variables are "local" variables. By convention, shell variables have lowercase names.
http://askubuntu.com/questions/26318/environment-variable-vs-shell-variable-whats-the-difference
BASH is a local variable that is valid in the current (bash) shell only.
Environment variables such as SHELL are valid systemwide. In a current Bash shell BASH points to the execution path of bash, whereas SHELL points to the shell defined as default (which may be of the same value).
We can see a list of all of our environmental variables by using the env or printenv commands.
env let's you modify the environment that programs run in by passing a set of variable definitions into a command like this:env VAR1="blahblah" command_to_run command_options
use set to see shell variables
_: The most recent previously executed command.
Unsetting Variables
export -n TEST_VAR
If we want to completely unset a variable, either shell or environmental, we can do so with the unset command:
unset TEST_VAR
The Difference between Login, Non-Login, Interactive, and Non-Interactive Shell Sessions
The bash shell reads different configuration files depending on how the session is started.
One distinction between different sessions is whether the shell is being spawned as a "login" or "non-login" session.
A login shell is a shell session that begins by authenticating the user. If you are signing into a terminal session or through SSH and authenticate, your shell session will be set as a "login" shell.
If you start a new shell session from within your authenticated session, like we did by calling the bash command from the terminal, a non-login shell session is started. You were were not asked for your authentication details when you started your child shell.
Another distinction that can be made is whether a shell session is interactive, or non-interactive.
An interactive shell session is a shell session that is attached to a terminal. A non-interactive shell session is one is not attached to a terminal session.
So each shell session is classified as either login or non-login and interactive or non-interactive.
A normal session that begins with SSH is usually an interactive login shell. A script run from the command line is usually run in a non-interactive, non-login shell. A terminal session can be any combination of these two properties.
Whether a shell session is classified as a login or non-login shell has implications on which files are read to initialize the shell session.
A session started as a login session will read configuration details from the /etc/profile file first. It will then look for the first login shell configuration file in the user's home directory to get user-specific configuration details.
It reads the first file that it can find out of ~/.bash_profile, ~/.bash_login, and ~/.profile and does not read any further files.
In contrast, a session defined as a non-login shell will read /etc/bash.bashrc and then the user-specific ~/.bashrc file to build its environment.
Non-interactive shells read the environmental variable called BASH_ENV and read the file specified to define the new environment.
http://www.cnblogs.com/chengmo/archive/2010/10/27/1862791.html
收获：whatis数据库，并且有makewhatis创建，whatis脚本是用作查询的
makewhatis是怎么样工作的呢？
[chengmo@centos5 ~]$ man makewhatis
#得到：
makewhatis reads all the manual pages contained in the given sections of manpath or the preformatted pages con-tained in the given sections of catpath. For each page, it writes a line in the whatis database; each line consists of the name of the page and a short description, separated by a dash. The description is extracted using the content of the NAME section of the manual page.
#大概意思是：makewhatis 从手册页配置的路径以及领域范围，搜集所有手册页索引信息，每个手册页在数据库加入一行，这行会包括手册页里面name,以及简单描述。
收获：知道这个数据库是建立是索引，并且每个数据库写入一行(a line) ,会不会这个数据库就是文本文件呢？现在到这里，我们不知道数据库保存地方，也不知道它结构，只有看看whatis命令，看它是不是有源码信息
type whatiswhatis is /usr/bin/whatis#告诉路径我们看看内容[chengmo@centos5 ~]$ vi /usr/bin/whatis有run-parts脚本运行/etc/cron.daily目录下面的文件
[chengmo@centos5 ~]$ cd /etc/cron.daily/[chengmo@centos5 cron.daily]$ cat makewhatis.cron#!/bin/bashLOCKFILE=/var/lock/makewhatis.lockmakewhatis -u -w