LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

more DocBook tags

This commit is contained in:
tille 2006-10-23 09:23:12 +00:00
parent 52bd4b5287
commit 11c001a5f3
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
LDP/guide/docbook/Intro-Linux/chap4.xml
View File

@ -40,7 +40,7 @@
<prompt>billy:~&gt;</prompt> <command>jobs<indexterm><primary>jobs</primary></indexterm></command>
[1]+ Running xterm &amp;
</screen>
<para>The full job control features are explained in detail in the <command>bash</command> Info pages, so only the frequently used job control<indexterm><primary>Bash</primary><secondary>job control</secondary></indexterm> applications are listed here<indexterm><primary>processes</primary><secondary>job control overview</secondary></indexterm>:</para>
<para>The full job control features are explained in detail in the <command>bash</command> <application>Info</application> pages, so only the frequently used job control<indexterm><primary>Bash</primary><secondary>job control</secondary></indexterm> applications are listed here<indexterm><primary>processes</primary><secondary>job control overview</secondary></indexterm>:</para>
<table frame="all">
<title>Controlling processes</title>
<tgroup cols="2" align="left" colsep="1" rowsep="1">
@ -225,7 +225,7 @@ init-+-amd
|-xfs
`-xinetd-ipv6
</screen>
<para>The <option>-u</option> and <option>-a</option> options give additional information. For more options and what they do, refer to the Info pages.</para>
<para>The <option>-u</option> and <option>-a</option> options give additional information. For more options and what they do, refer to the <application>Info</application> pages.</para>
<para>In the next section, we will see how one process can create another.</para>
</sect2>
@ -254,7 +254,7 @@ init-+-amd
</sect3>
<sect3 id="sect_04_01_05_02"><title>Ending processes</title>
<para>When a process<indexterm><primary>processes</primary><secondary>ending</secondary></indexterm> ends normally (it is not killed or otherwise unexpectedly interrupted), the program returns its <emphasis>exit status<indexterm><primary>exit status</primary></indexterm></emphasis> to the parent. This exit status is a number returned by the program providing the results of the program's execution. The system of returning information upon executing a job has its origin in the C programming language in which UNIX has been written.</para>
<para>The return codes<indexterm><primary>processes</primary><secondary>return codes</secondary></indexterm> can then be interpreted by the parent, or in scripts. The values of the return codes are program-specific. This information can usually be found in the man pages of the specified program, for example the <command>grep</command> command returns <computeroutput>-1</computeroutput> if no matches are found, upon which a message on the lines of "No files found" can be printed. Another example is the Bash Builtin command <command>true</command>, which does nothing except return an exit status of 0, meaning success.</para>
<para>The return codes<indexterm><primary>processes</primary><secondary>return codes</secondary></indexterm> can then be interpreted by the parent, or in scripts. The values of the return codes are program-specific. This information can usually be found in the man pages of the specified program, for example the <command>grep</command> command returns <computeroutput>-1</computeroutput> if no matches are found, upon which a message on the lines of <quote>No files found</quote> can be printed. Another example is the <application>Bash</application> builtin command <command>true</command>, which does nothing except return an exit status of 0, meaning success.</para>
</sect3>
<sect3 id="sect_04_01_05_03"><title>Signals</title>
<para>Processes end<indexterm><primary>processes</primary><secondary>stopping</secondary></indexterm> because they receive a signal<indexterm><primary>processes</primary><secondary>signal</secondary></indexterm>. There are multiple signals that you can send to a process. Use the <command>kill<indexterm><primary>kill</primary></indexterm></command> command to send a signal to a process. The command <command>kill <option>-l</option></command> shows a list of signals. Most signals are for internal use by the system, or for programmers when they write code. As a user, you will need the following signals<indexterm><primary>signals</primary><secondary>overview</secondary></indexterm>:</para>
@ -340,7 +340,7 @@ Message from joe@lo.callhost.org on ptys/1 at 12:36 ...
hey Jenny, shall we have lunch together?
EOF
</screen>
<para>After receiving a message, the terminal can be cleared using the <keycap>Ctrl</keycap>+<keycap>L</keycap> key combination. In order to receive no messages at all (except from the system administrator), use the <command>mesg</command> command. To see which connected users accept messages from others use <command>who <option>-w</option></command>. All features are fully explained in the Info pages of each command.</para>
<para>After receiving a message, the terminal can be cleared using the <keycap>Ctrl</keycap>+<keycap>L</keycap> key combination. In order to receive no messages at all (except from the system administrator), use the <command>mesg</command> command. To see which connected users accept messages from others use <command>who <option>-w</option></command>. All features are fully explained in the <application>Info</application> pages of each command.</para>
<note><title>Group names may vary</title>
<para>The group scheme is specific to the distribution. Other distributions may use other names or other solutions.</para></note>
@ -696,8 +696,8 @@ job 2 at 2001-06-14 02:00
<sect2 id="sect_04_04_04"><title>Cron and crontab</title>
<para>The cron system is managed by the <command>cron</command> daemon<indexterm><primary>daemons</primary><secondary>cron</secondary></indexterm>. It gets information about which programs and when they should run from the system's and users' crontab<indexterm><primary>scheduling</primary><secondary>cron</secondary></indexterm> entries. Only the root user has access to the system crontabs, while each user should only have access to his own crontabs. On some systems (some) users may not have access to the cron facility.</para>
<para>At system startup the cron daemon searches <filename>/var/spool/cron/</filename> for crontab entries which are named after accounts in <filename>/etc/passwd</filename>, it searches <filename>/etc/cron.d/<indexterm><primary>cron.d</primary></indexterm></filename> and it searches <filename>/etc/crontab<indexterm><primary>crontab</primary></indexterm></filename>, then uses this information every minute to check if there is something to be done. It executes commands as the user who owns the crontab file and mails any output of commands to the owner.</para>
<para>On systems using Vixie<indexterm><primary>cron</primary><secondary>Vixie cron</secondary></indexterm> cron, jobs that occur hourly, daily, weekly and monthly are kept in separate directories in <filename>/etc</filename> to keep an overview, as opposed to the standard UNIX cron function, where all tasks are entered into one big file.</para>
<para>Example of a Vixie crontab<indexterm><primary>crontab</primary><secondary>example</secondary></indexterm> file:</para>
<para>On systems using <application>Vixie<indexterm><primary>cron</primary><secondary>Vixie cron</secondary></indexterm></application> cron, jobs that occur hourly, daily, weekly and monthly are kept in separate directories in <filename>/etc</filename> to keep an overview, as opposed to the standard UNIX cron function, where all tasks are entered into one big file.</para>
<para>Example of a <application>Vixie</application> crontab<indexterm><primary>crontab</primary><secondary>example</secondary></indexterm> file:</para>
<screen>
<prompt>[root@blob /etc]#</prompt> <command>more crontab</command>
SHELL=/bin/bash