DEV Community: rbcn

I Built a Pipeline to Publish This Post.

rbcn — Sat, 30 May 2026 18:25:54 +0000

Introduction

I write in Obsidian. I publish on Hashnode. Until recently, moving between the two looked like this:

Open the vault note
Copy the content
Open Hashnode editor
Paste and reformat the frontmatter manually
Hunt for a cover image
Upload it
Hit publish

Somewhere between ten and fifteen minutes of friction between "I'm done writing" and "the post is live."

I got tired of it. So I built a pipeline.

This post documents that pipeline — and it was published through it.

The Problem with Manual Publishing

My Obsidian notes have their own frontmatter schema. Hashnode has its own. They're similar enough to feel like they should be the same thing, and different enough that copy-pasting always broke something.

The tags format was different. The title needed quoting sometimes and not others. The cover image had to be uploaded separately. The ## 📝 Draft section header had to be stripped out.

None of these are hard problems. But they were the kind of small, repetitive friction that makes you skip publishing altogether.

The Architecture

The pipeline has three components:

04_Publish note  (Obsidian vault)
  ↓
/hashnode-publish  (Claude Code skill)
  converts frontmatter, generates slug, writes file
  ↓
post/<timestamp>/slug.md  (GitHub relay repo)
  ↓  git push → GitHub Actions
  ├─ Resolve Unsplash cover image
  └─ Hashnode API  →  live post

Each component has a single responsibility. The vault stays clean. The publishing logic lives outside it.

Component 1: The GitHub Relay Repo

The first piece is a GitHub repository whose only job is to receive markdown files and forward them to Hashnode.

