Attachment #108598 for bug #149447

View | Details | Raw Unified | Return to bug 149447
Collapse All | Expand All




    <title>Synopsis</title>

   <para>The following chapter will cover the basic commands and
     functionality of the &os; operating system.  Much of this
     material is relevant for any &unix;-like operating system.  Feel
     free to skim over this chapter if you are familiar with the
     material.  If you are new to &os;, then you will definitely
     want to read through this chapter carefully.</para>

    <para>After reading this chapter, you will know:</para>

    <itemizedlist>
      <listitem>
        <para>How to use the <quote>virtual consoles</quote> of
	  &os;.</para>
      </listitem>
      <listitem>
	<para>How &unix; file permissions work along with

    <indexterm><primary>virtual consoles</primary></indexterm>
    <indexterm><primary>terminals</primary></indexterm>

    <para>&os; can be used in various ways.  One of them is typing commands
      to a text terminal.  A lot of the flexibility and power of a &unix;
      operating system is readily available at your hands when using &os;
      this way.  This section describes what <quote>terminals</quote> and
      <quote>consoles</quote> are, and how you can use them in &os;.</para>

    <sect2 id="consoles-intro">
      <title>The Console</title>
      <indexterm><primary>console</primary></indexterm>

      <para>If you have not configured &os; to automatically start a
	graphical environment during startup, the system will present you with
	a login prompt after it boots, right after the startup scripts finish
	running.  You will see something similar to:</para>

      <programlisting>FreeBSD/i386 (pc3.example.org) (ttyv0)</programlisting>

      <para>This line contains some bits of information about the system you
        have just booted.  You are looking at a <quote>&os;</quote>
	console, running on an Intel or compatible processor of the x86
	architecture<footnote>
	  <para>This is what <literal>i386</literal> means.  Note that even if
	    you are not running &os; on an Intel 386 CPU, this is going to
	    be <literal>i386</literal>.  It is not the type of your processor,
	    but the processor <quote>architecture</quote> that is shown
	    here.</para>

      <programlisting>login:</programlisting>

      <para>This is the part where you are supposed to type in your
	<quote>username</quote> to log into &os;.  The next section
	describes how you can do this.</para>
    </sect2>

    <sect2 id="consoles-login">
      <title>Logging into &os;</title>

      <para>&os; is a multiuser, multiprocessing system.  This is
	the formal description that is usually given to a system that can be
	used by many different people, who simultaneously run a lot of
	programs on a single machine.</para>

      <para>Every multiuser system needs some way to distinguish one
	<quote>user</quote> from the rest.  In &os; (and all the
	&unix;-like operating systems), this is accomplished by requiring that
	every user must <quote>log into</quote> the system before being able
	to run programs.  Every user has a unique name (the
	<quote>username</quote>) and a personal, secret key (the
	<quote>password</quote>).  &os; will ask for these two before
	allowing a user to run any programs.</para>

      <indexterm><primary>startup scripts</primary></indexterm>
      <para>Right after &os; boots and finishes running its startup
	scripts<footnote>
	  <para>Startup scripts are programs that are run automatically by
	    &os; when booting.  Their main function is to set things up for
	    everything else to run, and start any services that you have
	    configured to run in the background doing useful things.</para>
	</footnote>, it will present you with a prompt and ask for a valid

	it to say that it is done for security reasons.</para>

      <para>If you have typed your password correctly, you should by now be
	logged into &os; and ready to try out all the available
	commands.</para>

      <para>You should see the <acronym>MOTD</acronym> or message of
	the day followed by a command prompt (a <literal>#</literal>,
	<literal>$</literal>, or <literal>%</literal> character).  This
	indicates you have successfully logged into &os;.</para>
    </sect2>

    <sect2 id="consoles-virtual">
      <title>Multiple Consoles</title>

      <para>Running &unix; commands in one console is fine, but &os; can
	run many programs at once.  Having one console where commands can be
	typed would be a bit of a waste when an operating system like &os;
	can run dozens of programs at the same time.  This is where
	<quote>virtual consoles</quote> can be very helpful.</para>

      <para>&os; can be configured to present you with many different
	virtual consoles.  You can switch from one of them to any other
	virtual console by pressing a couple of keys on your keyboard.  Each
	console has its own different output channel, and &os; takes care
	of properly redirecting keyboard input and monitor output as you
	switch from one virtual console to the next.</para>

      <para>Special key combinations have been reserved by &os; for
	switching consoles<footnote>
	  <para>A fairly technical and accurate description of all the details
	    of the &os; console and keyboard drivers can be found in the
	    manual pages of &man.syscons.4;, &man.atkbd.4;, &man.vidcontrol.1;
	    and &man.kbdcontrol.1;.  We will not expand on the details here,
	    but the interested reader can always consult the manual pages for

	<keycombo><keycap>Alt</keycap><keycap>F1</keycap></keycombo>,
	<keycombo><keycap>Alt</keycap><keycap>F2</keycap></keycombo>, through
	<keycombo><keycap>Alt</keycap><keycap>F8</keycap></keycombo> to switch
	to a different virtual console in &os;.</para>

      <para>As you are switching from one console to the next, &os; takes
	care of saving and restoring the screen output.  The result is an
	<quote>illusion</quote> of having multiple <quote>virtual</quote>
	screens and keyboards that you can use to type commands for
	&os; to run.  The programs that you launch on one virtual console
	do not stop running when that console is not visible.  They continue
	running when you have switched to a different virtual console.</para>
    </sect2>

    <sect2 id="consoles-ttys">
      <title>The <filename>/etc/ttys</filename> File</title>

      <para>The default configuration of &os; will start up with eight
        virtual consoles.  This is not a hardwired setting though, and
        you can easily customize your installation to boot with more
        or fewer virtual consoles.  The number and settings of the

        <filename>/etc/ttys</filename> file.</para>

      <para>You can use the <filename>/etc/ttys</filename> file to configure
	the virtual consoles of &os;.  Each uncommented line in this file
	(lines that do not start with a <literal>#</literal> character) contains
	settings for a single terminal or virtual console.  The default
	version of this file that ships with &os; configures nine virtual
	consoles, and enables eight of them.  They are the lines that start with
	<literal>ttyv</literal>:</para>



      <para>A detailed description of what <quote>single user mode</quote> is
	can be found in <xref linkend="boot-singleuser">.  It is worth noting
	that there is only one console when you are running &os; in single
	user mode.  There are no virtual consoles available.  The settings of
	the single user mode console can also be found in the
	<filename>/etc/ttys</filename> file.  Look for the line that starts

      <note>
        <para>As the comments above the <literal>console</literal> line
	  indicate, you can edit this line and change <literal>secure</literal> to
	  <literal>insecure</literal>.  If you do that, when &os; boots
	  into single user mode, it will still ask for the
	  <username>root</username> password.</para>


	  <literal>insecure</literal></emphasis>.  If you ever forget
	  the <username>root</username> password, booting into single user
	  mode is a bit involved.  It is still possible, but it might be a bit
	  hard for someone who is not very comfortable with the &os;
	  booting process and the programs involved.</para>
      </note>
    </sect2>

    <sect2 id="consoles-vidcontrol">
      <title>Changing Console Video Modes</title>

      <para>The &os; console default video mode may be adjusted to
	1024x768, 1280x1024, or any other size supported by your
	graphics chip and monitor.  To use a different video mode, you
	first must recompile your kernel and include two additional

    <title>Permissions</title>
    <indexterm><primary>UNIX</primary></indexterm>

    <para>&os;, being a direct descendant of BSD &unix;, is based on
      several key &unix; concepts.  The first and
      most pronounced is that &os; is a multi-user operating system.
      The system can handle several users all working simultaneously on
      completely unrelated tasks.  The system is responsible for properly
      sharing and managing requests for hardware devices, peripherals,

      of the file's permission.</para>

    <para>This is all well and good, but how does the system control
      permissions on devices? &os; actually treats most hardware
      devices as a file that programs can open, read, and write data to
      just like any other file.  These special device files are stored on
      the <filename>/dev</filename> directory.</para>

    <title>Directory Structure</title>
    <indexterm><primary>directory hierarchy</primary></indexterm>

    <para>The &os; directory hierarchy is fundamental to obtaining
      an overall understanding of the system.  The most important
      concept to grasp is that of the root directory,
      <quote>/</quote>.  This directory is the first one mounted at

	      class="directory">/usr/local/</filename></entry>

	      <entry>Local executables, libraries, etc.  Also used as
	        the default destination for the &os; ports
	        framework.  Within <filename>/usr/local</filename>,
	        the general layout sketched out by &man.hier.7; for
	        <filename>/usr</filename> should be used.  Exceptions

	    
	    <row>
	      <entry><filename class="directory">/usr/ports/</filename></entry>
	      <entry>The &os; Ports Collection (optional).</entry>
	    </row>
	    
	    <row>

  <sect1 id="disk-organization">
      <title>Disk Organization</title>

      <para>The smallest unit of organization that &os; uses to find files
	is the filename.  Filenames are case-sensitive, which means that
	<filename>readme.txt</filename> and <filename>README.TXT</filename>
	are two separate files.  &os; does not use the extension
	(<filename>.txt</filename>) of a file to determine whether the file is
	a program, or a document, or some other form of data.</para>


	<literal>\</literal> to separate file and directory names, while &macos;
	uses <literal>:</literal>.</para>

      <para>&os; does not use drive letters, or other drive names in the
	path.  You would not write <filename>c:/foo/bar/readme.txt</filename>
	on &os;.</para>

      <para>Instead, one file system is designated the <firstterm>root
	  file system</firstterm>.  The root file system's root directory is
	referred to as <literal>/</literal>.  Every other file system is then
	<firstterm>mounted</firstterm> under the root file system.  No matter
	how many disks you have on your &os; system, every directory
	appears to be part of the same disk.</para>

      <para>Suppose you have three file systems, called <literal>A</literal>,

	identical, to the <command>join</command> command.</para>

      <para>This is not normally something you need to concern yourself with.
	Typically you create file systems when installing &os; and decide
	where to mount them, and then never change them unless you add a new
	disk.</para>


	</listitem>

	<listitem>
	  <para>&os; automatically optimizes the layout of files on a
	    file system, depending on how the file system is being used.  So a
	    file system that contains many small files that are written
	    frequently will have a different optimization to one that contains

	</listitem>
	
	<listitem>
	  <para>&os;'s file systems are very robust should you lose power.
	    However, a power loss at a critical point could still damage the
	    structure of the file system.  By splitting your data over multiple
	    file systems it is more likely that the system will still come up,


	<listitem>
	  <para>File systems are a fixed size.  If you create a file system when
	    you install &os; and give it a specific size, you may later
	    discover that you need to make the partition bigger.  This is not
	    easily accomplished without backing up, recreating the file system
	    with the new size, and then restoring the backed up data.</para>

	  <important>
	    <para>&os; features the &man.growfs.8;
	      command, which makes it possible to increase the size of 
	      file system on the fly, removing this limitation.</para>
	  </important>

	typical mount point in the file system hierarchy, or the letter of the
	partition they are contained in.</para>

      <para>&os; also uses disk space for <firstterm>swap
	  space</firstterm>.  Swap space provides &os; with
	<firstterm>virtual memory</firstterm>.  This allows your computer to
	behave as though it has much more memory than it actually does.  When
	&os; runs out of memory it moves some of the data that is not
	currently being used to the swap space, and moves it back in (moving
	something else out) when it needs it.</para>


      </informaltable>

      <para>Each partition-that-contains-a-file-system is stored in what
	&os; calls a <firstterm>slice</firstterm>.  Slice is &os;'s term
	for what the common call partitions, and again, this is because of
	&os;'s &unix; background.  Slices are numbered, starting at 1,
	through to 4.</para>

	<indexterm><primary>slices</primary></indexterm>

	0.  Common codes that you will see are listed in 
	<xref linkend="basics-dev-codes">.</para>

      <para>When referring to a partition &os; requires that you also name
	the slice and disk that contains the partition, and when referring to
	a slice you must also refer to the disk name.
	Thus, you refer to a partition by listing

      <para><xref linkend="basics-concept-disk-model"> shows a conceptual
	model of the disk layout that should help make things clearer.</para>

      <para>In order to install &os; you must first configure the disk
	slices, then create partitions within the slice you will use for
	&os;, and then create a file system (or swap space) in each
	partition, and decide where that file system will be mounted.</para>

      <table frame="none" pgwide="1" id="basics-dev-codes">

      <example id="basics-concept-disk-model">
	<title>Conceptual Model of a Disk</title>

	<para>This diagram shows &os;'s view of the first IDE disk attached
	  to the system.  Assume that the disk is 4&nbsp;GB in size, and contains
	  two 2&nbsp;GB slices (&ms-dos; partitions).  The first slice contains a &ms-dos;
	  disk, <devicename>C:</devicename>, and the second slice contains a
	  &os; installation.  This example &os; installation has three
	  data partitions, and a swap partition.</para>

	<para>The three partitions will each hold a file system.  Partition

	  <term><literal>fstype</literal></term>
            
	  <listitem><para>The file system type to pass to
		&man.mount.8;.  The default &os; file system is
	      <literal>ufs</literal>.</para>
	  </listitem>
	</varlistentry>

  <sect1 id="basics-processes">
    <title>Processes</title>

    <para>&os; is a multi-tasking operating system.  This means that it
      seems as though more than one program is running at once.  Each program
      running at any one time is called a <firstterm>process</firstterm>.
      Every command you run will start at least one new process, and there are

      parent process.  The exception to this is a special process called
      &man.init.8;.  <command>init</command> is always the first
      process, so its PID is always 1.  <command>init</command> is started
      automatically by the kernel when &os; starts.</para>

    <para>Two commands are particularly useful to see the processes on the
      system, &man.ps.1; and &man.top.1;.  The <command>ps</command> command is used to

      <username>root</username> user, who can send signals to everyone's
      processes.</para>

    <para>&os; will also send applications signals in some cases.  If an
      application is badly written, and tries to access memory that it is not
      supposed to, &os; sends the process the <firstterm>Segmentation
	Violation</firstterm> signal (<literal>SIGSEGV</literal>).  If an
      application has used the &man.alarm.3; system call to be alerted after a
      period of time has elapsed then it will be sent the Alarm signal

    <para><literal>SIGKILL</literal> can not be ignored by a process.  This is
      the <quote>I do not care what you are doing, stop right now</quote>
      signal.  If you send <literal>SIGKILL</literal> to a process then
      &os; will stop that process there and then<footnote>
	<para>Not quite true&mdash;there are a few things that can not be
	  interrupted.  For example, if the process is trying to read from a
	  file that is on another computer on the network, and the other

    <indexterm><primary>shells</primary></indexterm>
    <indexterm><primary>command line</primary></indexterm>

    <para>In &os;, a lot of everyday work is done in a command line
      interface called a shell.  A shell's main job is to take commands
      from the input channel and execute them.  A lot of shells also have
      built in functions to help with everyday tasks such as file management,
      file globbing, command line editing, command macros, and environment
      variables.  &os; comes with a set of shells, such as 
      <command>sh</command>, the Bourne Shell, and <command>tcsh</command>, 
      the improved C-shell.  Many other shells are available
      from the &os; Ports Collection, such as
      <command>zsh</command> and <command>bash</command>.</para>

    <para>Which shell do you use?  It is really a matter of taste.  If you


	  <row>
	    <entry><envar>OSTYPE</envar></entry>
	    <entry>Type of operating system.  e.g., &os;.</entry>
	  </row>

	  <row>

    <indexterm><primary>text editors</primary></indexterm>
    <indexterm><primary>editors</primary></indexterm>

    <para>A lot of configuration in &os; is done by editing text files.
      Because of this, it would be a good idea to become familiar
      with a text editor.  &os; comes with a few as part of the base
      system, and many more are available in the Ports Collection.</para>

    <indexterm>

      <primary>editors</primary>
      <secondary><command>emacs</command></secondary>
    </indexterm>
    <para>&os; also comes with more powerful text editors such as
      <application>vi</application> as part of the base system, while other editors, like
      <application>Emacs</application> and <application>vim</application>,
      are part of the &os; Ports Collection (<filename role="package">editors/emacs</filename> and <filename role="package">editors/vim</filename>).  These editors offer much
      more functionality and power at the expense of being a little more
      complicated to learn.  However if you plan on doing a lot of text
      editing, learning a more powerful editor such as


    <para>A device is a term used mostly for hardware-related
      activities in a system, including disks, printers, graphics
      cards, and keyboards.  When &os; boots, the majority
      of what &os; displays are devices being detected.
      You can look through the boot messages again by viewing
      <filename>/var/run/dmesg.boot</filename>.</para>


          has at least three ABIs: SVR4, Solaris, SCO) does it hold
          true.</para>

        <para>&os; tries to work around this problem somewhat by
          providing a utility for <emphasis>branding</emphasis> a
          known <acronym>ELF</acronym> executable with information
          about the ABI it is compliant with.  See the manual page for

      </listitem>
    </itemizedlist>

    <para>&os; comes from the <quote>classic</quote> camp and used
      the &man.a.out.5; format, a technology tried and proven through
      many generations of BSD releases, until the beginning of the 3.X
      branch. Though it was possible to build and run native
      <acronym>ELF</acronym> binaries (and kernels) on a &os;
      system for some time before that, &os; initially resisted the
      <quote>push</quote> to switch to <acronym>ELF</acronym> as the
      default format. Why?  Well, when the Linux camp made their
      painful transition to <acronym>ELF</acronym>, it was not so much

      <acronym>ELF</acronym> tools available offered a solution to the
      shared library problem and were generally seen as <quote>the way
      forward</quote> anyway, the migration cost was accepted as
      necessary and the transition made.  &os;'s shared library
      mechanism is based more closely on Sun's
      &sunos; style shared library mechanism
      and, as such, is very easy to use.</para>

      <filename>a.out</filename> than it was to migrate to
      <acronym>ELF</acronym>.</para>

    <para>However, as time passed, the build tools that &os;
      derived their build tools from (the assembler and loader
      especially) evolved in two parallel trees. The &os; tree
      added shared libraries and fixed some bugs. The GNU folks that
      originally wrote these programs rewrote them and added simpler
      support for building cross compilers, plugging in different
      formats at will, and so on. Since many people wanted to build cross
      compilers targeting &os;, they were out of luck since the
      older sources that &os; had for <application>as</application> and <application>ld</application> were not up to the
      task. The new GNU tools chain (<application>binutils</application>) does support cross
      compiling, <acronym>ELF</acronym>, shared libraries, C++
      extensions, etc. In addition, many vendors are releasing
      <acronym>ELF</acronym> binaries, and it is a good thing for
      &os; to run them.</para>

    <para><acronym>ELF</acronym> is more expressive than <filename>a.out</filename> and
      allows more extensibility in the base system. The

      <title>Manual Pages</title>
      <indexterm><primary>manual pages</primary></indexterm>

      <para>The most comprehensive documentation on &os; is in the form
	of manual pages. Nearly every program on the system comes with a
	short reference manual explaining the basic operation and various
	arguments. These manuals can be viewed with the <command>man</command> command.  Use

      <title>GNU Info Files</title>
      <indexterm><primary>Free Software Foundation</primary></indexterm>

      <para>&os; includes many applications and utilities produced by
	the Free Software Foundation (FSF).  In addition to manual pages,
	these programs come with more extensive hypertext documents called
	<literal>info</literal> files which can be viewed with the

Return to bug 149447