Forem: Anguishe

I Built a Free Tools Directory for Linux Users Who Are Tired of Googling the Same Commands

Anguishe — Thu, 07 May 2026 20:51:35 +0000

The Problem I Keep Running Into

I've written the same bash script scaffolding at least 40 times. Every time I spin up a new automation, I start from scratch: add the shebang, remember the set -euo pipefail line, define variables, write the same error-handling block I always use, forget to add a usage message until the third time I run it wrong.

And don't get me started on chmod. I Google "chmod 755 vs 644" at least once a month, even though I know what it means. The octal-to-permission mapping just doesn't stick unless you're using it every single day.

So I built something to fix both of those problems — and it's turning into a whole directory of tools.

What I Built: bashsnippets.xyz/tools

bashsnippets.xyz/tools is a free directory of interactive tools for Linux users and developers. No signup. No rate limits. Works in the browser. Copy and go.

Right now it has two tools live, with a new one shipping every week:

1. chmod Permissions Builder

Click checkboxes for read/write/execute across owner/group/others. Get the exact chmod command instantly — both octal and symbolic — with a plain-English explanation.

Example output:

chmod 755 filename
chmod u=rwx,g=rx,o=rx filename

Owner: read + write + execute

Group: read + execute

Others: read + execute

If you've ever second-guessed whether a script needs 755 or 744, this eliminates the lookup step permanently.

→ Try the chmod builder

2. Bash Boilerplate Generator

Pick your script type (automation, backup, monitoring, deployment), toggle options (error handling, logging, dry-run mode, help message), optionally inject a snippet from the library, and get a production-ready .sh template with everything wired up.

No more blank files. No more copying the same header block from your last script.

→ Try the boilerplate generator

What's Coming Next

I'm shipping a new tool every week. The queue right now:

Cron Job Builder — visual cron syntax builder with plain-English output
Exit Code Lookup — paste an exit code, get the meaning instantly
systemd Unit File Generator — build service files without memorizing the spec

Each one solves a specific "I always Google this" problem.

