Fix dead internal links

blog/content/extra/handling-exceptions-with-naked-fns/01-catching-exceptions/index.md

@@ -15,7 +15,10 @@ As always, the complete source code is on [Github]. Please file [issues] for any
 [Github]: https://github.com/phil-opp/blog_os/tree/catching_exceptions
 [issues]: https://github.com/phil-opp/blog_os/issues
 
-> **Note**: This post describes how to handle exceptions using naked functions (see <a href="/handling-exceptions-with-naked-fns.html">“Handling Exceptions with Naked Functions”</a> for an overview). Our new way of handling exceptions can be found in the <a href="/handling-exceptions.html">“Handling Exceptions”</a> post.
+> **Note**: This post describes how to handle exceptions using naked functions (see [“Handling Exceptions with Naked Functions”] for an overview). Our new way of handling exceptions can be found in the [“Handling Exceptions”] post.
+
+[“Handling Exceptions with Naked Functions”]: ./extra/handling-exceptions-with-naked-fns/_index.md
+[“Handling Exceptions”]: ./posts/09-handling-exceptions/index.md
 
 ## Exceptions
 An exception signals that something is wrong with the current instruction. For example, the CPU issues an exception if the current instruction tries to divide by 0. When an exception occurs, the CPU interrupts its current work and immediately calls a specific exception handler function, depending on the exception type.

blog/content/extra/handling-exceptions-with-naked-fns/02-better-exception-messages/index.md

@@ -10,14 +10,16 @@ In this post, we explore exceptions in more detail. Our goal is to print additio
 
 <!-- more --><aside id="toc"></aside>
 
-As always, the complete source code is on [Github]. Please file [issues] for any problems, questions, or improvement suggestions. There is also a [gitter chat] and a [comment section] at the end of this page.
+As always, the complete source code is on [Github]. Please file [issues] for any problems, questions, or improvement suggestions. There is also a [gitter chat] and a comment section at the end of this page.
 
 [Github]: https://github.com/phil-opp/blog_os/tree/better_exception_messages
 [issues]: https://github.com/phil-opp/blog_os/issues
 [gitter chat]: https://gitter.im/phil-opp/blog_os
-[comment section]: #disqus_thread
 
-> **Note**: This post describes how to handle exceptions using naked functions (see <a href="/handling-exceptions-with-naked-fns.html">“Handling Exceptions with Naked Functions”</a> for an overview). Our new way of handling exceptions can be found in the <a href="/handling-exceptions.html">“Handling Exceptions”</a> post.
+> **Note**: This post describes how to handle exceptions using naked functions (see [“Handling Exceptions with Naked Functions”] for an overview). Our new way of handling exceptions can be found in the [“Handling Exceptions”] post.
+
+[“Handling Exceptions with Naked Functions”]: ./extra/handling-exceptions-with-naked-fns/_index.md
+[“Handling Exceptions”]: ./posts/09-handling-exceptions/index.md
 
 ## Exceptions in Detail
 An exception signals that something is wrong with the currently-executed instruction. Whenever an exception occurs, the CPU interrupts its current work and starts an internal exception routine.

blog/content/extra/handling-exceptions-with-naked-fns/03-returning-from-exceptions/index.md

@@ -10,14 +10,16 @@ In this post, we learn how to return from exceptions correctly. In the course of
 
 <!-- more --><aside id="toc"></aside>
 
-As always, the complete source code is on [Github]. Please file [issues] for any problems, questions, or improvement suggestions. There is also a [gitter chat] and a [comment section] at the end of this page.
+As always, the complete source code is on [Github]. Please file [issues] for any problems, questions, or improvement suggestions. There is also a [gitter chat] and a comment section at the end of this page.
 
 [Github]: https://github.com/phil-opp/blog_os/tree/returning_from_exceptions
 [issues]: https://github.com/phil-opp/blog_os/issues
 [gitter chat]: https://gitter.im/phil-opp/blog_os
-[comment section]: #disqus_thread
 
