bashguide.html

<!-- start pandoc -->

<h1 data-number="1" id="bash-quick-guide">
  <span class="header-section-number">1</span> Bash Quick Guide
</h1>
<p>
  Bash is an acronym for Bourne Again Shell. It is based on the Bourne shell and
  is mostly compatible with its features.
</p>
<p>
  Shells are command interpreters. They are applications that provide users with
  the ability to give commands to their operating system interactively, or to
  execute batches of commands quickly. In no way are they required for the
  execution of programs; they are merely a layer between system function calls
  and the user.
</p>
<p>
  Think of a shell as a way for you to speak to your system. Your system doesn’t
  need it for most of its work, but it is an excellent interface between you and
  what your system can offer. It allows you to perform basic math, run basic
  tests and execute applications. More importantly, it allows you to combine
  these operations and connect applications to each other to perform complex and
  automated tasks.
</p>
<p>
  Bash is not your operating system. It is not your window manager. It is not
  your terminal (but it often runs inside your terminal). It does not control
  your mouse or keyboard. It does not configure your system, activate your
  screen-saver, or open your files. It’s important to understand that bash is
  only an interface for you to execute statements (using bash syntax), either at
  the interactive bash prompt or via bash scripts. The things that
  <em>actually happen</em> are usually caused by other programs.
</p>
<p>
  This guide is based on
  <a href="http://mywiki.wooledge.org/BashGuide"
    >the bash guide in GreyCat’s wiki</a
  >
  and aims to be more concise, while still being accurate. It was produced
  specifically for the Bash Workshop by
  <a href="www.thealternative.ch">TheAlternative.ch</a>.
</p>
<p>
  It is published under the
  <a href="http://creativecommons.org/licenses/by-nc-sa/4.0/"
    >CC by-nc-sa 4.0 license</a
  >.
</p>
<h1 data-number="2" id="commands-and-arguments">
  <span class="header-section-number">2</span> Commands and Arguments
</h1>
<p>
  Bash reads commands from its input, which can be either a file or your
  terminal. In general, each line is interpreted as a command followed by its
  arguments.
</p>
<pre><code>ls
touch file1 file2 file3
ls -l
rm file1 file2 file3</code></pre>
<p>
  The first word is always the command that is executed. All subsequent words
  are given to that command as argument.
</p>
<p>
  Note that <em>options</em>, such as the <code>-l</code> option in the example
  above, are not treated specially by bash. They are arguments like any other.
  It is up to the program (<code>ls</code> in the above case) to treat it as an
  option.
</p>
<p>
  Words are delimited by whitespace (spaces or tabs). It does not matter how
  many spaces there are between two words. For example, try
</p>
<pre><code>echo Hello            World</code></pre>
<p>
  The process of splitting a line of text into words is called
  <em>word splitting</em>. It is vital to be aware of it, especially when you
  come across expansions later on.
</p>
<h2 data-number="2.1" id="preventing-word-splitting">
  <span class="header-section-number">2.1</span> Preventing Word Splitting
</h2>
<p>
  Sometimes, you will want to pass arguments to commands that contain
  whitespace. To do so, you can use quotes:
</p>
<pre><code>touch &quot;Filename with spaces&quot;</code></pre>
<p>
  This command creates a single file named <em>Filename with spaces</em>. The
  text within double quotes is protected from word splitting and hence treated
  as a single word.
</p>
<p>Note that you can also use single quotes:</p>
<pre><code>touch &#39;Another filename with spaces&#39;</code></pre>
<p>There is, however, an important difference between the two:</p>
<ul>
  <li>Double quotes prevent <strong>word splitting</strong></li>
  <li>Single quotes prevent <strong>word splitting and expansion</strong></li>
</ul>
<p>
  When you use single quotes, the quoted text will never be changed by bash.
  With double quotes, expansion will still happen. This doesn’t make a
  difference in the above example, but as soon as you e.g. use variables, it
  becomes important.
</p>
<p>
  In general, it is considered good practice to use single quotes whenever
  possible, and double quotes only when expansion is desired. In that sense, the
  last example above can be considered “more correct”.
</p>
<h2 data-number="2.2" id="the-importance-of-spaces">
  <span class="header-section-number">2.2</span> The Importance of Spaces
</h2>
<p>
  Bash contains various keywords and built-ins that aren’t immediately
  recognizable as commands, such as the new test command:
</p>
<pre><code>[[ -f file ]]</code></pre>
<p>
  The above code tests whether a file named “file” exists in the current
  directory. Just like every line of bash code, it consists of a command
  followed by its arguments. Here, the command is <code>[[</code>, while the
  arguments are <code>-f</code>, <code>file</code> and <code>]]</code>.
</p>
<p>
  Many programmers of other languages would write the above command like so:
</p>
<pre><code>[[-f file]]</code></pre>
<p>
  This, though, is wrong: Bash will look for a command named <code>[[-f</code>,
  which doesn’t exist, and issue an error message. This kind of mistake is very
  common for beginners. It is advisable to always use spaces after any kind of
  brackets in bash, even though there are cases where they are not necessary.
</p>
<h2 data-number="2.3" id="scripts">
  <span class="header-section-number">2.3</span> Scripts
</h2>
<p>
  You have probably interacted with bash through a terminal before. You would
  see a bash prompt, and you would issue one command after another.
</p>
<p>
  Bash scripts are basically a sequence of commands stored in a file. They are
  read and processed in order, one after the other.
</p>
<p>
  Making a script is easy. Begin by making a new file, and put this on the first
  line:
</p>
<pre><code>#!/bin/bash</code></pre>
<p>
  This line is called an <em>interpreter directive</em>, or more commonly, a
  <em>hashbang</em> or <em>shebang</em>. Your operating system uses it to
  determine how this file can be run. In this case, the file is to be run using
  <code>bash</code>, which is stored in the <code>/bin/</code> directory.
</p>
<p>
  After the shebang, you can add any command that you could also use in your
  terminal. For example, you could add
</p>
<pre><code>echo &#39;Hello World&#39;</code></pre>
<p>and then save the file as “myscript”</p>
<p>You can now run the file from the terminal by typing</p>
<pre><code>bash myscript</code></pre>
<p>
  Here, you explicitly called bash and made it execute the script.
  <code>bash</code> is used as the command, while <code>myscript</code> is an
  argument. However, it’s also possible to use <code>myscript</code> as a
  command directly.
</p>
<p>To do so, you must first make it executable:</p>
<pre><code>chmod +x myscript</code></pre>
<p>
  Now that you have permission to execute this script directly, you can type
</p>
<pre><code>./myscript</code></pre>
<p>to run it.</p>
<p>
  The <code>./</code> is required to tell bash that the executable is located in
  the current directory, rather than the system directory. We will come back to
  this in the chapter on Variables.
</p>
<h1 data-number="3" id="variables-and-parameters">
  <span class="header-section-number">3</span> Variables and Parameters
</h1>
<p>
  Variables and parameters can be used to store strings and retrieve them later.
  <em>Variables</em> are the ones you create yourself, while
  <em>special parameters</em> are pre-set by bash. <em>Parameters</em> actually
  refers to both, but is often used synonymously to special parameters.
</p>
<p>To store a string in a variable, we use the <em>assignment syntax</em>:</p>
<pre><code>varname=vardata</code></pre>
<p>
  This sets the variable <code>varname</code> to contain the string
  <code>vardata</code>.
</p>
<p>
  Note that you cannot use spaces around the <code>=</code> sign. With the