Why I Built This (and Why It's Free)

I got tired of opening 6 Stack Overflow tabs every time I needed to do something I'd done 20 times before. These aren't complex problems — they're just pattern-matching tasks where the syntax is annoying to remember.

The tools are free because:

They're simple enough that paywalling them would be ridiculous
I want them to be genuinely useful, not VC-funded SaaS bloat
The snippet library (which the tools complement) has always been free

There's no business model. Just a side project that scratches an itch I have, and apparently a lot of other people have too based on the YouTube Shorts I've been posting.

Try It

bashsnippets.xyz/tools

If you spot bugs, missing features, or have ideas for new tools, drop a comment. I'm building this in public and genuinely want feedback from people who actually use bash day-to-day.

Stop Guessing 'chmod' I Built a Free Visual Permissions Builder for Linux

Anguishe — Thu, 07 May 2026 20:31:05 +0000

The Problem

You're about to deploy a script. You know you need the file executable, but readable only by the owner. You type chmod 754... or was it 744? Maybe 755?

You Google it. You find a Stack Overflow thread from 2011. You get it wrong anyway.

chmod's octal notation is one of those things every Linux user has to look up every single time — and the mental model for why 755 means what it means isn't obvious unless you've memorized the bit table.

I built a tool to fix that permanently.

The Tool: chmod Permissions Builder

🔗 bashsnippets.xyz/tools/chmod-permissions-builder.html

It's a free, no-login, browser-based tool. You click checkboxes for Owner, Group, and Others — read, write, execute — and it instantly generates:

The chmod octal command (chmod 755 filename)
The symbolic command (chmod u=rwx,g=rx,o=rx filename)
A plain-English explanation of what those permissions mean

No ads walls. No email required. Copy and go.

How chmod Permissions Actually Work

Before we get to the tool output, here's the bit math that makes it click once:

Each permission set (owner / group / others) is a 3-bit binary number:

Permission	Binary	Octal
`---`	000	0
`--x`	001	1
`-w-`	010	2
`-wx`	011	3
`r--`	100	4
`r-x`	101	5
`rw-`	110	6
`rwx`	111	7

So chmod 755 means:

7 = owner gets rwx (read + write + execute)
5 = group gets r-x (read + execute, no write)
5 = others get r-x

That's it. Once you see it as binary, it's never confusing again. The tool builds this table live as you click.

Common Permission Combos

Here are the most-used values and what they're for:

chmod 755 script.sh      # Executable script — owner can edit, others can run
chmod 644 config.conf    # Config file — owner can edit, others read-only
chmod 600 .ssh/id_rsa    # Private key — owner only, no one else
chmod 777 /tmp/shared    # Fully open (use sparingly, never on production)
chmod 700 ~/scripts/     # Private directory — owner only

How to Apply Permissions Recursively

The builder outputs a single-file command. If you need to apply permissions across a whole directory:

# Apply 755 to all directories, 644 to all files
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

Or use the -R flag (with care):

chmod -R 755 /var/www/html

⚠️ Never run chmod -R 777 on anything outside a throw-away sandbox. It removes all security boundaries.

Check Current Permissions Fast

Before changing anything, inspect what's there:

ls -la filename          # Single file
stat filename            # Verbose output including octal
ls -la /path/to/dir/     # Directory listing

stat shows you the octal directly — useful when you need to replicate permissions from one file to another:

stat -c "%a" filename    # Just the octal number

Try the Tool

If you set the wrong permissions on a web server config or SSH key, things break in ways that are slow to debug. Getting it right the first time matters.

→ Open the chmod Permissions Builder

No login. No install. Works on mobile too.

More free tools and copy-paste bash scripts at bashsnippets.xyz

Every bash script I write starts with the same 20 lines. So I made a generator for them.

Anguishe — Wed, 06 May 2026 21:00:43 +0000

There's a set of things every bash script should have at the top. Not "here are some nice-to-haves" — actual things that prevent real, bad, hard-to-debug failures:

#!/bin/bash
set -euo pipefail
IFS=$'\n\t'

set -e makes the script exit immediately if any command returns a non-zero status. Without it, your script keeps running after a failure and you get compounding errors that are confusing to trace.

set -u makes the script error if you reference a variable that hasn't been set. Without it, $MYVAR being undefined silently evaluates to an empty string. That empty string goes into a path. That path gets passed to rm -rf. You see where this goes.

set -o pipefail makes the exit status of a pipeline reflect the first failure in the chain, not just the last command. broken_command | grep something would exit 0 without this flag, because grep succeeded even though the input was empty.

IFS=$'\n\t' prevents word splitting on spaces in filenames. Without it, a filename like my file.txt gets treated as two arguments.

This is what I call the mandatory header. I've forgotten parts of it enough times that I stopped trying to remember it and started generating it.

The Boilerplate Generator

You configure:

Script identity — name, description, author. These go in the comment block at the top so someone reading the script 6 months from now (probably you) knows what it's supposed to do.

Safety flags — each one is a checkbox with an explanation of what it does. `set -x` is there too for debug mode — I often add it temporarily when something isn't working, then remove it before deploying.

Features:

Timestamped log() function — stops you from using raw echo for output, which doesn't timestamp. When you're looking at a log file and everything just says "backup complete" with no time attached, you'll wish you had this.
CHECK / CROSS variables — adds CHECK="✓" and CROSS="✗" at the top, which is the convention across all BashSnippets scripts. Consistent visual output in the terminal.
Argument parser with --help and --dry-run — getopts-based. Dry run mode is something I use constantly during development to test a script's logic without actually writing/deleting/moving anything.
Lock file — prevents duplicate runs. If you're scheduling something with cron and the job sometimes runs long, without a lock file you can end up with two instances trying to write to the same output file.
Root check — exits cleanly with an error if the script isn't run as root, instead of failing halfway through with a permission error.
Trap on EXIT — runs a cleanup() function on exit or interruption, which you can populate with whatever teardown logic makes sense.

Snippet injection — you can pull in a script from the library (disk space warning, file backup, delete old logs, etc.) and have it dropped into the body of the generated boilerplate. So you're not starting from zero — you're starting from a working script wrapped in production safety.

What the output looks like

When you configure everything and click copy, you get a complete `.sh` file: shebang, comment block, safety flags, feature code, and your injected snippet (if any) in the main logic section. There's even a source comment pointing back to bashsnippets.xyz so your team knows where the template came from.

I use this myself. Every new script starts here.

Why this exists as a tool instead of a GitHub gist

Because I kept updating my gist as I learned new things, and then had five different versions floating around in different places. A tool with checkboxes forces me to be explicit about what I'm including and why, and the output is always current.

Try it: https://bashsnippets.xyz/tools/bash-boilerplate-generator.html

Free, no login, GitHub Pages. Generates clean `.sh` output you can paste directly into a file and start editing.

Stop Googling "what is exit code 127" There's a better way to handle it

Anguishe — Wed, 06 May 2026 20:57:35 +0000

Exit code 127 means "command not found." I know that now. But the first dozen times I saw it, I Googled it. Every time. Because exit codes are one of those things that are fundamental to bash scripting but never feel intuitive until you've been burned by them enough.

Here's a quick table of the ones that show up constantly:

Code	Meaning
0	Success
1	General error
2	Misuse of shell built-in
126	Command found but not executable
127	Command not found
130	Script killed with Ctrl-C
137	Process killed with SIGKILL (kill -9)
139	Segmentation fault
143	Process killed with SIGTERM

The rule for codes above 128: subtract 128 to get the signal number. 137 = 128 + 9 (SIGKILL). 143 = 128 + 15 (SIGTERM). Once you know that pattern, a lot of the high-numbered codes make sense.

But looking up the code is only half the problem

The other half is writing the error handler. And this is where most scripts fall short. They check `$?` after a command, but the handler is usually something like:

if [ $? -ne 0 ]; then
  echo "something went wrong"
  exit 1
fi

Which tells you almost nothing when you're looking at logs at 2am.

I built a tool that generates a proper handler for any code you give it.

The Exit Code Lookup tool

You go to https://bashsnippets.xyz/tools/bash-exit-code-lookup.html, type in a code — or click one of the common ones — and you get:

What the code means
The most likely causes (this is the part that actually saves time)
A copy-paste error handler in your choice of format: if/else block, case statement, or inline || fallback

The if/else output names the code explicitly, logs what failed, and exits with the same code so the calling process knows something went wrong. The case statement version is better if you're handling multiple possible outcomes. The inline `||` is what you want when you're doing something quick and you just need a fast bail-out.

One thing I added that I actually use myself: the quick-click buttons for the codes you see constantly. You don't have to type 127 — just click it, get the handler, copy it.

Common situation this actually helps with

You're writing a script that calls a binary. You want to handle the case where the binary isn't installed (127), the case where the binary exists but fails on the input (1), and the case where someone Ctrl-C'd it (130). Those three cases need different responses — log and exit, retry with different args, clean up and exit gracefully — and the case statement the tool generates is structured for exactly that.

The thing I keep adding to all my scripts now

trap 'echo "Script failed at line $LINENO with exit code $?" >&2' ERR

Put that near the top of any script that matters. When it fails — and things fail — you know exactly where and with what code. Pair it with the exit code lookup when you're not sure what the code means, and you cut debugging time significantly.

Try it: https://bashsnippets.xyz/tools/bash-exit-code-lookup.html

No signup. All 256 codes (0-255) are in there. The handlers are copy-ready and production-quality, not the half-baked one-liners you find on random Stack Overflow answers.

I got tired of deploying broken cronjobs, so I built a tool that generates them properly

Anguishe — Wed, 06 May 2026 20:54:04 +0000

Every linux user has a story. Mine is a backup script that silently failed for three weeks because the cron expression was right but the PATH wasn't set, so the script couldn't find tar. Backups looked like they were running. Nothing was actually being archived. I found out when I needed to restore a file.

That specific failure mode — cron jobs that pass silently but don't actually do anything — is one of the most annoying problems in Linux automation because there's no obvious error. The job runs. The exit code is 0. Your logs say nothing because you didn't add logging. And now you're debugging something that happened at 2am three weeks ago.

So I built a tool.

What it does

The Cron Job Builder at bashsnippets.xyz does three things that I always forget to do manually:

1. Builds the expression visually

You pick minute, hour, day of month, month, and day of week from dropdowns. It assembles the expression in real time. There are also quick presets — daily 2am, every 6 hours, weekdays 9am, monthly, every 15 minutes — for the schedules you actually use 90% of the time.

2. Wraps it in production-safe bash

This is the part that actually matters. The tool adds:

>> /var/log/cronjob.log 2>&1 — so stdout and stderr go somewhere you can read them later
SHELL=/bin/bash — because cron's default shell is not what you think it is
PATH=/usr/local/bin:/usr/bin:/bin — this is the one that burned me. Cron has a stripped-down PATH. Commands that work in your terminal fail silently in cron because the binary isn't in scope.
MAILTO=you@example.com — optional, but useful for catching failures you're not watching for
Lock file via flock — prevents a slow job from stacking on top of itself if it runs longer than the schedule interval

Every single one of these is a checkbox. You don't have to remember them — you just check what you need.

3. Shows the next 10 scheduled run times

So you can verify the expression is actually doing what you think it's doing before you paste it into crontab.

You can also inject a snippet from the library

The tool has a dropdown that lets you pull in a pre-built script from the BashSnippets library — file backup, disk space warning, delete old logs — and have it wrapped in the boilerplate automatically. So you go from "I want to back up my home directory nightly" to a full, copy-ready crontab entry in about 20 seconds.

Why I built this on a static site

The whole site is GitHub Pages. No backend, no database, no server-side anything. The cron expression parser, the next-run-time calculator, all of it runs in the browser. That means it loads fast, works offline if you've cached it, and I don't have to pay for compute just so someone can build a cron expression.

Try it: https://bashsnippets.xyz/tools/cron-job-builder.html

Everything on BashSnippets is free. No login, no email capture, no limit on how many times you use it. Just open it, configure it, copy the output.

If you've ever had a cronjob fail silently and had to debug it at an awkward hour, this is for you.

CodeLegion? I think so. . .

Anguishe — Wed, 06 May 2026 16:53:42 +0000

🚀 Check out my CoderLegion profile & latest post!

🏆 Points: 162 | 🎱 Badges: 5 | 👥 Followers: 0 | 📄 Posts: 3

Latest post: "I built a free bash script library because I kept Googling the same 10 scripts over and over"
Read it here: https://coderlegion.com/16878/i-built-a-free-bash-script-library-because-i-kept-googling-the-same-10-scripts-over-and-over

View my full profile: https://coderlegion.com/user/BashSnippets

Come join me!

My site went down for a few hours yesterday and my users knew before me

Anguishe — Mon, 04 May 2026 23:26:36 +0000

It happened to me.

My site — bashsnippets.xyz — had been down for six hours before I knew
about it. I found out because a reader emailed me. Not because I checked.
Not because I had monitoring. Because someone else had to tell me.

That's the kind of thing that sits with you.

The fix took 20 minutes to build. Here's exactly what I wrote and why
every piece of it matters.

The problem with checking manually

The natural instinct is to just open a browser and load the page.
But that has two failure modes:

You only check when you remember to
You don't check at 2am when it actually goes down

What you want is automated, logged, and running while you sleep.

Start with the one-liner

Before building the full script, understand the core command:

curl -o /dev/null -s -w "%{http_code}" https://yoursite.com

Run it. It prints one number. That number is your site's HTTP status code.

Here's what each flag does — and this is worth understanding
because you'll use these flags for a lot more than uptime checking:

-o /dev/null — tells curl to discard the response body entirely.
You don't need the HTML. You only need the status code.
Without this flag, curl dumps the entire page to your terminal.

-s — silent mode. Suppresses the progress bar and error messages.
Without this, curl prints download stats you don't need.

-w "%{http_code}" — write-out format. Tells curl to print only
the HTTP status code after the request completes.
This is the only output you care about.

Result: just the number. Nothing else. Clean, parseable, scriptable.

$ curl -o /dev/null -s -w "%{http_code}" https://bashsnippets.xyz
200

Status codes you need to know

Code	Meaning	What to do
200	Up and healthy	Nothing
301/302	Redirect — usually fine	Check it's intentional
404	Page not found	Check your URL
503	Server error — site is down	Investigate immediately
000	DNS failure / unreachable	Your server may be completely offline

The full script

Now wrap it in logic that tells you what the number means:

#!/bin/bash

CHECK="✓"
CROSS="✗"

URL="https://bashsnippets.xyz"
STATUS=$(curl -o /dev/null -s -w "%{http_code}" "$URL")

if [ "$STATUS" -eq 200 ]; then
  echo "$CHECK $URL is up (HTTP $STATUS)"
else
  echo "$CROSS $URL returned HTTP $STATUS — check it"
fi

The $CHECK and $CROSS variables aren't required — you could hardcode
the symbols directly — but defining them at the top makes it trivial
to change the output format later and keeps the echo lines readable
at a glance.

Save this as uptime.sh in your home directory.

Make it executable

chmod +x ~/uptime.sh

chmod +x adds execute permission to the file. Without this,
bash treats it as a plain text file and refuses to run it.
This is the step people forget. Every time.

Test it manually before scheduling anything:

./uptime.sh
# ✓ https://bashsnippets.xyz is up (HTTP 200)

Schedule it with cron

A script you run manually is still manual monitoring.
The goal is automation — the script checks your site while you sleep.

Open your crontab:

crontab -e

Add this line:

*/5 * * * * ~/uptime.sh >> ~/uptime.log 2>&1

Breaking this down:

*/5 * * * * — run every 5 minutes. The */5 means "every 5th
minute of every hour of every day." Change to */1 to test it faster.

~/uptime.sh — the script to run. The ~/ expands to your
home directory — safer than a relative path.

>> ~/uptime.log — append output to a log file.
Using >> instead of > means each result adds to the file
rather than overwriting it. You want a history, not just the last result.

2>&1 — redirect stderr to stdout so errors also get logged.

Save and exit. Cron confirms: crontab: installing new crontab

Watch it run in real time

tail -f ~/uptime.log

tail -f watches a file and prints new lines as they're added.
Open this in a second terminal after setting up cron.
Within a minute you'll see the script run on its own —
no input from you, no trigger, just cron firing the script
and the result appearing in the log automatically.

That moment where the second line appears on its own —
that's the confirmation that automation is actually working.

The full copy-paste version

#!/bin/bash

CHECK="✓"
CROSS="✗"

URL="https://yoursite.com"   # ← change this to your site
STATUS=$(curl -o /dev/null -s -w "%{http_code}" "$URL")

if [ "$STATUS" -eq 200 ]; then
  echo "$CHECK $URL is up (HTTP $STATUS)"
else
  echo "$CROSS $URL returned HTTP $STATUS — check it"
fi

Cron line to add with crontab -e:

*/5 * * * * ~/uptime.sh >> ~/uptime.log 2>&1

Full reference page with all variations:
→ bashsnippets.xyz/snippets/check-if-website-is-up.html

I post a new copy-paste bash script every week at bashsnippets.xyz.
All free. No signups. @BashSnippets on YouTube if you want to see these in 30-second form.

How do you monitor your sites? I'm genuinely curious what the rest of you are running 👇

I was killing Ollama processes the hard way for months. A one-word command fixed it.

Anguishe — Mon, 04 May 2026 18:07:14 +0000

I run a lot of local LLMs. Ollama, OpenWebUI, coding models.

llama3, qwen-coder models, deepseek-coder, whatever I'm testing that week.

The problem is Ollama doesn't always clean up after itself.

Pull a few models. Run them. Close the terminal. Think you're done.
You're not. There are now 3 or 4 ollama and ollama_llama_server
processes still sitting in the background, each one holding
6-8 GB of RAM hostage while I am trying to actually get stuff done.

I'd notice it when my machine started lagging mid-session.
Open a terminal, run ps aux, and get back a wall of text
200 lines deep. Scroll through it. Find the PID. Copy it.
Run kill. Realize there are two more and loop this way for an hour trying to clean everything up.

Four commands. Every single time. For months:

bash
ps aux | grep ollama   # step 1: find it
# scroll through output, locate PID
# e.g. 47823
kill 47823             # step 2: kill it
# still running? find the next one
kill 47824             # step 3: kill that one too
# check again...

This is my struggle for months. But then i learned pkill.

pkill exists and I ignored it

pkill lets you kill any process by name. No PID hunting.
No ps aux wall of text. One command.

pkill ollama

That's it. Every Ollama process, the server, the model runner,
all of it. A fresh start, per se.

But before you run that blindly, always do a pgrep first.
It shows you exactly what you're about to kill without
actually killing anything:

pgrep -l ollama

Output:
47823 ollama
47824 ollama_llama_server
47825 ollama_llama_server

Three processes. All Ollama. All eating RAM. Now you know
what you're working with before you pull the trigger.

Then kill them all in one shot:

pkill ollama

Verify they're gone:

pgrep -l ollama
# no output = all clear

Done. The whole workflow takes 3 seconds instead of 3 minutes.

The flags I actually use

# Preview before killing — always do this first
pgrep -l ollama

# Kill all matching processes by name
pkill ollama

# Exact match only — won't catch ollama_llama_server
pkill -x ollama

# Force kill if it's frozen and won't respond
pkill -9 ollama

# Kill a specific model process by full command string
pkill -f "ollama_llama_server"

The -f flag is especially useful when you have multiple
models running and only want to kill one of them.
pkill -f "codellama" will only hit the codellama process
and leave everything else running.

Why this matters more with local LLMs

With normal processes you might have one or two orphans at a time.
With Ollama you can easily have five or six. Tthe main server,
plus a separate runner process for each model you've touched
in a session. kill with a PID was never designed for
cleaning up that many processes at once, the runner processes were adding up.

pkill was.

If you're running local LLMs regularly, this is the command
that keeps your RAM clean between sessions. Add it to muscle
memory alongside ollama list and ollama ps.

Full pkill/pgrep reference with every flag:

→ bashsnippets.xyz/snippets/kill-a-process.html

Free bash scripts for Linux and devs every week:
→ bashsnippets.xyz

Also posted Short #5 on this yesterday if you want to see
the before/after in 30 seconds:
@BashSnippets on YouTube

I built a couple bash scripts this week after my server crashed Thursday at 11pm

Anguishe — Sun, 03 May 2026 22:55:51 +0000

My disk hit 100% on a Thursday night. Just a silent crash and a bunch of errors I found the next day.
I had nothing running in the background watching for problems.

Disk space warning** The script I needed before that Thursday happened.

`#!/bin/bash
THRESHOLD=80
USAGE=$(df / | awk 'NR==2{print $5}' | tr -d '%')

if [ "$USAGE" -gt "$THRESHOLD" ]; then
  echo "⚠ Disk at ${USAGE}% — time to act"
else
  echo "✓ Disk OK: ${USAGE}% used"
fi`

I just happened to be doing some brushing up on crontab a bit lately so I automated the script before I did anything else, so this wouldn't happen again.
Full script with email alerts → bashsnippets.xyz/snippets/disk-space-warning.html

2. Killing Processes
I also found myself continuing to fall into a ps aux | grep ""
loop after cleaning up the disk and new there was a one-word command out there that made it easier, but I couldn't recall...
I had to google it a few times before it stuck with me:

pkill/pgrep <--- turned a 4 command work-flow into a one-word workflow:
My loop was this:

ps aux | grep myapp   # find it
kill 12345            # copy/paste PID
ps aux | grep myapp   # confirm it died

After, it was this:

pgrep -l myapp
pkill -x myapp

Where this went:

So, of course, these and a few more, like error handling, turned into a free, and growing script library at bashsnippets.xyz — copy-paste ready, explained line by line, no signup.

I also started turning each one into a short video on YouTube (@bashsnippets). Hoping to gain some traction in the beginner bash communities!

Hope someone can find some use of this, but What are you automating? Drop it in the comments.

I Got Tired of Googling the Same Bash Commands, So I Built This. . .

Anguishe — Sat, 02 May 2026 21:02:27 +0000

I kept running into the same problem while working in Linux and dev environments.

The small intricacies between zsh and bash hit me at the worst time.... every time. When in need of a Bash command, I’d end up doing the same cycle:

Open Google
Search “how to…”
Find slightly different answers
Test, break something, repeat...

It wasn’t hard. . . it was just slow and monotonous.
So, I began collecting the commands I actually used in real projects and organizing them into a personal cheat-sheet.

Over time, it turned into a small curated collection of Bash snippets, Linux commands, and terminal tricks that I now use almost daily.

Things like:

faster file searching
process monitoring tricks
Git shortcuts
terminal productivity hacks
small one-liners that replace entire workflows

What I realized is that if something saves you 10 seconds but you use it 50 times a day, it adds up fast. I've been able to go from using 4-5 commands for the same bash one-liner that I just couldn't always recall.

I decided to clean it up and turn it into something public instead of just a local note file.

If you’re into Bash, Linux, or just want to speed up your terminal workflow, I’ve been putting everything here:
Link

It’s still growing, and I’m actively adding new snippets as I find better ways of doing things.

I realize this is super beginner level stuff but if you’ve got any underrated commands you think should be included, I’m always open to suggestions.