From ff9eb09838016f0ac677d2f9c2b87cde5673bda8 Mon Sep 17 00:00:00 2001 From: Lee Cattarin Date: Tue, 24 Mar 2026 10:10:57 -0700 Subject: [PATCH] update headers to use code blocks again now that i fixed that --- src/posts/2025/2025-05-14-azure-locations.md | 22 +++++----- src/posts/2026/2026-01-05-moving-images.md | 10 ++--- src/posts/2026/2026-01-07-intro-to-git.md | 44 ++++++++++---------- 3 files changed, 38 insertions(+), 38 deletions(-) diff --git a/src/posts/2025/2025-05-14-azure-locations.md b/src/posts/2025/2025-05-14-azure-locations.md index d10e0ce7..50266c50 100644 --- a/src/posts/2025/2025-05-14-azure-locations.md +++ b/src/posts/2025/2025-05-14-azure-locations.md @@ -2,7 +2,7 @@ title: azure locations and file crawling image: src: 2025/azure-locations.jpg - alt: "A Linux terminal. There is a fun rainbow flag in ascii art at the top, and then the user has called a command asking Azure for a list of resources applicable to a specific resource type" + alt: "A Linux terminal. There is a fun rainbow flag in ascii art at the top, and then the user has called a command asking Azure for a list of locations applicable to a specific resource type. The output is lengthy." tags: - reference - software @@ -75,7 +75,7 @@ Okay, let's backtrack. From a given Bicep file, we want: 1. All referenced resource types 1. All referenced modules -### grep +### `grep` Resources and modules both have patterns in how they are declared. Thankfully, they're pretty simple regexes. `grep` will spit out lines in a file that match a given regex. @@ -89,7 +89,7 @@ grep -E "^resource " "$file" grep -E "^module " "$file" ``` -### cut +### `cut` From there, let's use `cut` to strip off the parts we don't want. @@ -108,7 +108,7 @@ grep -E "^module " "$file" \ These calls are a little opaque. `-d` sets a **delimiter** (what to split on). `-f` picks a **field** to return, numbered from 1. -### mapfile +### `mapfile` We'll save these values to variables. `mapfile` reads a file, putting each line into a new array element. `-t` **trims** newline characters. The `<`s do some redirection, and yes, the space between them *matters*. @@ -120,7 +120,7 @@ mapfile -t modules < <(grep -E "^module " "$file" \ | cut -d "'" -f 2 -) ``` -### dirname (& more) +### `dirname` (& more) We can't just stop there. We need to search each module in turn. Using `dirname`, we can get the directory of the file we're searching, then append the relative module path. @@ -143,7 +143,7 @@ Additionally, `mapfile` usually writes from index 0 onwards. But with the `-O` a Finally, we got some recursion going! `get_resources` calls `get_resources` for every module found. -### the get_resources function +### the `get_resources` function So far, our code looks like this: @@ -176,7 +176,7 @@ Now we need to use these resource types to get available locations. First, actua mapfile -t resources < <(get_resources "main.bicep") ``` -### sort +### `sort` Does sorting matter? Not really, but `sort` has a useful feature, `-u`, which returns **u**nique items (aka, it deduplicates). Looking up the same resource type twice slows us down. @@ -186,7 +186,7 @@ mapfile -t resources < <(get_resources "main.bicep" | sort -u) `sort` is one reason it helps to have newlines as delimiters - it expects that. -### az +### `az` We'll use `az` to list *all* the locations - just to give ourselves a starting point. You could also use the locations for the first resource type. @@ -205,7 +205,7 @@ mapfile -t newLocations < <(az provider show --namespace "$namespace" \ `--out tsv` means we will get a list with no decoration whatsoever - it's vital for programmatic handling of `az` command output. -### cut (again) +### `cut` (again) We'll need to get those `$namespace` and `$resourceType` variables. `cut` comes back in handy: @@ -221,7 +221,7 @@ namespace=$(echo "$resource" | cut -d "/" -f 1 -) resourceType=$(echo "$resource" | cut -d "/" -f 2 -) ``` -### comm +### `comm` Okay, we can get locations. How do we handle finding their intersection? @@ -248,7 +248,7 @@ then fi ``` -### tee +### `tee` We'll print the locations to the shell. We can even use `tee` to print them to a file for good measure: diff --git a/src/posts/2026/2026-01-05-moving-images.md b/src/posts/2026/2026-01-05-moving-images.md index 11300280..52c451c1 100644 --- a/src/posts/2026/2026-01-05-moving-images.md +++ b/src/posts/2026/2026-01-05-moving-images.md @@ -16,7 +16,7 @@ so it's time to move them into year-based folders. Let's talk about how I did th (want to [skip right to the completed script?](#result)) -## find +## `find` let's start with the basics: a list of posts. `find` gets us everything under a specific directory - in this case, the `_posts` directory. We can filter out the directories a few different ways, but I piped the `find` output through a basic `grep` looking for `.md` in the filename. @@ -27,7 +27,7 @@ do done ``` -## grep +## `grep` `grep` can also help us get image names with the regex `"name:.+jpg|png"`. I add `name:` to the regex because there are *very occasionally* images that aren't the featured image for the post, and those don't fit the pattern of `name: `. Since there's so few of those, I ended up handling them manually. @@ -40,7 +40,7 @@ to make `grep` work with regex, it needs the `-E` flag. IMAGE_LINE=$(cat $FILE | grep -E "name:.+jpg|png$") ``` -## cut +## `cut` that output gets us the full line of text that includes the image filename. Let's trim out what we actually want. @@ -62,7 +62,7 @@ with `cut`, we can also get the year of the post: YEAR=$(echo $FILE | cut -d '/' -f 2 -) ``` -## sed +## `sed` there's two major things we need to do with the information we've gathered: @@ -77,7 +77,7 @@ by default, `sed` prints to standard output, so we'll tell it to edit in-place i sed "s,$IMAGE,$YEAR/&," -i $FILE ``` -## mving and shaking +## `mv`ing and shaking (my mom thinks I'm funny.) diff --git a/src/posts/2026/2026-01-07-intro-to-git.md b/src/posts/2026/2026-01-07-intro-to-git.md index da6e74d5..a019a32a 100644 --- a/src/posts/2026/2026-01-07-intro-to-git.md +++ b/src/posts/2026/2026-01-07-intro-to-git.md @@ -18,12 +18,12 @@ alrighty, this one's a real doozy. Strap in. - [problem statement](#problem-statement) - [what is git?](#what-is-git) - [where can I use git?](#where-can-i-use-git) - - [what is a CLI?](#what-is-a-cli) + - [what is a CLI?](#what-is-a-cli) - [where can I use the git CLI?](#where-can-i-use-the-git-cli) - - [git for Windows](#git-for-windows) - - [WSL](#wsl) + - [git for Windows](#git-for-windows) + - [WSL](#wsl) - [a few terminal operations](#a-few-terminal-operations) - - [edit files](#edit-files) + - [edit files](#edit-files) - [git version](#git-version) - [a few handy settings](#a-few-handy-settings) - [git going](#git-going) @@ -81,13 +81,13 @@ finally, I wrote this walkthrough primarily with knowledge from using **WSL** [m that all said, let's get (git?) into it! -## what is git? +## what is `git`? `git` is a *version control system*. We can use it to track changes we make to a set of files. > tip: it's important to understand that despite the examples of MS Office and Google Docs above, `git` *isn't useful* with word documents. `git` shines with plain text files - .txt, .md, or basically any type of code. -### where can I use git? +### where can I use `git`? many, many tools interact with `git`: @@ -101,7 +101,7 @@ today we're going to talk about the `git` CLI... technically. But **don't let th a CLI a way to interact with your computer and with software in text-only form. Rather than using the mouse and clicking on things, you type in commands and see output. -### where can I use the git CLI? +### where can I use the `git` CLI? if you want to use the `git` CLI, you'll need a terminal. You've got a couple options here: @@ -112,7 +112,7 @@ if you want to use the `git` CLI, you'll need a terminal. You've got a couple op - I use [Windows Subsystem for Linux, or WSL](https://learn.microsoft.com/en-us/windows/wsl/install){target="_blank" rel="external"}, which gives you a Linux distribution within Windows. It's pretty smooth sailing at this point, but there's some idiosyncracies to conquer - like the fact that your *Windows* files and your *Linux* files are stored in different places. If choosing WSL, [see my usage notes below](#wsl) - both of the Windows options listed work with [Windows Terminal](https://apps.microsoft.com/detail/9n0dx20hk701){target="_blank" rel="external"} which offers a nicer-looking terminal experience than the basic command prompt. If you're going to keep working with what you set up today, I recommend it! -#### git for Windows +#### `git` for Windows on the "Releases" page, scroll down to "Assets" and pick the `.exe` file. @@ -161,7 +161,7 @@ we'll want to edit files, right? How do we open our editor from the terminal? there's usually a terminal command for the editor. For VSCode, it's `code`; for Zed, it's `zed`. If we want to open the *current directory* in our editor of choice (and we do!), we'll write ` .` (note the `.`), where `.` means "the current directory." -## git version +## `git version` let's check that you have git installed with `git version`. You might see something like `git version 2.34.1` printed out in response. If you don't get a version number, but instead get an error saying you don't have `git`, [install `git`](https://git-scm.com/install){target="_blank" rel="external"}. @@ -196,9 +196,9 @@ git config --global user.name git config --global user.email ``` -## git going +## `git` going -(no, that's not a real `git` command) +(no, that's not a real `git` command.) there's two main ways to start: @@ -207,17 +207,17 @@ there's two main ways to start: > tip: `git` and associated tooling refer to projects as **repositories**. I'll be sticking with the word project here as I find it a bit friendlier, but you'll probably run across the word repository in the wider world of `git` -### git init +### `git init` `git init ` will create a new directory named `project` ready to be used with git. We can then use `cd ` to enter the directory. > tip: don't use spaces in your project name! -### git clone +### `git clone` `git clone ` will pull in an existing project. We're not going to talk about this right now; instead, we're going forward assuming with `git init`. -## git status +## `git status` before we do anything, let's see what `git` will tell us about our project. Type `git status` and we might see the following: @@ -243,7 +243,7 @@ let's dissect this. a **commit** is one set of changes made to our work. We get to choose which changes are part of any given commit, and we write a message describing the commit so that future-us knows what we did if for some reason we need to undo something. -### git log +### `git log` in an established project, we can use `git log` to look at our **commit history**. By default, one commit will output like this: @@ -304,7 +304,7 @@ Changes to be committed: *now* we're ready to create a commit! -## git commit +## `git commit` if we just write `git commit`, it'll open an editor for us to edit the **commit message** - our description of the changes. This can be handy if we want to write a lengthy description, but if we want to just write a one-liner, we can use `git commit -m ""`. It's quicker and doesn't involve opening an editor. @@ -351,7 +351,7 @@ Changes not staged for commit: modified: file.txt ``` -### git restore +### `git restore` `git restore` is new! That lets us get rid of our changes and go back to the last version of the file committed. Be careful with this - we should only do it if we *really* want to get rid of those changes. @@ -364,7 +364,7 @@ git commit -m "added a new sentence" again, we can use `git status` or `git log` as needed. -## git revert +## `git revert` ooooh... I don't actually like that change. What if I want to undo something? @@ -389,7 +389,7 @@ now we can try `git revert `. It'll open our editor to write a me I didn't edit the message - we can tell because it just says "Revert" and then the old commit message. But we can edit and add lots of detail about why we're doing it. -## git remote +## `git remote` let's try a new command: `git remote`. Hmm, nothing happened... what's a "remote"? @@ -426,7 +426,7 @@ codeberg https://codeberg.org/inherentlee/git-intro.git (push) cool! we have a remote set up. What does "fetch" and "push" mean? -### git fetch (and git pull) +### `git fetch` (and `git pull`) `git fetch` brings **remote** changes to our local machine. So does a command called `git pull`. Why are there two? @@ -438,7 +438,7 @@ if we're working alone and *from one machine*, we'll pretty much never have to u for our use case, we can pretty safely stick to `git pull` (if we ever even need to use it!), but if you're working in a larger collaborative project, `git fetch` is your friend! -### git push, take one +### `git push`, take one `git push` is the opposite of `git pull` - it takes your local changes and adds them to the remote. @@ -533,7 +533,7 @@ we'll notice that the SSH URL starts with `git@`, whereas the HTTPS URL started in order for all this to be useful, we need to tell Codeberg about our SSH key. In Codeberg, navigate to [settings, then find the left-hand tab for SSH keys](https://codeberg.org/user/settings/keys){target="_blank" rel="external"}. Choose 'Add key' and paste in the **public** key (if you set up that `sshcat` alias, use it now to output your key for ease of copying). Save and we'll now be set up to authenticate with SSH! -### git push, take two +### `git push`, take two we can now call `git push` again and again now without having to repeat our credentials every time. We can also call `git pull` for our private repositories.