Navigation

Look, I get it. You live in cd and ls. You’ve got your ls -la muscle memory so deeply ingrained you do it in your sleep. But sometimes, you need to actually get something done. You need to find a file buried in a labyrinth of directories, rename a batch of photos, or just see what’s chewing up all your disk space. For that, you need a proper file manager. Not the clunky GUI thing that came with your desktop environment, but a terminal-based one that respects your need for speed and doesn’t make you reach for the mouse.

Right, let’s talk about tree. If ls is a quick glance at your desk, tree is the full, organized blueprint of your entire office. It’s one of those utilities that seems almost frivolous until you use it once, and then you wonder how you ever lived without it. It recursively lists the contents of directories, displaying them in a, well, tree-like structure. It’s the fastest way to get the lay of the land in an unfamiliar project directory or to visualize the sprawling monstrosity you’ve created in your ~/Downloads folder.

Right, let’s talk about making your shell do the heavy lifting. You’re not going to type out every single filename one by one, are you? Of course not. You’re smarter than that, and the shell is too. This is where “globbing” comes in—the process of using wildcard patterns to match filenames. It’s called globbing because of the original glob() function that handled it, and it’s one of those wonderfully simple yet powerful concepts that, once you master it, you’ll wonder how you ever lived without it.

Right, let’s settle this. The single biggest source of confusion and broken scripts when you’re starting out isn’t some complex algorithm—it’s simply not knowing where you are and how to tell the computer where you want to be. It all boils down to two ways of giving directions: absolute and relative. Think of it like giving someone your address. You could say, “It’s the big red house on 123 Main Street, Anytown, USA.” That works no matter where in the world you’re starting from. That’s an absolute path. It begins with a forward slash /, the root of the entire filesystem, and lists every single directory down to the target.

Right, let’s talk about cd. It’s the command you’ll use more than any other, the digital equivalent of putting one foot in front of the other. The concept is laughably simple: you tell your shell where you want to go, and it takes you there. The implementation, however, has a few quirks that have tripped up everyone from absolute beginners to grizzled veterans who just weren’t paying attention. Let’s demystify it.

Right, let’s talk about ls. It’s the first command most of us learn, and consequently, the one we use wrong for the longest time. Typing ls by itself is like glancing into a room with the lights off. You get the vague shapes. But we’re not here for vague shapes. We’re here to see everything. Let’s turn on the lights. The default ls output is… fine. It’s a quick, alphabetical list. But the moment you need to know anything else—like who owns a file, how big it is, or when it was last modified—you’re left squinting. That’s where our flags come in. They’re not just options; they’re the difference between a glance and true sight.

Right, let’s start with the most brutally honest command in your arsenal: pwd. It stands for “print working directory,” and it does exactly one thing. It’s the command-line equivalent of you stopping in the middle of a hike, looking down at your boots, and declaring, “Yep, I am here.” It’s not glamorous, but my god, is it fundamental. You will use this more than you’ll use your backspace key, especially when you’re lost, which is a permanent state of being for anyone who’s actually getting stuff done.

Right, let’s talk about menus. Not the laminated kind you get at a diner, but the ones that hold your entire website together. You’ve got your main nav, your footer, and that sneaky sidebar. They’re not just different places to put links; they serve fundamentally different purposes for your users. Getting this wrong is like putting the silverware drawer in the bathroom—sure, it’s in the house, but good luck finding it when you need it.

Right, let’s talk about making sure your user isn’t lost. The single most important job of a navigation menu is to answer the silent, desperate question every user has: “Where the hell am I?” Active state highlighting is how you answer that question. It’s the digital equivalent of a “You Are Here” star on a mall map, and if you screw it up, your user is going to the food court out of sheer frustration, never to return to your website.

Alright, let’s talk about Hugo’s menu system in templates. This is where the rubber meets the road, where your beautifully defined menus in config.toml finally get to show off on the actual website. We’ll be using .Site.Menus—your gateway to all the menu magic. Think of .Site.Menus as a big dictionary (a map, in Go parlance) that Hugo plops into your template. Each key in this map is the name of a menu you defined (like "main" or "footer"), and the value is a slice (an array) of menu entries. Your job is to range over that slice and turn it into HTML. It’s shockingly straightforward once you get the hang of it.

Right, nested menus. This is where we go from “handy navigation” to “full-on application architecture.” Done well, it’s a thing of beauty and usability. Done poorly, and you’ve built a Russian nesting doll of user frustration. My goal is to make sure you’re in the first camp. The core idea is simple: a parent menu entry doesn’t link to a page itself, but instead, when you hover or click it, it reveals a child menu—a sub-list of more specific options. It’s the “just one more level” of web navigation. We use this for a reason: it helps users mentally categorize information without overwhelming them with fifty top-level links. Think of it as the difference between a messy desk and one with a few well-labeled drawers.

Right, let’s talk about the four horsemen of the menu-pocalypse: name, url, weight, identifier, and parent. These are the fields you’ll be slapping onto every menu entry in your config.toml (or yaml, or json—I don’t judge your life choices). They seem simple, but Hugo, in its infinite wisdom, gives them just enough rope to hang yourself with. I’m here to cut you down. Think of a menu entry as a way to tell Hugo: “Hey, for this page (or even for a custom link I’m inventing out of thin air), I want you to put a thing in that navigation bar over there.” These five properties are how you tell Hugo what that thing is, where it goes, what it’s called, and crucially, where it lives in the hierarchy. Get them wrong, and your menu will look like a map drawn by a caffeine-addled squirrel.

Right, let’s talk about getting your pages onto the damn menu. You’ve built a page, you’re proud of it, and now you want people to actually find it. In static site generators, menus aren’t magical, sentient beings that automatically discover your content. You have to explicitly tell the system, “Hey, put this thing here.” The most elegant, keep-it-all-together way to do this is directly in the page’s front matter. Think of front matter as the instruction sheet you paperclip to a document before filing it. It’s the metadata for your page, written in YAML (or TOML, or JSON), sitting right at the top between two sets of triple dashes (---). This is where you declare, “I am a page that belongs in the main navigation,” and you do it by defining a menu property.

Right, let’s talk menus. Not the laminated kind you get at a diner, but the ones that hold your entire application together. This is where we move from building individual pages to building a system that users can actually navigate. Drupal’s menu system is brilliantly powerful, which is a polite way of saying it can be a bit of a labyrinth if you don’t know what you’re doing. We’re going to define them in our module’s .yml files, because that’s how we roll in the land of serious Drupal development.