The GitHub Actions workflow triggers on any push that touches post/**/*.md. The nested path pattern matters — post/*.md wouldn't match, so every article goes into a timestamp-named subfolder: post/20260517143000/slug.md. That folder name also serves as a natural ordering key.

When the workflow fires, it runs two steps per changed file:

Resolve Unsplash cover image — more on this below.
Hashnode publish — calls the Hashnode API via raunakgurud09/hashnode-publish@v1.1.

The Hashnode API key lives in GitHub Secrets. It never touches the local machine.

Component 2: The Claude Code Skill

The second piece is a Claude Code slash command: /hashnode-publish.

When invoked, it reads the current vault note, parses its frontmatter, and converts it to Hashnode's format. Then it generates a slug from the filename, creates the timestamp folder, writes the converted file, and pushes to the relay repo.

The frontmatter conversion handles the differences between the vault schema and Hashnode's schema: tag format, field ordering, stripping vault-specific fields, dropping the ## 📝 Draft header from the body. If description is empty, it stops and asks to fill it in first. If publish is false, it warns before proceeding.

From the writer's perspective, the workflow becomes:

1. Write the note in Obsidian
2. Fill in the frontmatter (title, description, tags, etc.)
3. Type /hashnode-publish
4. Done

The entire publishing process — conversion, file creation, commit, push — runs in under ten seconds.

Component 3: Unsplash Cover Images

The third piece solves the cover image problem.

The vault frontmatter accepts a splash_keyword field. When it's set and cover_image is empty, the skill passes the keyword through to the relay repo file. GitHub Actions picks it up, calls the Unsplash API, and injects the result as cover_image before passing the file to Hashnode.

# In the vault note frontmatter
splash_keyword: "developer workspace"
cover_image: ""

GitHub Actions:
  splash_keyword found → GET /photos/random?query=developer+workspace
  → cover_image: https://images.unsplash.com/photo-...
  → splash_keyword removed from frontmatter

The Unsplash API key lives in GitHub Secrets alongside the Hashnode key. Nothing sensitive is stored locally.

One more thing: the Unsplash API terms encourage attribution. So whenever an image is fetched, the workflow appends a line to the article body:

*cover image: [unsplash](https://unsplash.com/)*

The cover image for this post was chosen by that step. I wrote splash_keyword: "developer workspace" and the algorithm did the rest.

The Decision to Use a Relay Repo

A simpler design would call the Hashnode API directly from the Claude Code skill. No relay repo, no GitHub Actions — just a local script with the API key.

I chose the relay repo approach for one reason: the API keys live in GitHub Secrets, not on the local machine.

This matters more than it might seem. A Claude Code skill runs with access to the local environment. Keeping secrets out of that environment, and inside a CI/CD system with audit logs and rotation tooling, is a better default. The relay repo adds one step but removes a category of risk.

There's a secondary benefit: the relay repo is a record. Every published post has a corresponding commit with a timestamp and a slug. That's useful.

What the Frontmatter Looks Like

A complete vault note ready for publishing looks like this:

---
title: "Post Title."
subtitle: "Subtitle here."
tags: ["tag1", "tag2"]
description: "One or two sentences describing the post."
cover_image: ""
splash_keyword: "relevant search term"
publish: true
enableTableOfContent: true
isNewsletterActivated: true
---

Three fields drive the cover image behavior:

`cover_image`	`splash_keyword`	Result
set	—	Use the URL directly
empty	set	Fetch from Unsplash
empty	empty	No cover image

Lessons

The friction between "done writing" and "published" is a publishing problem, not a writing problem.

Optimizing the writing environment — better tools, better structure — doesn't help if the last mile is still manual. The pipeline had to be built separately.

And a pattern that recurred across all three components:

Put secrets where they belong. API keys in GitHub Secrets, not environment variables, not shell configs.

It's the same principle that came up in the SSH agent post: scope matters. A credential should only be reachable from the system that actually needs to use it.

What's Next

The pipeline is functional. A few things I'd add eventually:

Update existing posts: the current workflow only handles new files; updating a published post requires a separate flow
Preview step: see the formatted output before pushing
Japanese articles: the same pipeline works, but slug generation from Japanese filenames needs a romanization step

For now, typing /hashnode-publish and watching the commit appear in the relay repo is satisfying enough.

Migrating to zsh Broke Obsidian Git.

rbcn — Sat, 30 May 2026 17:53:20 +0000

Introduction

In the previous post, I quit .bashrc and gave bash and zsh separate responsibilities. The terminal environment was clean.

The next day, I opened Obsidian and Git sync had stopped.

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

It looked like "switching to zsh broke Obsidian." But the shell wasn't the real culprit.
The ssh-agent's scope simply wasn't reaching GUI applications.

This is the record of how I tracked down that cause and fought my way through the Flatpak sandbox to fix it.

The Structure of the Problem

Checking from the terminal, the SSH keys were visible.

echo "$SSH_AUTH_SOCK"   # /run/user/1000/gcr/ssh
ssh-add -l              # work-github / personal-github

Yet Obsidian Git plugin kept asking for a passphrase every single time.

Terminal (zsh) → OK
Obsidian (GUI) → NG

The problem broke down like this:

ssh-agent launched from a shell
  → only valid within that shell's process tree

Obsidian launched by the GUI
  → never reads .zshrc
  → never reaches the ssh-agent

In other words, this wasn't a shell configuration problem — it was a login session design problem.

Why Did It Work Before?

A question immediately surfaced: when everything was crammed into .bashrc, Obsidian Git worked fine. Why?

The answer turned out to involve GNOME Keyring (gcr).

gcr-ssh-agent integrates with the GNOME login session and automatically exposes SSH keys when the login keyring is unlocked. That meant Obsidian had always been talking to gcr directly, without going through the shell at all.

It wasn't that passphrases were unnecessary — it was that GNOME Keyring had been silently providing the previously-saved passphrase all along.

Attempting gcr-ssh-agent Unification (and Failing)

My first plan was to leverage this mechanism and route everything through gcr.

gcr-ssh-agent
  → /run/user/1000/gcr/ssh
  → shared by Terminal / Editor / Obsidian / Flatpak

I exposed the gcr socket to the Flatpak Obsidian sandbox.

flatpak override --user \
  --filesystem=xdg-run/gcr \
  --env=SSH_AUTH_SOCK=/run/user/1000/gcr/ssh \
  md.obsidian.Obsidian

It worked — temporarily. GitHub authentication went through.

Then I rebooted. The problem came back.

Signing hangs

ssh-add -l              # personal-github / work-github → visible
ssh -T github-personal  # → hangs (no response)

The verbose log showed GitHub was accepting the key.

Offering public key: id_ed25519_personal
Server accepts key: id_ed25519_personal
signing using ssh-ed25519   ← hangs here

The signing request sent to gcr-ssh-agent was never coming back.

Keys resurrect after `ssh-add -D`

ssh-add -D   # All identities removed.
ssh-add -l   # personal-github / work-github  ← instantly back

gcr was auto-publishing keys from its keyring storage. And that auto-restored state was broken for signing.

Cleaning up via Seahorse was risky

When I tried to delete SSH key entries in Seahorse (GNOME's keyring manager), I realized it looked like it would delete the actual private key files (~/.ssh/id_ed25519_personal) along with them.

That was the end of the gcr unification attempt.

What Remained Unexplained

I never found the root cause of gcr-ssh-agent's signing hang. Here's what I was able to rule out:

The key files were not corrupted
The public keys on GitHub were registered correctly
Exposing the Flatpak socket was not the sole cause
~/.ssh/config Host aliases were not misconfigured

→ gcr-ssh-agent's auto-restored state was unstable at signing time
→ Root cause: unknown

This isn't a verdict that gcr-ssh-agent is broken. This problem happened in this environment. Given that, I chose to prioritize determinism and switch to OpenSSH ssh-agent.

Pinning OpenSSH ssh-agent as a systemd User Service

I decided to manage a plain OpenSSH ssh-agent with a fixed socket path under systemd user.

mkdir -p ~/.config/systemd/user

cat > ~/.config/systemd/user/ssh-agent.service <<'EOF'
[Unit]
Description=OpenSSH key agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a %t/ssh-agent.socket

[Install]
WantedBy=default.target
EOF

systemctl --user daemon-reload
systemctl --user enable --now ssh-agent.service

The socket is now pinned at /run/user/1000/ssh-agent.socket.

Updating `~/.ssh/config`

I added explicit IdentityAgent directives so SSH connections don't depend on the current value of SSH_AUTH_SOCK.

Host github-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_personal
    IdentitiesOnly yes
    AddKeysToAgent yes
    IdentityAgent /run/user/1000/ssh-agent.socket

Host github-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes
    AddKeysToAgent yes
    IdentityAgent /run/user/1000/ssh-agent.socket

Normalizing the socket in bash and zsh

Added to both .bashrc and .zshrc:

# OpenSSH ssh-agent (shared between .bashrc and .zshrc)
if [ -S "$XDG_RUNTIME_DIR/ssh-agent.socket" ]; then
  export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"
fi

Dealing with Flatpak

Flatpak's Obsidian runs inside its own sandbox. The host socket needs to be explicitly exposed.

flatpak override --user \
  --filesystem=xdg-run/ssh-agent.socket \
  --env=SSH_AUTH_SOCK=/run/user/1000/ssh-agent.socket \
  md.obsidian.Obsidian

# Remove gcr access
flatpak override --user \
  --nofilesystem=xdg-run/gcr \
  md.obsidian.Obsidian

The Obsidian Git wrapper

Since the Obsidian Git plugin uses /app/bin/git inside the Flatpak, I wrapped it.

cat > ~/.local/bin/obsidian-git <<'EOF'
#!/usr/bin/env bash

SOCK="/run/user/1000/ssh-agent.socket"

export SSH_AUTH_SOCK="$SOCK"
export GIT_SSH_COMMAND="ssh \
  -F /home/rbcn2000/.ssh/config \
  -o IdentityAgent=$SOCK \
  -o BatchMode=yes \
  -o ConnectTimeout=10 \
  -o ServerAliveInterval=5 \
  -o ServerAliveCountMax=1"

exec /app/bin/git "$@"
EOF

chmod +x ~/.local/bin/obsidian-git

BatchMode=yes is the critical part — it prevents the automated commit/sync process from silently hanging while waiting for a passphrase prompt that can never appear.

In the Obsidian Git plugin settings, set Custom Git binary path to /home/rbcn2000/.local/bin/obsidian-git.

Automating Key Loading After Reboot

Unlike gcr, OpenSSH ssh-agent does not restore keys automatically. After a reboot, the agent starts empty.

I considered bringing keychain back, but decided against it — it risks creating duplicate agents. Instead, I wrote a minimal script whose only job is loading the keys.

cat > ~/.local/bin/ssh-load-github <<'EOF'
#!/usr/bin/env bash

set -u

SOCK="/run/user/1000/ssh-agent.socket"
export SSH_AUTH_SOCK="$SOCK"

if [ ! -S "$SOCK" ]; then
  systemctl --user start ssh-agent.service 2>/dev/null || true
fi

if [ ! -S "$SOCK" ]; then
  echo "ssh-agent socket not found: $SOCK" >&2
  exit 1
fi

# Don't wait for passphrase input in non-interactive environments
if [ ! -t 0 ]; then
  exit 0
fi

CURRENT_KEYS="$(ssh-add -l 2>/dev/null || true)"

if ! printf '%s\n' "$CURRENT_KEYS" | grep -q 'personal-github'; then
  ssh-add "$HOME/.ssh/id_ed25519_personal" || exit 1
fi

CURRENT_KEYS="$(ssh-add -l 2>/dev/null || true)"

if ! printf '%s\n' "$CURRENT_KEYS" | grep -q 'work-github'; then
  ssh-add "$HOME/.ssh/id_ed25519_work" || exit 1
fi
EOF

chmod +x ~/.local/bin/ssh-load-github

Call it from .zshrc and .bashrc on interactive shell startup:

if [[ $- == *i* ]] && [ -t 0 ] && [ "${SSH_LOAD_GITHUB_ON_SHELL:-1}" = "1" ]; then
  "$HOME/.local/bin/ssh-load-github" 2>/dev/null || true
fi

Now, the first time a terminal opens after reboot, you enter the passphrase once — and that's it.

The .desktop Launcher Trap

I thought it was solved. There was one more problem.

After a reboot, launching Obsidian first meant Git didn't work.

The culprit was the TTY check inside ssh-load-github:

if [ ! -t 0 ]; then
  exit 0   # No TTY → do nothing
fi

When Obsidian launches from a .desktop file, there is no TTY. So ssh-load-github exits immediately, keys never get loaded, and Obsidian starts up with an empty agent.

The fix: SSH_ASKPASS for a GUI dialog

OpenSSH has a built-in mechanism for exactly this situation: SSH_ASKPASS.

sudo apt install ssh-askpass-gnome

I wrote a dedicated launcher that uses it:

cat > ~/.local/bin/open-obsidian <<'EOF'
#!/usr/bin/env bash

SOCK="/run/user/1000/ssh-agent.socket"
export SSH_AUTH_SOCK="$SOCK"

if [ ! -S "$SOCK" ]; then
  systemctl --user start ssh-agent.service 2>/dev/null || true
fi

if [ ! -S "$SOCK" ]; then
  echo "ssh-agent socket not found: $SOCK" >&2
  exit 1
fi

# Accept passphrase input via GTK dialog even without a TTY
export SSH_ASKPASS="/usr/lib/openssh/gnome-ssh-askpass"
export SSH_ASKPASS_REQUIRE=force

CURRENT_KEYS="$(ssh-add -l 2>/dev/null || true)"

if ! printf '%s\n' "$CURRENT_KEYS" | grep -q 'personal-github'; then
  ssh-add "$HOME/.ssh/id_ed25519_personal" || exit 1
fi

CURRENT_KEYS="$(ssh-add -l 2>/dev/null || true)"

if ! printf '%s\n' "$CURRENT_KEYS" | grep -q 'work-github'; then
  ssh-add "$HOME/.ssh/id_ed25519_work" || exit 1
fi

exec flatpak run md.obsidian.Obsidian "$@"
EOF

chmod +x ~/.local/bin/open-obsidian

Overriding the .desktop file

The system-side Flatpak .desktop file can't be edited directly — Flatpak updates would overwrite it. Instead, copy it to the user applications directory and redirect the Exec line.

cp /var/lib/flatpak/exports/share/applications/md.obsidian.Obsidian.desktop \
   ~/.local/share/applications/md.obsidian.Obsidian.desktop

sed -i 's|^Exec=.*|Exec=/home/rbcn2000/.local/bin/open-obsidian %U|' \
   ~/.local/share/applications/md.obsidian.Obsidian.desktop

update-desktop-database ~/.local/share/applications/

Now, launching Obsidian from the app launcher shows a GTK passphrase dialog first, then starts Obsidian.

The Final Architecture

systemd user
  ↓
OpenSSH ssh-agent.service
  ↓
/run/user/1000/ssh-agent.socket
  ├─ bash / zsh (ssh-load-github on shell startup)
  ├─ ~/.ssh/config (IdentityAgent explicit)
  └─ ~/.local/bin/open-obsidian  ← launched from .desktop
       └─ SSH_ASKPASS=gnome-ssh-askpass (GTK dialog)
            ↓
          Flatpak Obsidian
               ↓
             ~/.local/bin/obsidian-git (BatchMode=yes)
               ↓
             /app/bin/git

After a reboot, behavior is now fully symmetric:

Opening a terminal first:
  → ssh-load-github runs
  → passphrase entered once
  → shared across bash / zsh / Obsidian for the rest of the session

Opening Obsidian first:
  → open-obsidian runs
  → GTK dialog prompts for passphrase
  → shared across bash / zsh / Obsidian for the rest of the session

Separation of Concerns

In the end, the responsibilities around ssh-agent sorted themselves into a clear table:

Responsibility	Handled by
Agent startup	systemd user `ssh-agent.service`
Agent selection	`SSH_AUTH_SOCK` / `IdentityAgent`
Key loading (terminal)	`ssh-load-github` (TTY present)
Key loading (GUI launch)	`open-obsidian` + `SSH_ASKPASS` (no TTY)
Unattended Git operations	`BatchMode=yes`

Tools like keychain that handle everything in one shot are convenient, but they make it easy to accidentally create duplicate agents or fail to reach GUI applications. Separating the responsibilities made it clear exactly what was happening at every step.

Lessons Learned

An environment variable is not a "setting" — it is the result of process inheritance.

Even if SSH_AUTH_SOCK is correctly set somewhere, it only reaches a child process if that child is spawned from a process that has it. Configuration written in .zshrc simply does not reach GUI applications. That was the root of everything.

And an additional lesson:

Sometimes a fixed socket with a simple agent is more deterministic than a polished GUI integration.

gcr-ssh-agent's desktop integration is elegant. But in this environment, its auto-restore mechanism turned out to be unstable at signing time. A plain OpenSSH ssh-agent on a fixed socket was far more predictable.

I Quit .bashrc.

rbcn — Sat, 30 May 2026 17:47:33 +0000

Introduction

One morning, the j command was gone.

I had been using it as an alias for zoxide, but suddenly it returned command not found. It worked fine in Ghostty, but not in VSCode's integrated terminal. Zed behaved differently yet again.

I had built the perfect "I can't explain why this works" environment.

This is the story of what happens when you keep piling settings into .bashrc — and what you gain when you stop.

Before: The Everything-in-.bashrc Era

When I started Linux development, I added a new line to .bashrc every time I introduced a useful tool.

# .bashrc (bloated state)
eval "$(starship init bash)"
eval "$(zoxide init bash)"
eval "$(fzf --bash)"
eval "$(keychain --quiet --eval --agents ssh id_ed25519_work id_ed25519_personal)"
source ~/.bash_aliases
export PATH="$HOME/.local/bin:$PATH"
# ... secrets, completions, etc.

Aliases, completions, environment variables, and tool initializations were all jammed into a single file.

This caused three main problems.

① PATH inconsistency

Some tools would have their paths registered and some wouldn't. Every time I opened a new terminal, things might behave differently.

② Behavioral differences across terminals

Commands that worked in Ghostty didn't work in VSCode's integrated terminal. The disappearing j command was the clearest symptom.

③ Loss of reproducibility

I could no longer explain why things worked. Was it my config? Something I ran earlier? I had no idea.

The Insight: Shell ≠ Environment

As I worked through the problem, something clicked.

Shell ≠ Environment
Shell = UI (the interface)
Environment = execution context

.bashrc had been doing two completely different jobs at once: configuring the OS-standard shell and initializing the development environment. That was the root of all the confusion.

The problem wasn't the tools themselves (zoxide, starship). It was the mixing of initialization paths. Login shells and interactive shells read different files — that discrepancy was causing the behavioral differences across terminals.

After: Decomposing into Three Layers

Based on this insight, I split the environment into three distinct layers.

bash     = OS-standard / preservation layer
zsh      = development environment layer
terminal = display layer (all unified to zsh -l)

Returning bash to a preservation layer

I reset .bashrc to the system default.

cp /etc/skel/.bashrc ~/.bashrc

The only thing I kept was an expanded HISTSIZE. All development-specific configuration was removed.

Consolidating the development environment into zsh

Development tool initialization moved to .zshrc.

# ~/.zshrc
eval "$(starship init zsh)"
eval "$(zoxide init zsh)"
source ~/.zsh_aliases
export PATH="$HOME/.local/bin:$PATH"

Aliases were also separated into .zsh_aliases.

Unifying all terminals to `zsh -l`

I updated each terminal's configuration to launch zsh as a login shell.

Ghostty

command = /usr/bin/zsh -l

VSCode

"terminal.integrated.profiles.linux": {
  "zsh": {
    "path": "/usr/bin/zsh",
    "args": ["-l"]
  }
},
"terminal.integrated.defaultProfile.linux": "zsh"

Zed (v1.0.0)

"terminal": {
  "shell": {
    "with_arguments": {
      "program": "/usr/bin/zsh",
      "args": ["-l"]
    }
  }
}

WezTerm (~/.wezterm.lua)

local wezterm = require 'wezterm'
local config = {
  default_prog = { '/usr/bin/zsh', '-l' },
  font = wezterm.font('JetBrainsMono Nerd Font'),
  font_size = 13.0,
  color_scheme = "Dracula",
  enable_tab_bar = false,
}
return config

WezTerm takes the shell and its arguments as an array via default_prog. Font settings can be unified here as well.

Gotchas Along the Way

A few things tripped me up during the migration.

Icons turn into tofu squares in VSCode only

Symptoms:

Ghostty → OK
Zed     → OK
VSCode  → icons render as □ (tofu)

The cause: VSCode has a separate font setting for its integrated terminal.

"terminal.integrated.fontFamily": "JetBrainsMono Nerd Font Mono"

Adding this line fixed it.

The display name and actual name of the font don't match

Display name: JetBrainsMono Nerd Font Mono
Actual name:  JetBrainsMono NFM

Ghostty resolves this transparently via fontconfig. WezTerm and Zed may require specifying JetBrainsMono NFM explicitly.

The `j` command disappeared

I had alias j='z' in .bash_aliases, but after migrating to zsh it needed to move to .zsh_aliases.

# ~/.zsh_aliases
alias j='z'
alias ji='zi'

`$0` and `$SHELL` show different values

echo $0      # → zsh
echo $SHELL  # → /bin/bash

$SHELL reflects the login shell, not necessarily the currently running shell. Adding this to .zshrc aligns them:

export SHELL=/usr/bin/zsh

Results

Before: everything in .bashrc → non-deterministic environment
After:  bash=preservation / zsh=development / terminal=display → determinism restored

Same environment regardless of which terminal launches it
PATH issues eliminated
Debugging scope narrowed to the application itself

The biggest win: I can now explain why things work.

Closing

Quitting .bashrc wasn't about abandoning tools.
It was about making ownership of the environment explicit.

Shell is UI. Environment is execution context. Cramming both into the same file was the source of all the confusion.

In the next post, I'll cover what happened immediately after this migration: Obsidian Git's SSH authentication broke, and I found myself in a battle with ssh-agent and the Flatpak sandbox.

DEV Community: rbcn

I Built a Pipeline to Publish This Post.

Introduction

The Problem with Manual Publishing

The Architecture

Component 1: The GitHub Relay Repo

Component 2: The Claude Code Skill

Component 3: Unsplash Cover Images

The Decision to Use a Relay Repo

What the Frontmatter Looks Like

Lessons

What's Next

Migrating to zsh Broke Obsidian Git.

Introduction

The Structure of the Problem

Why Did It Work Before?

Attempting gcr-ssh-agent Unification (and Failing)

Signing hangs

Keys resurrect after ssh-add -D

Cleaning up via Seahorse was risky

What Remained Unexplained

Pinning OpenSSH ssh-agent as a systemd User Service

Updating ~/.ssh/config

Normalizing the socket in bash and zsh

Dealing with Flatpak

The Obsidian Git wrapper

Automating Key Loading After Reboot

The .desktop Launcher Trap

The fix: SSH_ASKPASS for a GUI dialog

Overriding the .desktop file

The Final Architecture

Separation of Concerns

Lessons Learned

I Quit .bashrc.

Introduction

Before: The Everything-in-.bashrc Era

The Insight: Shell ≠ Environment

After: Decomposing into Three Layers

Returning bash to a preservation layer

Consolidating the development environment into zsh

Unifying all terminals to zsh -l

Gotchas Along the Way

Icons turn into tofu squares in VSCode only

The display name and actual name of the font don't match

The j command disappeared

$0 and $SHELL show different values

Results

Closing

Keys resurrect after `ssh-add -D`

Updating `~/.ssh/config`

Unifying all terminals to `zsh -l`

The `j` command disappeared

`$0` and `$SHELL` show different values