"Might could" sounds natural to you but it's a double modal in English

Non-native English speakers — especially those whose native language stacks modals freely — sometimes write things like:

"One thing we might could improve..."

This is a double modal. It exists in some regional American dialects (Southern US) but is grammatically incorrect in standard and professional English. Pick one modal: might or could.

The right choice depends on intent:

  • "One thing we could improve" — confident suggestion, implies you see a concrete area to fix. This is usually what you mean.
  • "One thing we might improve" — tentative, sounds like you're unsure whether improvement will happen at all. Weaker than you probably intend.
  • "One thing we might want to improve" — works, but adds unnecessary words. "Could" is cleaner.

The other trap in the same sentence: "the pipeline I re-run" vs "the pipeline I reran". "Re-run" is the present tense or a noun; if the action already happened, it's reran (past tense).

The corrected sentence:

"One thing we could improve: even though the deployment failed, the pipeline I reran still reported 'All Good'."

Garbled text before PS1 over SSH? Your OSC sequences are leaking

You SSH into a machine and see garbage like ile://host/home/userurrentDir=/home/user before your prompt. Locally everything is fine. What happened?

Your PROMPT_COMMAND includes an OSC 7 / OSC 1337 sequence that reports the current directory to the terminal emulator. Locally, WezTerm (or iTerm2, etc.) intercepts these invisible escape sequences. Over SSH with TERM=linux, no terminal emulator is listening — the raw bytes print as text.

The fix is a guard condition before wiring __report_cwd into PROMPT_COMMAND:

if [[ -n "${TERM_PROGRAM:-}" || "${TERM:-}" =~ xterm|screen|tmux|wezterm|alacritty ]]; then
  [[ ":$PROMPT_COMMAND:" != *__report_cwd* ]] && \
    PROMPT_COMMAND="__report_cwd${PROMPT_COMMAND:+; $PROMPT_COMMAND}"
fi

When TERM=linux (plain SSH) and TERM_PROGRAM is empty, the function is skipped entirely. No escape sequences, no garbage.

After deploying the fix, start a fresh shell — PROMPT_COMMAND is already set in the running session and won't be cleared by re-sourcing.

Short-lived tokens don't belong in the same file as long-lived credentials

You protect ~/.bashrc.secret with chmod 444 so nothing accidentally overwrites your API keys and passwords. Then your token-refresh script needs to write a new session cookie somewhere — and hits Permission denied.

The fix isn't adding a second writable secrets file. It's stop persisting short-lived tokens entirely.

Refactor the refresh script to output TOKEN HASH on stdout and let the caller capture it:

# refresh_token — reads credentials, prints session token to stdout
CREDENTIALS=$(bash ~/bin/refresh_token 2>/dev/null)
TOKEN=$(echo "$CREDENTIALS" | awk '{print $1}')
HASH=$(echo "$CREDENTIALS" | awk '{print $2}')

No file writes. No second secrets layer. The token lives in the process environment for the duration of the operation and disappears when it's done.

This works because session tokens are cheap to re-obtain — one HTTP call with stored credentials. The only reason to persist them is avoiding that call, which is almost never worth the complexity of managing a writable token store alongside a read-only credential store.

The rule: if you can regenerate it from long-lived credentials in under a second, don't persist it.

One Telegram Bot + Two Machines = Silent Message Loss

Running the same Telegram bot relay as a systemd service on multiple machines means both instances poll the same bot token. Telegram delivers each update to one consumer only — so messages vanish at random, or land on the wrong host. Both sides think they're healthy; neither is.

The fix: one bot per machine, one channel per bot. Each channel becomes a dedicated console for exactly one host. No coordination needed, no distributed locks, no split-brain.

To manage multiple bot tokens in a shared dotfiles repo, key them by hostname:

# dotfiles — all tokens in one file, encrypted as usual
export TG_TOKEN_homeserver="token_aaa"
export TG_TOKEN_vps="token_bbb"

# relay picks its own token at runtime
export TG_TOKEN=$(eval echo \$TG_TOKEN_$(hostname))

Every machine runs the same service file unchanged — hostname resolves to the right token automatically. Adding a third machine is just a new bot, a new channel, and one more TG_TOKEN_<hostname> line.

TG Channel: homeserver  →  bot-A  →  machine 1
TG Channel: vps         →  bot-B  →  machine 2
TG Channel: pi          →  bot-C  →  machine 3

`exec bash` vs `bash`: don't nest your shells

After changing your hostname with hostnamectl set-hostname, the current terminal still shows the old name. You want a fresh shell — but bash and exec bash behave differently.

Running bash spawns a child process. Your old shell is still alive underneath, and $SHLVL increments by one. Environment changes (like the new hostname) are picked up, but you've added a layer:

$ echo $SHLVL
1
$ bash
$ echo $SHLVL
2

Nested shells can cause subtle issues — exit only drops you back to the parent, aliases and env vars may differ between layers, and deep nesting is easy to accidentally accumulate.

exec bash replaces the current process in-place (same PID). The old shell is gone, a new one takes over, and $SHLVL stays the same:

$ echo $SHLVL
1
$ exec bash
$ echo $SHLVL
1

This is the clean way to reload your shell config after changing .bashrc, updating $HOSTNAME, or any other env-level change. No nesting, no leftover state.