Fixing references to HTML pages (swcarpentry#145)

ra2003 · Nov 27, 2016 · 48d506d · 48d506d
1 parent faafd9a
commit 48d506d
Show file tree

Hide file tree

Showing 8 changed files with 24 additions and 24 deletions.
diff --git a/_episodes/01-select.md b/_episodes/01-select.md
@@ -15,18 +15,18 @@ keypoints:
 - "Use SELECT... FROM... to get values from a database table."
 - "SQL is case-insensitive (but data is case-sensitive)."
 ---
-A [relational database](reference.html#relational-database)
+A [relational database]({{ site.github.url }}/reference/#relational-database)
 is a way to store and manipulate information.
-Databases are arranged as [tables](reference.html#table).
-Each table has columns (also known as [fields](reference.html#field)) that describe the data,
-and rows (also known as [records](reference.html#record)) which contain the data.
+Databases are arranged as [tables]({{ site.github.url }}/reference/#table).
+Each table has columns (also known as [fields]({{ site.github.url }}/reference/#field)) that describe the data,
+and rows (also known as [records]({{ site.github.url }}/reference/#record)) which contain the data.
 
 When we are using a spreadsheet,
 we put formulas into cells to calculate new values based on old ones.
 When we are using a database,
 we send commands
-(usually called [queries](reference.html#query))
-to a [database manager](reference.html#database-manager):
+(usually called [queries]({{ site.github.url }}/reference/#query))
+to a [database manager]({{ site.github.url }}/reference/#database-manager):
 a program that manipulates the database for us.
 The database manager does whatever lookups and calculations the query specifies,
 returning the results in a tabular form
@@ -43,7 +43,7 @@ that we can then use as a starting point for further queries.
 > so it *is* possible to move information from one to another.
 {: .callout}
 
-Queries are written in a language called [SQL](reference.html#sql),
+Queries are written in a language called [SQL]({{ site.github.url }}/reference/#sql),
 which stands for "Structured Query Language".
 SQL provides hundreds of different ways to analyze and recombine data.
 We will only look at a handful of queries,
@@ -142,7 +142,7 @@ The tables below show the database we will use in our examples:
 Notice that three entries --- one in the `Visited` table,
 and two in the `Survey` table --- don't contain any actual
 data, but instead have a special `-null-` entry:
-we'll return to these missing values [later](05-null.html).
+we'll return to these missing values [later]({{ site.github.url }}/05-null/).
 
 
 > ## Checking If Data is Available
@@ -230,7 +230,7 @@ We have written our commands in upper case and the names for the table and colum
 in lower case,
 but we don't have to:
 as the example below shows,
-SQL is [case insensitive](reference.html#case-insensitive).
+SQL is [case insensitive]({{ site.github.url }}/reference/#case-insensitive).
 
 ~~~
 SeLeCt FaMiLy, PeRsOnAl FrOm PeRsOn;

diff --git a/_episodes/03-filter.md b/_episodes/03-filter.md
@@ -14,7 +14,7 @@ keypoints:
 - "Write queries incrementally."
 ---
 One of the most powerful features of a database is
-the ability to [filter](reference.html#filter) data,
+the ability to [filter]({{ site.github.url }}/reference/#filter) data,
 i.e.,
 to select only those records that match certain criteria.
 For example,
@@ -176,7 +176,7 @@ SELECT * FROM Survey WHERE quant='sal' AND (person='lake' OR person='roe');
 We can also filter by partial matches.  For example, if we want to
 know something just about the site names beginning with "DR" we can
 use the `LIKE` keyword.  The percent symbol acts as a
-[wildcard](reference.html#wildcard), matching any characters in that
+[wildcard]({{ site.github.url }}/reference/#wildcard), matching any characters in that
 place.  It can be used at the beginning, middle, or end of the string:
 
 ~~~

diff --git a/_episodes/05-null.md b/_episodes/05-null.md
@@ -188,7 +188,7 @@ that combine multiple values, such as `min`, `max` or `avg`, *ignore*
 `null` values. In the majority of cases, this is a desirable output:
 for example, unknown values are thus not affecting our data when we
 are averaging it. Aggregation functions will be addressed in more
-detail in [the next section](06-agg.html).
+detail in [the next section]({{ site.github.url }}/06-agg/).
 
 > ## Sorting by Known Date
 >
@@ -213,7 +213,7 @@ detail in [the next section](06-agg.html).
 > ## Pros and Cons of Sentinels
 >
 > Some database designers prefer to use
-> a [sentinel value](reference.html#sentinel-value)
+> a [sentinel value]({{ site.github.url }}/reference/#sentinel-value)
 > to mark missing data rather than `null`.
 > For example,
 > they will use the date "0000-00-00" to mark a missing date,

diff --git a/_episodes/06-agg.md b/_episodes/06-agg.md
@@ -36,7 +36,7 @@ SELECT dated FROM Visited;
 |1932-03-22|
 
 but to combine them,
-we must use an [aggregation function](reference.html#aggregation-function)
+we must use an [aggregation function]({{ site.github.url }}/reference/#aggregation-function)
 such as `min` or `max`.
 Each of these functions takes a set of records as input,
 and produces a single record as output:

diff --git a/_episodes/07-join.md b/_episodes/07-join.md
@@ -70,7 +70,7 @@ SELECT * FROM Site JOIN Visited;
 |MSK-4|-48.87|-123.4 |844  |DR-1  |1932-03-22|
 
 `JOIN` creates
-the [cross product](reference.html#cross-product)
+the [cross product]({{ site.github.url }}/reference/#cross-product)
 of two tables,
 i.e.,
 it joins each record of one table with each record of the other table
@@ -185,8 +185,8 @@ AND    Visited.dated IS NOT NULL;
 We can tell which records from `Site`, `Visited`, and `Survey`
 correspond with each other
 because those tables contain
-[primary keys](reference.html#primary-key)
-and [foreign keys](reference.html#foreign-key).
+[primary keys]({{ site.github.url }}/reference/#primary-key)
+and [foreign keys]({{ site.github.url }}/reference/#foreign-key).
 A primary key is a value,
 or combination of values,
 that uniquely identifies each record in a table.

diff --git a/_episodes/08-hygiene.md b/_episodes/08-hygiene.md
@@ -21,7 +21,7 @@ keypoints:
 
 Now that we have seen how joins work, we can see why the relational
 model is so useful and how best to use it.  The first rule is that
-every value should be [atomic](reference.html#atomic), i.e., not
+every value should be [atomic]({{ site.github.url }}/reference/#atomic), i.e., not
 contain parts that we might want to work with separately.  We store
 personal and family names in separate columns instead of putting the
 entire name in one column so that we don't have to use substring

diff --git a/_episodes/09-create.md b/_episodes/09-create.md
@@ -150,14 +150,14 @@ but that's never supposed to happen:
 and all our queries assume there will be a row in the latter
 matching every value in the former.
 
-This problem is called [referential integrity](reference.html#referential-integrity):
+This problem is called [referential integrity]({{ site.github.url }}/reference/#referential-integrity):
 we need to ensure that all references between tables can always be resolved correctly.
 One way to do this is to delete all the records
 that use `'lake'` as a foreign key
 before deleting the record that uses it as a primary key.
 If our database manager supports it,
 we can automate this
-using [cascading delete](reference.html#cascading-delete).
+using [cascading delete]({{ site.github.url }}/reference/#cascading-delete).
 However,
 this technique is outside the scope of this chapter.
 
@@ -184,7 +184,7 @@ this technique is outside the scope of this chapter.
 
 > ## Generating Insert Statements
 >
-> One of our colleagues has sent us a [CSV](reference.html#comma-separated-values) file containing
+> One of our colleagues has sent us a [CSV]({{ site.github.url }}/reference/#comma-separated-values) file containing
 > temperature readings by Robert Olmstead, which is formatted like
 > this:
 >

diff --git a/_episodes/10-prog.md b/_episodes/10-prog.md
@@ -56,7 +56,7 @@ Line 2 establishes a connection to the database.
 Since we're using SQLite,
 all we need to specify is the name of the database file.
 Other systems may require us to provide a username and password as well.
-Line 3 then uses this connection to create a [cursor](reference.html#cursor).
+Line 3 then uses this connection to create a [cursor]({{ site.github.url }}/reference/#cursor).
 Just like the cursor in an editor,
 its role is to keep track of where we are in the database.
 
@@ -134,7 +134,7 @@ SELECT personal || ' ' || family FROM Person WHERE id='dyer'; DROP TABLE Survey;
 If we execute this,
 it will erase one of the tables in our database.
 
-This is called an [SQL injection attack](reference.html#sql-injection-attack),
+This is called an [SQL injection attack]({{ site.github.url }}/reference/#sql-injection-attack),
 and it has been used to attack thousands of programs over the years.
 In particular,
 many web sites that take data from users insert values directly into queries
@@ -144,7 +144,7 @@ Since a villain might try to smuggle commands into our queries in many different
 the safest way to deal with this threat is
 to replace characters like quotes with their escaped equivalents,
 so that we can safely put whatever the user gives us inside a string.
-We can do this by using a [prepared statement](reference.html#prepared-statement)
+We can do this by using a [prepared statement]({{ site.github.url }}/reference/#prepared-statement)
 instead of formatting our statements as strings.
 Here's what our example program looks like if we do this: