Eliminate erroneous role="directory" attributes from <filename> elements
and replace them with class="directory" [1][2] [1] http://docbook.org/tdg/en/html/filename.html [2] http://www.freebsd.org/doc/en/books/fdp-primer/sgml-markup-docbook.html#AEN1799 (4.2.5.5) Approved by: trhodes, gabor (mentor)
This commit is contained in:
parent
002b4edbbe
commit
edafad6a69
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=32632
21 changed files with 125 additions and 125 deletions
en_US.ISO8859-1
articles
committers-guide
cvs-freebsd
mh
nanobsd
p4-primer
relaydelay
remote-install
books
developers-handbook/kernelbuild
fdp-primer/the-website
handbook
advanced-networking
disks
firewalls
geom
jails
kernelconfig
linuxemu
mirrors
network-servers
ports
security
pmake/gods
|
@ -256,19 +256,19 @@
|
|||
to the appropriate repomeisters.</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>ncvs@ - regarding <filename role="directory">
|
||||
<listitem><para>ncvs@ - regarding <filename class="directory">
|
||||
/home/ncvs</filename>, the src
|
||||
repository</para></listitem>
|
||||
|
||||
<listitem><para>pcvs@ - regarding <filename role="directory">
|
||||
<listitem><para>pcvs@ - regarding <filename class="directory">
|
||||
/home/pcvs</filename>, the ports
|
||||
repository</para></listitem>
|
||||
|
||||
<listitem><para>dcvs@ - regarding <filename role="directory">
|
||||
<listitem><para>dcvs@ - regarding <filename class="directory">
|
||||
/home/dcvs</filename>, the doc
|
||||
repository</para></listitem>
|
||||
|
||||
<listitem><para>projcvs@ - regarding <filename role="directory">
|
||||
<listitem><para>projcvs@ - regarding <filename class="directory">
|
||||
/home/projcvs</filename>, the
|
||||
third party projects repository</para></listitem>
|
||||
</itemizedlist>
|
||||
|
@ -750,11 +750,11 @@ alias scvs cvs -d <replaceable>user</replaceable>@ncvs.FreeBSD.org:/home/ncvs</p
|
|||
</itemizedlist>
|
||||
|
||||
<para>You will almost certainly get a conflict because
|
||||
of the <literal>$Id: article.sgml,v 1.276 2008-07-22 17:05:47 remko Exp $</literal> (or in FreeBSD's case,
|
||||
of the <literal>$Id: article.sgml,v 1.277 2008-08-06 22:03:48 pgj Exp $</literal> (or in FreeBSD's case,
|
||||
<literal>$<!-- stop expansion -->FreeBSD<!-- stop expansion -->$</literal>)
|
||||
lines, so you will have to edit the file to resolve the conflict
|
||||
(remove the marker lines and the second <literal>$Id: article.sgml,v 1.276 2008-07-22 17:05:47 remko Exp $</literal> line,
|
||||
leaving the original <literal>$Id: article.sgml,v 1.276 2008-07-22 17:05:47 remko Exp $</literal> line intact).</para>
|
||||
(remove the marker lines and the second <literal>$Id: article.sgml,v 1.277 2008-08-06 22:03:48 pgj Exp $</literal> line,
|
||||
leaving the original <literal>$Id: article.sgml,v 1.277 2008-08-06 22:03:48 pgj Exp $</literal> line intact).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
@ -2627,7 +2627,7 @@ docs:Documentation Bug:freebsd-doc:</programlisting>
|
|||
</itemizedlist>
|
||||
|
||||
<para>Alternatively, you can use the <command>rmport</command>
|
||||
script, from <filename role="directory">ports/Tools/scripts</filename>.
|
||||
script, from <filename class="directory">ports/Tools/scripts</filename>.
|
||||
This script has been written by &a.vd;, who is also its current
|
||||
maintainer, so please send questions, patches or suggestions
|
||||
about <command>rmport</command> to him.</para>
|
||||
|
|
|
@ -79,7 +79,7 @@
|
|||
<screen>&prompt.user; <userinput>cvs -d <replaceable>path-to-repository</replaceable> init</userinput></screen>
|
||||
|
||||
<para>This tells <application>CVS</application> to create the
|
||||
<filename role="directory">CVSROOT</filename> administrative directory, where all the
|
||||
<filename class="directory">CVSROOT</filename> administrative directory, where all the
|
||||
customization takes place.</para>
|
||||
</sect2>
|
||||
|
||||
|
@ -105,25 +105,25 @@
|
|||
<sect2>
|
||||
<title>Getting the sources</title>
|
||||
|
||||
<para>Now you need to obtain the <filename role="directory">CVSROOT</filename> directory
|
||||
<para>Now you need to obtain the <filename class="directory">CVSROOT</filename> directory
|
||||
from the FreeBSD repository. This is most easily done by checking it
|
||||
out from a FreeBSD anonymous CVS mirror. See <ulink
|
||||
url="&url.books.handbook;/anoncvs.html">the relevant chapter in
|
||||
the handbook</ulink> for more information. Let us assume that the
|
||||
sources are stored in <filename role="directory">CVSROOT-freebsd</filename> in the
|
||||
sources are stored in <filename class="directory">CVSROOT-freebsd</filename> in the
|
||||
current directory.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Copying the FreeBSD scripts</title>
|
||||
|
||||
<para>Next, we will copy the FreeBSD <filename role="directory">CVSROOT</filename>
|
||||
<para>Next, we will copy the FreeBSD <filename class="directory">CVSROOT</filename>
|
||||
sources into your own repository. If you are accustomed to
|
||||
<application>CVS</application>, you might be thinking that you can just
|
||||
import the scripts, in an attempt to make synchronizing with later
|
||||
versions easier. However, it turns out that
|
||||
<application>CVS</application> has a deficiency in this area:
|
||||
when importing sources into the <filename role="directory">CVSROOT</filename> directory,
|
||||
when importing sources into the <filename class="directory">CVSROOT</filename> directory,
|
||||
it will not update the needed administrative files. In order to make
|
||||
it recognize those, you will need to checkin each file after importing
|
||||
them, losing the value of <literal>cvs import</literal>. Therefore,
|
||||
|
@ -131,7 +131,7 @@
|
|||
|
||||
<para>It does not matter if the above paragraph did not make sense to
|
||||
you—the end result is the same. Simply check out your
|
||||
<filename role="directory">CVSROOT</filename> and copy the FreeBSD files over your
|
||||
<filename class="directory">CVSROOT</filename> and copy the FreeBSD files over your
|
||||
local (untouched) copies:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>cvs -d <replaceable>path-to-your-repository</replaceable> checkout CVSROOT</userinput>
|
||||
|
@ -276,7 +276,7 @@
|
|||
match one of the lines in this file are exempted from this check.
|
||||
You should add expressions to this file as you checkin files that
|
||||
cannot have a revision header. For the purpose of installing the
|
||||
scripts, it may be best to exclude <filename role="directory">CVSROOT/</filename>
|
||||
scripts, it may be best to exclude <filename class="directory">CVSROOT/</filename>
|
||||
from header checks.</para>
|
||||
</listitem>
|
||||
|
||||
|
@ -465,7 +465,7 @@
|
|||
<para><literal>@LOG_FILE_MAP</literal> - change this array
|
||||
as you wish - each regexp is matched on the directory of
|
||||
the commit, and the commit log message gets stored in
|
||||
the <filename role="directory">commitlogs</filename> subdirectory in
|
||||
the <filename class="directory">commitlogs</filename> subdirectory in
|
||||
the filename mentioned.</para>
|
||||
</listitem>
|
||||
|
||||
|
@ -494,7 +494,7 @@
|
|||
<literal>^CVSROOT/</literal>, and add one line with only
|
||||
<literal>^CVSROOT/</literal> on it. After the wrapper is
|
||||
installed, you can add your header to the files in the
|
||||
<filename role="directory">CVSROOT</filename> directory and restore these lines,
|
||||
<filename class="directory">CVSROOT</filename> directory and restore these lines,
|
||||
but for now they will only be in the way when you try to commit
|
||||
later on.</para>
|
||||
</step>
|
||||
|
@ -532,7 +532,7 @@
|
|||
<para>The last thing to do before you are finished, is to make sure
|
||||
the commitlogs can be stored. By default these are stored in
|
||||
the repository, in the <filename>commitlogs</filename> subdirectory
|
||||
of the <filename role="directory">CVSROOT</filename> directory. This directory
|
||||
of the <filename class="directory">CVSROOT</filename> directory. This directory
|
||||
needs to be created, so do the following:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>mkdir commitlogs</userinput>
|
||||
|
@ -542,7 +542,7 @@
|
|||
|
||||
<para>Now, after careful review, you should commit your changes. Be
|
||||
sure that you have granted yourself access to the
|
||||
<filename role="directory">CVSROOT</filename> directory in your
|
||||
<filename class="directory">CVSROOT</filename> directory in your
|
||||
<filename>avail</filename> before you do this, because otherwise you
|
||||
will lock yourself out. So make sure everything is as you intend, and
|
||||
then do the following:</para>
|
||||
|
@ -571,8 +571,8 @@
|
|||
<title>FreeBSD specific setup</title>
|
||||
|
||||
<para>The FreeBSD project itself uses a slightly different setup, which
|
||||
also uses files from the <filename role="directory">freebsd</filename> subdirectory of
|
||||
the FreeBSD <filename role="directory">CVSROOT</filename>. The project uses this because
|
||||
also uses files from the <filename class="directory">freebsd</filename> subdirectory of
|
||||
the FreeBSD <filename class="directory">CVSROOT</filename>. The project uses this because
|
||||
of the large number of committers, which all would have to be in the
|
||||
same group. So, a simple wrapper was written which ensures that people
|
||||
have the correct credentials to commit, and then sets the group id
|
||||
|
@ -641,7 +641,7 @@
|
|||
<para>Next up is installing the wrapper to ensure you become the
|
||||
correct group when committing. The sources for this live in
|
||||
<filename>cvswrap.c</filename> in your
|
||||
<filename role="directory">CVSROOT</filename>.</para>
|
||||
<filename class="directory">CVSROOT</filename>.</para>
|
||||
|
||||
<para>Compile the sources that you edited to include the correct
|
||||
paths:</para>
|
||||
|
|
|
@ -540,7 +540,7 @@ which I am probably the guilty party).</screen>
|
|||
</informalexample>
|
||||
|
||||
<para>That will grab all the email in your <filename
|
||||
role="directory">inbox</filename> that was sent to
|
||||
class="directory">inbox</filename> that was sent to
|
||||
freebsd-hackers or cc'd to that list. The brace options allow
|
||||
you to group search criteria together. This is sometimes very
|
||||
necessary as in the following example</para>
|
||||
|
|
|
@ -104,24 +104,24 @@
|
|||
|
||||
<listitem>
|
||||
<para>The configuration file partition, which can be mounted
|
||||
under the <filename role="directory">/cfg</filename> directory
|
||||
under the <filename class="directory">/cfg</filename> directory
|
||||
at run time.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>These partitions are normally mounted read-only.</para>
|
||||
|
||||
<para>The <filename role="directory">/etc</filename> and
|
||||
<filename role="directory">/var</filename> directories are
|
||||
<para>The <filename class="directory">/etc</filename> and
|
||||
<filename class="directory">/var</filename> directories are
|
||||
&man.md.4; (malloc) disks.</para>
|
||||
|
||||
<para>The configuration file partition persists under the
|
||||
<filename role="directory">/cfg</filename> directory. It
|
||||
contains files for <filename role="directory">/etc</filename>
|
||||
<filename class="directory">/cfg</filename> directory. It
|
||||
contains files for <filename class="directory">/etc</filename>
|
||||
directory and is briefly mounted read-only right after the
|
||||
system boot, therefore it is required to copy modified files
|
||||
from <filename role="directory">/etc</filename> back to the
|
||||
<filename role="directory">/cfg</filename> directory if changes
|
||||
from <filename class="directory">/etc</filename> back to the
|
||||
<filename class="directory">/cfg</filename> directory if changes
|
||||
are expected to persist after the system restarts.</para>
|
||||
|
||||
<example>
|
||||
|
@ -136,11 +136,11 @@
|
|||
|
||||
<note>
|
||||
<para>The partition containing
|
||||
<filename role="directory">/cfg</filename> should be mounted
|
||||
<filename class="directory">/cfg</filename> should be mounted
|
||||
only at boot time and while overriding the configuration
|
||||
files.</para>
|
||||
|
||||
<para>Keeping <filename role="directory">/cfg</filename> mounted at
|
||||
<para>Keeping <filename class="directory">/cfg</filename> mounted at
|
||||
all times is not a good idea, especially if
|
||||
the <application>NanoBSD</application> system runs off a mass
|
||||
storage medium that may be adversely affected by a large number
|
||||
|
@ -155,7 +155,7 @@
|
|||
<para>A <application>NanoBSD</application> image is built using a
|
||||
simple <filename>nanobsd.sh</filename> shell script, which can
|
||||
be found in the
|
||||
<filename role="directory"><replaceable>/usr</replaceable>/src/tools/tools/nanobsd</filename>
|
||||
<filename class="directory"><replaceable>/usr</replaceable>/src/tools/tools/nanobsd</filename>
|
||||
directory. This script creates an image, which can be copied on
|
||||
the storage medium using the &man.dd.1; utility.</para>
|
||||
|
||||
|
@ -290,7 +290,7 @@ customize_cmd cust_foo</programlisting>
|
|||
|
||||
<para>A more useful example of a customization function is the
|
||||
following, which changes the default size of the
|
||||
<filename role="directory">/etc</filename> directory
|
||||
<filename class="directory">/etc</filename> directory
|
||||
from 5MB to 30MB:</para>
|
||||
|
||||
<programlisting>cust_etc_size () (
|
||||
|
@ -318,7 +318,7 @@ customize_cmd cust_etc_size</programlisting>
|
|||
<listitem>
|
||||
<para><literal>cust_install_files</literal> —
|
||||
Installs files from the
|
||||
<filename role="directory">nanobsd/Files</filename>
|
||||
<filename class="directory">nanobsd/Files</filename>
|
||||
directory, which contains some useful scripts for system
|
||||
administration.</para>
|
||||
</listitem>
|
||||
|
@ -446,7 +446,7 @@ customize_cmd cust_nobeastie</programlisting>
|
|||
<application>NanoBSD</application> system, it is possible to use
|
||||
either the <filename>updatep1</filename> or
|
||||
<filename>updatep2</filename> script located in the
|
||||
<filename role="directory">/root</filename> directory, depending
|
||||
<filename class="directory">/root</filename> directory, depending
|
||||
from which partition is running the current system.</para>
|
||||
|
||||
<para>According to which services are available on host serving
|
||||
|
|
|
@ -220,13 +220,13 @@
|
|||
|
||||
<para>This will map the entire
|
||||
<application>Perforce</application> repository to the
|
||||
<filename role="directory">Root</filename> directory of your
|
||||
<filename class="directory">Root</filename> directory of your
|
||||
client. <emphasis>DO NOT USE THIS DEFAULT!</emphasis> The
|
||||
&os; repo is huge, and trying to map and sync it all will
|
||||
take an enormous amount of resources. Instead, only map the
|
||||
section of the repo that you intend to work on. For
|
||||
example, there is the smpng project tree at <filename
|
||||
role="directory">//depot/projects/smpng</filename>. A
|
||||
class="directory">//depot/projects/smpng</filename>. A
|
||||
mapping for this might look like:</para>
|
||||
|
||||
<programlisting>//depot/projects/smpng/... //<replaceable>client</replaceable>/...</programlisting>
|
||||
|
@ -306,7 +306,7 @@
|
|||
|
||||
<para>You can sync a subset of your tree or client by specifying a
|
||||
relative path to the sync command. For example, to only sync the
|
||||
<filename role="directory">ufs</filename> directory of the
|
||||
<filename class="directory">ufs</filename> directory of the
|
||||
<literal>smpng</literal> project, you might do the
|
||||
following:</para>
|
||||
|
||||
|
@ -336,9 +336,9 @@
|
|||
<quote>depot</quote>) is a single flat tree. Every file, whether
|
||||
a unique creation or a derivative from a branch, is accessible via
|
||||
a simple path under the server <filename
|
||||
role="directory">//depot</filename> directory. When you create a
|
||||
class="directory">//depot</filename> directory. When you create a
|
||||
branch, all you are doing is creating a new path under the
|
||||
<filename role="directory">//depot</filename>. This is in sharp
|
||||
<filename class="directory">//depot</filename>. This is in sharp
|
||||
contrast to systems like CVS, where each branch lives in the same
|
||||
path as its parent. With <application>Perforce</application>, the
|
||||
server tracks the relationship between the files in the parent and
|
||||
|
@ -811,7 +811,7 @@
|
|||
Every 2 minutes, the CVS server is polled for updates in the HEAD
|
||||
branch, and those updates are committed to
|
||||
<application>Perforce</application> in the <filename
|
||||
role="directory">//depot/vendor/freebsd/...</filename> tree. This
|
||||
class="directory">//depot/vendor/freebsd/...</filename> tree. This
|
||||
tree is then available for branching and integrating to derivative
|
||||
projects. Any project that directly modifies that &os; source
|
||||
code should have this tree as its branch parent (or grandparent,
|
||||
|
@ -862,19 +862,19 @@
|
|||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><filename
|
||||
role="directory">//depot/projects/soc2005/<replaceable>project-name</replaceable>/...</filename></para>
|
||||
class="directory">//depot/projects/soc2005/<replaceable>project-name</replaceable>/...</filename></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><filename
|
||||
role="directory">//depot/projects/soc2006/<replaceable>project-name</replaceable>/...</filename></para>
|
||||
class="directory">//depot/projects/soc2006/<replaceable>project-name</replaceable>/...</filename></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><filename
|
||||
role="directory">//depot/projects/soc2007/<replaceable>project-name</replaceable>/...</filename></para>
|
||||
class="directory">//depot/projects/soc2007/<replaceable>project-name</replaceable>/...</filename></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><filename
|
||||
role="directory">//depot/projects/soc2008/<replaceable>project-name</replaceable>/...</filename></para>
|
||||
class="directory">//depot/projects/soc2008/<replaceable>project-name</replaceable>/...</filename></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
|
|
@ -141,7 +141,7 @@
|
|||
is beyond the scope of this document.</para>
|
||||
|
||||
<para>Change the working directory to the
|
||||
<filename role="directory">relaydelay-0.04</filename>
|
||||
<filename class="directory">relaydelay-0.04</filename>
|
||||
directory:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cd relaydelay-0.04</userinput></screen>
|
||||
|
@ -164,7 +164,7 @@
|
|||
|
||||
<para>If everything worked correctly a new file,
|
||||
<filename>relaydelay.log</filename>, should exist in
|
||||
<filename role="directory">/var/log</filename>. It should
|
||||
<filename class="directory">/var/log</filename>. It should
|
||||
contain something similar to the following text:</para>
|
||||
|
||||
<programlisting>Loaded Config File: /etc/mail/relaydelay.conf
|
||||
|
@ -192,7 +192,7 @@ Starting Sendmail::Milter 0.18 engine.</programlisting>
|
|||
<ulink url="http://lists.puremagic.com/pipermail/greylist-users/2003-November/000327.html">
|
||||
http://lists.puremagic.com/pipermail/greylist-users/2003-November/000327.html</ulink>
|
||||
and save it in the
|
||||
<filename role="directory">relaydelay-0.04</filename>
|
||||
<filename class="directory">relaydelay-0.04</filename>
|
||||
directory. In the following examples this script is
|
||||
referred to as <filename>addlist.pl</filename>.</para>
|
||||
|
||||
|
|
|
@ -229,10 +229,10 @@ ifconfig_re0="inet 192.168.0.2 netmask 255.255.255.0"</programlisting>
|
|||
<para>The first step is to mount the &os; installation
|
||||
<acronym>CD</acronym>, or the installation
|
||||
<acronym>ISO</acronym> image to <filename
|
||||
role="directory">/cdrom</filename>. For the sake of example,
|
||||
class="directory">/cdrom</filename>. For the sake of example,
|
||||
in this article we will assume that you have downloaded the &os;
|
||||
7.0-RELEASE <acronym>ISO</acronym>. Mounting this ISO image to
|
||||
the <filename role="directory">/cdrom</filename> directory is
|
||||
the <filename class="directory">/cdrom</filename> directory is
|
||||
easy with the &man.mdconfig.8; utility:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>mdconfig -a -t vnode -u 10 -f <replaceable>7.0-RELEASE-amd64-disc1.iso</replaceable></userinput>
|
||||
|
@ -247,7 +247,7 @@ ifconfig_re0="inet 192.168.0.2 netmask 255.255.255.0"</programlisting>
|
|||
<para>The above <command>make</command> command has to be run
|
||||
from the top level of the <application>mfsBSD</application>
|
||||
directory tree, i.e. <filename
|
||||
role="directory">~/mfsbsd-1.0-beta1/</filename>.</para>
|
||||
class="directory">~/mfsbsd-1.0-beta1/</filename>.</para>
|
||||
</note>
|
||||
</sect2>
|
||||
|
||||
|
@ -317,9 +317,9 @@ ifconfig_re0="inet 192.168.0.2 netmask 255.255.255.0"</programlisting>
|
|||
introduction, this article will present how to set up a system
|
||||
with RAID-1 and <application>ZFS</application> capabilities.
|
||||
Our set up will consist of a small &man.gmirror.8; mirrored
|
||||
<filename role="directory">/</filename> (root), <filename
|
||||
role="directory">/usr</filename> and <filename
|
||||
role="directory">/var</filename> file systems, and the rest of
|
||||
<filename class="directory">/</filename> (root), <filename
|
||||
class="directory">/usr</filename> and <filename
|
||||
class="directory">/var</filename> file systems, and the rest of
|
||||
the disk space will be allocated for a &man.zpool.8; mirrored
|
||||
<application>ZFS</application> file system. Please note, that
|
||||
the <application>ZFS</application> file system will be
|
||||
|
@ -363,11 +363,11 @@ ifconfig_re0="inet 192.168.0.2 netmask 255.255.255.0"</programlisting>
|
|||
to the &man.bsdlabel.8; manual page in order to find out how
|
||||
to create partitions. Create partitions
|
||||
<literal>a</literal> for <filename
|
||||
role="directory">/</filename> (root) file system,
|
||||
class="directory">/</filename> (root) file system,
|
||||
<literal>b</literal> for swap, <literal>d</literal> for
|
||||
<filename role="directory">/var</filename>,
|
||||
<filename class="directory">/var</filename>,
|
||||
<literal>e</literal> for <filename
|
||||
role="directory">/usr</filename> and finally
|
||||
class="directory">/usr</filename> and finally
|
||||
<literal>f</literal> which will later be used for
|
||||
<application>ZFS</application>.</para>
|
||||
</callout>
|
||||
|
@ -417,7 +417,7 @@ ifconfig_re0="inet 192.168.0.2 netmask 255.255.255.0"</programlisting>
|
|||
<keycap>Enter</keycap>. With the help of arrow keys, move the
|
||||
cursor on the <literal>Install Root</literal> item, press
|
||||
<keycap>Space</keycap> and change it to <filename
|
||||
role="directory">/mnt</filename>. Press
|
||||
class="directory">/mnt</filename>. Press
|
||||
<keycap>Enter</keycap> to submit your changes and exit the
|
||||
<guimenuitem>Options</guimenuitem> menu by pressing
|
||||
<keycap>q</keycap>.</para>
|
||||
|
@ -474,7 +474,7 @@ ifconfig_re0="inet 192.168.0.2 netmask 255.255.255.0"</programlisting>
|
|||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Copy the <literal>GENERIC</literal> kernel to the
|
||||
<filename role="directory">/boot/kernel</filename>
|
||||
<filename class="directory">/boot/kernel</filename>
|
||||
directory:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cp -Rp /boot/GENERIC/* /boot/kernel</userinput></screen>
|
||||
|
|
|
@ -37,7 +37,7 @@
|
|||
<para>Up to version 4.X of &os; this was the recommended way to
|
||||
build a new kernel. It can still be used on newer versions
|
||||
(instead of the <quote>buildkernel</quote> target of the toplevel
|
||||
<filename role="directory">/usr/src/</filename> makefiles).
|
||||
<filename class="directory">/usr/src/</filename> makefiles).
|
||||
Building the kernel this way may be useful when working on the
|
||||
kernel code and it may actually be faster than the
|
||||
<quote>New</quote> procedure when only a single option or two were
|
||||
|
|
|
@ -130,12 +130,12 @@ ports-base</programlisting>
|
|||
<screen>&prompt.root; <userinput><command>csup</command> <option>-g</option> <option>-L2</option> <replaceable>doc-www-supfile</replaceable></userinput></screen>
|
||||
|
||||
<para>When this command finishes, you will find the directories
|
||||
<filename role="directory">doc/</filename>,
|
||||
<filename role="directory">www/</filename> and
|
||||
<filename role="directory">ports/</filename> under the directory you
|
||||
<filename class="directory">doc/</filename>,
|
||||
<filename class="directory">www/</filename> and
|
||||
<filename class="directory">ports/</filename> under the directory you
|
||||
specified in <literal>default prefix</literal>
|
||||
(<filename
|
||||
role="directory"><replaceable>/usr/build</replaceable></filename>
|
||||
class="directory"><replaceable>/usr/build</replaceable></filename>
|
||||
in our example). We will use this same directory for the build
|
||||
process itself, so it would be better to use a filesystem with
|
||||
sufficient free space.</para>
|
||||
|
@ -250,7 +250,7 @@ cvsroot-doc</programlisting>
|
|||
<para>Having completed either of the two methods, you will be ready to
|
||||
start the website build. In our example, the build directory is
|
||||
<filename
|
||||
role="directory"><replaceable>/usr/build</replaceable></filename>
|
||||
class="directory"><replaceable>/usr/build</replaceable></filename>
|
||||
and all the required files are already in place.</para>
|
||||
|
||||
<procedure>
|
||||
|
@ -262,7 +262,7 @@ cvsroot-doc</programlisting>
|
|||
|
||||
<step>
|
||||
<para>The website build starts from the
|
||||
<filename role="directory">www/en</filename> directory by executing
|
||||
<filename class="directory">www/en</filename> directory by executing
|
||||
the &man.make.1; <maketarget>all</maketarget> target, to create
|
||||
the web pages.</para>
|
||||
|
||||
|
@ -278,7 +278,7 @@ cvsroot-doc</programlisting>
|
|||
<procedure>
|
||||
<step>
|
||||
<para>If you have moved out of the
|
||||
<filename role="directory">en</filename> directory, change back to
|
||||
<filename class="directory">en</filename> directory, change back to
|
||||
it.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput><command>cd</command> <replaceable>/usr/build/www/en</replaceable></userinput></screen>
|
||||
|
@ -351,7 +351,7 @@ cvsroot-doc</programlisting>
|
|||
<listitem>
|
||||
<para>If set and not empty, the makefiles will build and install
|
||||
only the HTML pages from the www directory. All documents from
|
||||
the <filename role="directory">doc</filename> directory (Handbook,
|
||||
the <filename class="directory">doc</filename> directory (Handbook,
|
||||
FAQ, Tutorials) will be ignored. E.g.:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput><command>make</command> <makevar>WEB_ONLY=YES</makevar> <maketarget>all</maketarget> <maketarget>install</maketarget></userinput></screen>
|
||||
|
@ -364,7 +364,7 @@ cvsroot-doc</programlisting>
|
|||
<listitem>
|
||||
<para>If set, the makefiles will not checkout files from the ports
|
||||
cvs repository. Instead, it will copy the files from
|
||||
<filename role="directory">/usr/ports</filename> (or where the
|
||||
<filename class="directory">/usr/ports</filename> (or where the
|
||||
variable <envar>PORTSBASE</envar> points to).</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
|
@ -3654,7 +3654,7 @@ subnet 192.168.4.0 netmask 255.255.255.0 {
|
|||
<filename>pxeboot</filename>, not the kernel. There are other
|
||||
interesting possibilities, like loading
|
||||
<filename>pxeboot</filename> from a &os; CD-ROM
|
||||
<filename role="directory">/boot</filename> directory (as
|
||||
<filename class="directory">/boot</filename> directory (as
|
||||
&man.pxeboot.8; can load a <filename>GENERIC</filename> kernel,
|
||||
this makes it possible to use <acronym>PXE</acronym> to boot
|
||||
from a remote CD-ROM).</para>
|
||||
|
|
|
@ -3875,7 +3875,7 @@ device crypto</programlisting>
|
|||
<para>The following example will describe how to generate a
|
||||
key file, which will be used as part of the Master Key for
|
||||
the encrypted provider mounted under
|
||||
<filename role="directory">/private</filename>. The key
|
||||
<filename class="directory">/private</filename>. The key
|
||||
file will provide some random data used to encrypt the
|
||||
Master Key. The Master Key will be protected by a
|
||||
passphrase as well. Provider's sector size will be 4kB big.
|
||||
|
@ -3947,7 +3947,7 @@ Filesystem Size Used Avail Capacity Mounted on
|
|||
<title>Unmounting and Detaching the Provider</title>
|
||||
|
||||
<para>Once the work on the encrypted partition is done, and
|
||||
the <filename role="directory">/private</filename> partition
|
||||
the <filename class="directory">/private</filename> partition
|
||||
is no longer needed, it is prudent to consider unmounting
|
||||
and detaching the <command>geli</command> encrypted
|
||||
partition from the kernel.</para>
|
||||
|
|
|
@ -243,9 +243,9 @@
|
|||
|
||||
<note>
|
||||
<para>As of &os; 7.0 the sample <filename>pf.conf</filename>
|
||||
that was in <filename role="directory">/etc/</filename> has been
|
||||
that was in <filename class="directory">/etc/</filename> has been
|
||||
moved to <filename
|
||||
role="directory">/usr/share/examples/pf/</filename>. For &os;
|
||||
class="directory">/usr/share/examples/pf/</filename>. For &os;
|
||||
versions prior to 7.0 there is an <filename>/etc/pf.conf</filename>
|
||||
by default.</para>
|
||||
</note>
|
||||
|
|
|
@ -86,7 +86,7 @@
|
|||
<para>GEOM permits access and control to classes — Master Boot
|
||||
Records, <acronym>BSD</acronym> labels, etc — through the
|
||||
use of providers, or the special files in
|
||||
<filename role="directory">/dev</filename>. Supporting various
|
||||
<filename class="directory">/dev</filename>. Supporting various
|
||||
software <acronym>RAID</acronym> configurations, GEOM will
|
||||
transparently provide access to the operating system and
|
||||
operating system utilities.</para>
|
||||
|
@ -156,7 +156,7 @@
|
|||
<step><para>Ensure that a suitable mount point exists. If this
|
||||
volume will become a root partition, then temporarily use
|
||||
another mount point such as <filename
|
||||
role="directory">/mnt</filename>:</para>
|
||||
class="directory">/mnt</filename>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>mkdir /mnt</userinput></screen>
|
||||
</step>
|
||||
|
@ -185,7 +185,7 @@ XXX: What message? Put it inside the screen output above.
|
|||
</step>
|
||||
|
||||
<step><para>This process should have created two other devices
|
||||
in the <filename role="directory">/dev/stripe</filename>
|
||||
in the <filename class="directory">/dev/stripe</filename>
|
||||
directory in addition to the <devicename>st0</devicename> device.
|
||||
Those include <devicename>st0a</devicename> and
|
||||
<devicename>st0c</devicename>. At this point a file system may be created
|
||||
|
@ -246,7 +246,7 @@ XXX: What message? Put it inside the screen output above.
|
|||
<para>Begin by installing &os; on the first disk with only two
|
||||
partitions. One should be a swap partition, double the
|
||||
<acronym>RAM</acronym> size and all remaining space devoted to
|
||||
the root (<filename role="directory">/</filename>) file system.
|
||||
the root (<filename class="directory">/</filename>) file system.
|
||||
It is possible to have separate partitions for other mount points;
|
||||
however, this will increase the difficulty level ten fold due to
|
||||
manual alteration of the &man.bsdlabel.8; and &man.fdisk.8;
|
||||
|
@ -275,7 +275,7 @@ Done.</screen>
|
|||
<note>
|
||||
<para>This command should have created the
|
||||
<devicename>gm0</devicename>, device node under the
|
||||
<filename role="directory">/dev/mirror</filename>
|
||||
<filename class="directory">/dev/mirror</filename>
|
||||
directory.</para>
|
||||
</note>
|
||||
|
||||
|
@ -303,7 +303,7 @@ Done.</screen>
|
|||
<para>This should have caused the system to spit out some
|
||||
information and a bunch of numbers. This is good. Examine the
|
||||
screen for any error messages and mount the device to the
|
||||
<filename role="directory">/mnt</filename> mount point:</para>
|
||||
<filename class="directory">/mnt</filename> mount point:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>mount /dev/mirror/gm0s1a /mnt</userinput></screen>
|
||||
|
||||
|
@ -432,7 +432,7 @@ ggate0
|
|||
&prompt.root; <userinput>mount /dev/ggate0 /mnt</userinput></screen>
|
||||
|
||||
<para>From here on, the device may be accessed through the
|
||||
<filename role="directory">/mnt</filename> mount point.</para>
|
||||
<filename class="directory">/mnt</filename> mount point.</para>
|
||||
|
||||
<note>
|
||||
<para>It should be pointed out that this will fail if the device
|
||||
|
|
|
@ -253,10 +253,10 @@ is not required on &os; 6.0 and later.</para></footnote>
|
|||
<para>Selecting a location for a jail is the best starting point.
|
||||
This is where the jail will physically reside within the file system of the jail's host.
|
||||
A good choice can be <filename
|
||||
role="directory">/usr/jail/<replaceable>jailname</replaceable></filename>,
|
||||
class="directory">/usr/jail/<replaceable>jailname</replaceable></filename>,
|
||||
where <replaceable>jailname</replaceable> is the hostname
|
||||
identifying the jail. The <filename
|
||||
role="directory">/usr/</filename> file system usually has
|
||||
class="directory">/usr/</filename> file system usually has
|
||||
enough space for the jail file system, which for <quote>complete</quote> jails is, essentially,
|
||||
a replication of every file present in a default installation
|
||||
of the &os; base system.</para>
|
||||
|
@ -275,10 +275,10 @@ is not required on &os; 6.0 and later.</para></footnote>
|
|||
<para>The <maketarget>distribution</maketarget> target for
|
||||
<application>make</application> installs every needed
|
||||
configuration file. In simple words, it installs every installable file of
|
||||
<filename role="directory">/usr/src/etc/</filename> to the
|
||||
<filename role="directory">/etc</filename> directory of the jail
|
||||
<filename class="directory">/usr/src/etc/</filename> to the
|
||||
<filename class="directory">/etc</filename> directory of the jail
|
||||
environment:
|
||||
<filename role="directory">$D/etc/</filename>.</para>
|
||||
<filename class="directory">$D/etc/</filename>.</para>
|
||||
</callout>
|
||||
|
||||
<callout arearefs="jaildevfs">
|
||||
|
@ -592,38 +592,38 @@ jail_<replaceable>www</replaceable>_devfs_ruleset="<replaceable>www_ruleset</rep
|
|||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Each jail will be mounted under the <filename
|
||||
role="directory">/home/j</filename> directory.</para>
|
||||
class="directory">/home/j</filename> directory.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><filename role="directory">/home/j/mroot</filename> is
|
||||
<para><filename class="directory">/home/j/mroot</filename> is
|
||||
the template for each jail and the read-only partition for
|
||||
all of the jails.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A blank directory will be created for each jail under
|
||||
the <filename role="directory">/home/j</filename>
|
||||
the <filename class="directory">/home/j</filename>
|
||||
directory.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Each jail will have a <filename
|
||||
role="directory">/s</filename> directory, that will be
|
||||
class="directory">/s</filename> directory, that will be
|
||||
linked to the read-write portion of the system.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Each jail shall have its own read-write system that is
|
||||
based upon <filename
|
||||
role="directory">/home/j/skel</filename>.</para>
|
||||
class="directory">/home/j/skel</filename>.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Each jailspace (read-write portion of each jail) shall
|
||||
be created in <filename
|
||||
role="directory">/home/js</filename>.<para>
|
||||
class="directory">/home/js</filename>.<para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<note>
|
||||
<para>This assumes that the jails are based under the
|
||||
<filename role="directory">/home</filename> partition. This
|
||||
<filename class="directory">/home</filename> partition. This
|
||||
can, of course, be changed to anything else, but this change
|
||||
will have to be reflected in each of the examples
|
||||
below.</para>
|
||||
|
@ -697,7 +697,7 @@ jail_<replaceable>www</replaceable>_devfs_ruleset="<replaceable>www_ruleset</rep
|
|||
<para>Now, symlink the read-write file system to the
|
||||
read-only file system. Please make sure that the symlinks
|
||||
are created in the correct <filename
|
||||
role="directory">s/</filename> locations. Real
|
||||
class="directory">s/</filename> locations. Real
|
||||
directories or the creation of directories in the wrong
|
||||
locations will cause the installation to fail.</para>
|
||||
|
||||
|
@ -790,12 +790,12 @@ jail_www_devfs_enable="YES"</programlisting>
|
|||
<para>The reason why the
|
||||
<varname>jail_<replaceable>name</replaceable>_rootdir</varname>
|
||||
variable is set to <filename
|
||||
role="directory">/usr/home</filename> instead of
|
||||
<filename role="directory">/home</filename> is that the
|
||||
class="directory">/usr/home</filename> instead of
|
||||
<filename class="directory">/home</filename> is that the
|
||||
physical path of the <filename
|
||||
role="directory">/home</filename> directory on a
|
||||
class="directory">/home</filename> directory on a
|
||||
default &os; installation is <filename
|
||||
role="directory">/usr/home</filename>. The
|
||||
class="directory">/usr/home</filename>. The
|
||||
<varname>jail_<replaceable>name</replaceable>_rootdir</varname>
|
||||
variable must <emphasis>not</emphasis> be set to a path
|
||||
which includes a symbolic link, otherwise the jails will
|
||||
|
@ -875,7 +875,7 @@ jail_www_devfs_enable="YES"</programlisting>
|
|||
<para>The first step is to upgrade the host system in the
|
||||
usual manner. Then create a new temporary read-only
|
||||
template in <filename
|
||||
role="directory">/home/j/mroot2</filename>.</para>
|
||||
class="directory">/home/j/mroot2</filename>.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>mkdir /home/j/mroot2</userinput>
|
||||
&prompt.root; <userinput>cd /usr/src</userinput>
|
||||
|
@ -923,7 +923,7 @@ jail_www_devfs_enable="YES"</programlisting>
|
|||
|
||||
<note>
|
||||
<para>The read-write systems are attached to the read-only
|
||||
system (<filename role="directory">/s</filename>) and
|
||||
system (<filename class="directory">/s</filename>) and
|
||||
must be unmounted first.</para>
|
||||
</note>
|
||||
</step>
|
||||
|
|
|
@ -222,7 +222,7 @@ ath_hal(4) - Atheros Hardware Access Layer (HAL)</programlisting>
|
|||
it may already exist as a module.</para>
|
||||
|
||||
<para>Kernel modules exist in the
|
||||
<filename role="directory">/boot/kernel</filename> directory
|
||||
<filename class="directory">/boot/kernel</filename> directory
|
||||
and may be dynamically loaded into the running kernel using
|
||||
&man.kldload.8;. Most, if not all kernel drivers have a
|
||||
specific module and manual page. For example, the last section
|
||||
|
@ -392,7 +392,7 @@ ath_hal(4) - Atheros Hardware Access Layer (HAL)</programlisting>
|
|||
|
||||
<step>
|
||||
<para>Change to the <filename
|
||||
role="directory">/usr/src</filename> directory:</para>
|
||||
class="directory">/usr/src</filename> directory:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cd /usr/src</userinput></screen>
|
||||
</step>
|
||||
|
|
|
@ -409,7 +409,7 @@ multi on</programlisting>
|
|||
<para>The shell scripts that
|
||||
<application>&mathematica;</application> created during
|
||||
installation have to be modified before you can use them. If
|
||||
you chose <filename role="directory">/usr/local/bin</filename>
|
||||
you chose <filename class="directory">/usr/local/bin</filename>
|
||||
as the directory to place the
|
||||
<application>&mathematica;</application> executables in, you
|
||||
will find symlinks in this directory to files called
|
||||
|
|
|
@ -2468,7 +2468,7 @@ doc/zh_*</screen>
|
|||
|
||||
<note>
|
||||
<para>In the default installation
|
||||
<filename role="directory">/usr/ports</filename> is not
|
||||
<filename class="directory">/usr/ports</filename> is not
|
||||
created. If you run &os; 6.0-RELEASE, it should be created before
|
||||
<command>portsnap</command> is used. On more recent
|
||||
versions of &os; or <application>Portsnap</application>,
|
||||
|
|
|
@ -3104,7 +3104,7 @@ dhcpd_ifaces="dc0"</programlisting>
|
|||
<hostid>org.</hostid>, as <hostid>org.</hostid> is more specific
|
||||
than the root zone. The layout of each part of a hostname is
|
||||
much like a file system: the
|
||||
<filename role="directory">/dev</filename> directory falls
|
||||
<filename class="directory">/dev</filename> directory falls
|
||||
within the root, and so on.</para>
|
||||
</sect2>
|
||||
|
||||
|
@ -3188,7 +3188,7 @@ dhcpd_ifaces="dc0"</programlisting>
|
|||
</row>
|
||||
|
||||
<row>
|
||||
<entry><filename role="directory">/etc/namedb</filename></entry>
|
||||
<entry><filename class="directory">/etc/namedb</filename></entry>
|
||||
<entry>Directory where BIND zone information resides.</entry>
|
||||
</row>
|
||||
|
||||
|
@ -3202,10 +3202,10 @@ dhcpd_ifaces="dc0"</programlisting>
|
|||
|
||||
<para>Depending on how a given zone is configured on the server,
|
||||
the files related to that zone can be found in the <filename
|
||||
role="directory">master</filename>, <filename
|
||||
role="directory">slave</filename>, or <filename
|
||||
role="directory">dynamic</filename> subdirectories of the
|
||||
<filename role="directory">/etc/namedb</filename> directory.
|
||||
class="directory">master</filename>, <filename
|
||||
class="directory">slave</filename>, or <filename
|
||||
class="directory">dynamic</filename> subdirectories of the
|
||||
<filename class="directory">/etc/namedb</filename> directory.
|
||||
These files contain the <acronym>DNS</acronym> information that
|
||||
will be given out by the name server in response to queries.</para>
|
||||
</sect2>
|
||||
|
@ -3253,7 +3253,7 @@ dhcpd_ifaces="dc0"</programlisting>
|
|||
|
||||
<para>Configuration files for <application>named</application>
|
||||
currently reside in
|
||||
<filename role="directory">/etc/namedb</filename> directory and
|
||||
<filename class="directory">/etc/namedb</filename> directory and
|
||||
will need modification before use, unless all that is needed is
|
||||
a simple resolver. This is where most of the configuration will
|
||||
be performed.</para>
|
||||
|
@ -3262,7 +3262,7 @@ dhcpd_ifaces="dc0"</programlisting>
|
|||
<title>Using <command>make-localhost</command></title>
|
||||
|
||||
<para>To configure a master zone for the localhost visit the
|
||||
<filename role="directory">/etc/namedb</filename> directory
|
||||
<filename class="directory">/etc/namedb</filename> directory
|
||||
and run the following command:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>sh make-localhost</userinput></screen>
|
||||
|
|
|
@ -309,7 +309,7 @@ lsof: /usr/ports/sysutils/lsof</screen>
|
|||
/usr/ports/sysutils/lsof</screen>
|
||||
|
||||
<para>Note that this will return any matched files downloaded into the
|
||||
<filename role="directory">/usr/ports/distfiles</filename>
|
||||
<filename class="directory">/usr/ports/distfiles</filename>
|
||||
directory.</para>
|
||||
</listitem>
|
||||
|
||||
|
@ -635,7 +635,7 @@ docbook =
|
|||
role="package">net/csup</filename> port/package.</para>
|
||||
</note>
|
||||
|
||||
<para>Make sure <filename role="directory">/usr/ports</filename>
|
||||
<para>Make sure <filename class="directory">/usr/ports</filename>
|
||||
is empty before you run <application>csup</application> for
|
||||
the first time! If you already have the Ports Collection present,
|
||||
obtained from another source, <application>csup</application>
|
||||
|
@ -716,12 +716,12 @@ docbook =
|
|||
<para>Since &os; 6.1-RELEASE and with recent versions
|
||||
of the <application>Portsnap</application> port or package, you
|
||||
can safely skip this step. The <filename
|
||||
role="directory">/usr/ports</filename> will be created
|
||||
class="directory">/usr/ports</filename> will be created
|
||||
automatically at first use of the &man.portsnap.8; command.
|
||||
With previous versions of
|
||||
<application>Portsnap</application>, you will have to
|
||||
create an empty directory <filename
|
||||
role="directory">/usr/ports</filename> if it does not
|
||||
class="directory">/usr/ports</filename> if it does not
|
||||
exists:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>mkdir /usr/ports</userinput></screen>
|
||||
|
@ -729,7 +729,7 @@ docbook =
|
|||
|
||||
<step>
|
||||
<para>Download a compressed snapshot of the Ports Collection into
|
||||
<filename role="directory">/var/db/portsnap</filename>. You can
|
||||
<filename class="directory">/var/db/portsnap</filename>. You can
|
||||
disconnect from the Internet after this step, if you wish.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>portsnap fetch</userinput></screen>
|
||||
|
@ -738,13 +738,13 @@ docbook =
|
|||
<step>
|
||||
<para>If you are running <application>Portsnap</application> for the
|
||||
first time, extract the snapshot into <filename
|
||||
role="directory">/usr/ports</filename>:
|
||||
class="directory">/usr/ports</filename>:
|
||||
</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>portsnap extract</userinput></screen>
|
||||
|
||||
<para>If you already have a populated <filename
|
||||
role="directory">/usr/ports</filename> and you are just updating,
|
||||
class="directory">/usr/ports</filename> and you are just updating,
|
||||
run the following command instead:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>portsnap update</userinput></screen>
|
||||
|
@ -1260,7 +1260,7 @@ ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ fetch</userinput></screen>
|
|||
<filename role="package">ports-mgmt/portmanager</filename>
|
||||
port:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cd <filename role="directory">/usr/ports/ports-mgmt/portmanager</filename></userinput>
|
||||
<screen>&prompt.root; <userinput>cd <filename class="directory">/usr/ports/ports-mgmt/portmanager</filename></userinput>
|
||||
&prompt.root; <userinput>make install clean</userinput></screen>
|
||||
|
||||
<para>All the installed ports can be upgraded using this simple
|
||||
|
@ -1304,7 +1304,7 @@ ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ fetch</userinput></screen>
|
|||
<filename role="package">ports-mgmt/portmaster</filename>
|
||||
port:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cd <filename role="directory">/usr/ports/ports-mgmt/portmaster</filename></userinput>
|
||||
<screen>&prompt.root; <userinput>cd <filename class="directory">/usr/ports/ports-mgmt/portmaster</filename></userinput>
|
||||
&prompt.root; <userinput>make install clean</userinput></screen>
|
||||
|
||||
<para><application>Portmaster</application> groups ports into four
|
||||
|
|
|
@ -2657,7 +2657,7 @@ kadmind5_server_enable="YES"</programlisting>
|
|||
|
||||
<para>This is done because the applications for
|
||||
<acronym>MIT</acronym> kerberos installs binaries in the
|
||||
<filename role="directory">/usr/local</filename>
|
||||
<filename class="directory">/usr/local</filename>
|
||||
hierarchy.</para>
|
||||
</sect2>
|
||||
|
||||
|
|
|
@ -42,8 +42,8 @@
|
|||
<programlisting>.PATH.h : /sprite/lib/include /sprite/att/lib/include</programlisting>
|
||||
|
||||
<para>would tell <application>PMake</application> to look in the
|
||||
directories <filename role="directory">/sprite/lib/include</filename> and
|
||||
<filename role="directory">/sprite/att/lib/include</filename> for any
|
||||
directories <filename class="directory">/sprite/lib/include</filename> and
|
||||
<filename class="directory">/sprite/att/lib/include</filename> for any
|
||||
files whose suffix is <filename>.h</filename>.</para>
|
||||
|
||||
<para>The current directory is always consulted first to see if a
|
||||
|
|
Loading…
Reference in a new issue