-> **Note**: This post describes how to handle exceptions using naked functions (see <a href="/handling-exceptions-with-naked-fns.html">“Handling Exceptions with Naked Functions”</a> for an overview). Our new way of handling exceptions can be found in the <a href="/handling-exceptions.html">“Handling Exceptions”</a> post.
+> **Note**: This post describes how to handle exceptions using naked functions (see [“Handling Exceptions with Naked Functions”] for an overview). Our new way of handling exceptions can be found in the [“Handling Exceptions”] post.
+
+[“Handling Exceptions with Naked Functions”]: ./extra/handling-exceptions-with-naked-fns/_index.md
+[“Handling Exceptions”]: ./posts/09-handling-exceptions/index.md
 
 ## Introduction
 Most exceptions are fatal and can't be resolved. For example, we can't return from a divide-by-zero exception in a reasonable way. However, there are some exceptions that we can resolve:

blog/content/posts/02-entering-longmode/index.md

@@ -494,7 +494,7 @@ _Congratulations_! You have successfully wrestled through this CPU configuration
 #### One Last Thing
 Above, we reloaded the code segment register `cs` with the new GDT offset. However, the data segment registers `ss`, `ds`, `es`, `fs`, and `gs` still contain the data segment offsets of the old GDT. This isn't necessarily bad, since they're ignored by almost all instructions in 64-bit mode. However, there are a few instructions that expect a valid data segment descriptor _or the null descriptor_ in those registers. An example is the the [iretq] instruction that we'll need in the [_Returning from Exceptions_] post.
 
-[iretq]: ./extra/handling-exceptions-with-naked-fns/03-returning-from-exceptions/index.md#the-iretq-instruction
+[iretq]: ./extra/handling-exceptions-with-naked-fns/03-returning-from-exceptions/index.md#the
 [_Returning from Exceptions_]: ./extra/handling-exceptions-with-naked-fns/03-returning-from-exceptions/index.md
 
 To avoid future problems, we reload all data segment registers with null:

blog/content/posts/10-double-faults/index.md

@@ -9,12 +9,11 @@ In this post we explore double faults in detail. We also set up an _Interrupt St
 
 <!-- more --><aside id="toc"></aside>
 
-As always, the complete source code is available on [Github]. Please file [issues] for any problems, questions, or improvement suggestions. There is also a [gitter chat] and a [comment section] at the end of this page.
+As always, the complete source code is available on [Github]. Please file [issues] for any problems, questions, or improvement suggestions. There is also a [gitter chat] and a comment section at the end of this page.
 
 [Github]: https://github.com/phil-opp/blog_os/tree/post_10
 [issues]: https://github.com/phil-opp/blog_os/issues
 [gitter chat]: https://gitter.im/phil-opp/blog_os
-[comment section]: #disqus_thread
 
 ## What is a Double Fault?
 In simplified terms, a double fault is a special exception that occurs when the CPU fails to invoke an exception handler. For example, it occurs when a page fault is triggered but there is no page fault handler registered in the [Interrupt Descriptor Table][IDT] (IDT). So it's kind of similar to catch-all blocks in programming languages with exceptions, e.g. `catch(...)` in C++ or `catch(Exception e)` in Java or C#.

blog/templates/base.html

@@ -32,7 +32,7 @@
             <hr>
             <small>
                 &copy; <time datetime="2017">2017</time>. All rights reserved.
-                <a href="/contact.html">Contact</a>
+                <a href="{{ get_url(link="pages/contact.md") }}">Contact</a>
             </small>
         </footer>
     </div>

blog/templates/handling-exceptions-with-naked-fns.html

@@ -6,6 +6,6 @@
 
 {% block introduction %}
 
-    <p>These posts explain how to handle CPU exceptions using naked functions. Historically, these posts were the main exception handling posts before the <code>x86-interrupt</code> calling convention and the <code>x86_64</code> crate existed. Our new way of handling exceptions can be found in the <a href="/handling-exceptions.html">“Handling Exceptions”</a> post.</p>
+    <p>These posts explain how to handle CPU exceptions using naked functions. Historically, these posts were the main exception handling posts before the <code>x86-interrupt</code> calling convention and the <code>x86_64</code> crate existed. Our new way of handling exceptions can be found in the <a href="{{ get_url(link="posts/09-handling-exceptions/index.md") }}">“Handling Exceptions”</a> post.</p>
 
 {% endblock introduction %}