标签：#bash

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

Introduction My zsh profile is over 1000 lines at this point. A lot of that is functions I asked AI to generate for me, since it's fast, portable, and saves me a ton of typing. Here's the thing though: the shortcuts that save me the most time aren't the clever ones. They're the dumb ones. Things like clone instead of git clone && cd , or dir instead of mkdir -p && cd . Each one only saves a second or two, but I run them so often that it adds up fast. These are in no particular order, just the ones I reach for constantly. Git aliases for common commands A few one-liners I have set up as plain aliases: alias gcp = "git cherry-pick" alias git-append = "git commit --amend --no-edit -a" gcp is self-explanatory. git-append amends the last commit with your currently staged (and unstaged, thanks to -a ) changes without touching the commit message. Great for fixing up a commit you just made before you push. Create a branch or switch to it if it already exists One of my most-used functions. Normally you have to remember whether a branch exists before deciding between git checkout <branch> and git checkout -b <branch> . This just does the right thing either way: gb () { if git rev-parse --verify --quiet " $1 " > /dev/null ; then git checkout " $1 " else git checkout -b " $1 " fi } Nuke all local changes to reset the working tree When an experiment goes sideways or I just want to throw everything away and start clean, I run nah : nah () { git reset --hard git clean -df if [ -d ".git/rebase-apply" ] || [ -d ".git/rebase-merge" ] ; then git rebase --abort fi } This resets tracked changes, removes untracked files and directories. No confirmation prompt, so use it carefully. Print recent commits as ready-to-paste cherry-pick commands Useful when you need to cherry-pick a batch of commits from one branch onto another in order: logs () { if [[ -z " $1 " || " $1 " = ~ [ ^0-9] ]] ; then echo "Usage: logs <number_of_commits>" return 1 fi git log -n " $1 " --reverse --pretty = format: "g

In bioinformatics we are handling a lot of tabular data. Be it VCF files, tabular Blast output, or just creating a CSV or TSV samplesheet. Actually, one of my favorite tabular formats is by using SeqKit to convert Fasta or FastQ files to tabular format, as this allows to do various filtering operations by row , using standard unix tools if so wished. Scrolling through this type of data in the terminal can be messy to say the least though. Although CSVs can of course be imported into a spreadsheet software for viewing, it would be very powerful to be able to view them comfortably right from the terminal, isn't it? To take one example that fits within the code window of a blog post, let's take a selected set of columns from the CSV output from the Mykrobe tool. And to make it emulate another common problem with many csv formats, let's also use tr to convert the _ :s in the headers into real spaces (Mykrobe does not do this, but many other tools do): $ cat SOME_SAMPLE.csv | cut -d , -f 2,3,10,14,15,17,18 | tr '_' ' ' > selection.csv $ cat selection.csv "drug" , "susceptibility" , "kmer size" , "phylo group per covg" , "species per covg" , "phylo group depth" , "species depth" "Amikacin" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Capreomycin" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Ciprofloxacin" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Delamanid" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Ethambutol" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Ethionamide" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Isoniazid" , "R" , "21" , "99.672" , "98.428" , "372" , "347" "Kanamycin" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Levofloxacin" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Linezolid" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Moxifloxacin" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Ofloxacin" , "S" , "21" , "99.672" , "98.428" , "372" , "347" "Pyrazinamide" , "S" , "21" , "99.672"

I once spent forty minutes at eleven at night debugging a deploy that wasn't broken. The release script ran the database migration, the migration threw connection refused , the script exited non-zero, the deploy rolled itself back, and I got paged. So I did the things you do. I read the migration. I read the logs. I checked the database — it was up, it was healthy, it accepted my connection instantly. I re-ran the deploy and it worked. I chalked it up to gremlins and went to bed, which is the part I'm not proud of, because it happened again two days later. That time I watched the timing: the script brought up a fresh database container and started the migration about six seconds before Postgres finished initializing and began accepting connections. The migration was racing the database's boot. Most of the time it won. The times it lost, I lost forty minutes. The script wasn't wrong about anything except one assumption: that a dependency is ready the instant you ask for it. In production, dependencies are eventually ready That's the mental model shift. Networks blip. A service you call returns a 503 for the two seconds it takes to finish a rolling restart. An API rate-limits you with a 429 it fully expects you to retry. A fresh container's database isn't accepting connections for its first few seconds. Treating the first failure as fatal turns every one of these normal, transient conditions into a paged engineer — and the script that handles them isn't smarter — it declines to give up on the first try. But retrying naively is its own trap. Retry instantly and you hammer a recovering service into staying down. Retry forever and a genuinely dead dependency hangs your script indefinitely. Retry a 404 and you wait a minute to confirm what you already knew. Good retries are bounded, backed off, and selective. A retry function you can reuse anywhere #!/bin/bash # Purpose: survive transient failures instead of dying on the first error set -euo pipefail CHECK = "✓" CROSS = "

A */1 rsync took our staging box to a load average of 41 one afternoon, and it took me longer than I want to admit to work out why. The sync normally finished in about twenty seconds. That day the backup target's NFS mount went sluggish, the sync started taking ninety seconds, and cron — which does not know or care whether the last run is still going — launched a fresh copy every single minute on top of it. Inside ten minutes there were a half-dozen rsyncs all reading the same tree off the same slow disk, each one making the disk slower, each new minute adding another. The box wasn't under attack. It was attacking itself, one polite copy at a time. The thing that stung was that nothing was broken — every individual rsync was correct, the disk eventually recovered on its own, and the only reason it became an outage is that cron has no concept of "the last one is still running." That's the trap with scheduled jobs: a command that's perfectly fine when you run it by hand can take down a server the first time it runs longer than its interval with nobody watching. The fix everyone reaches for first is the wrong one The instinct is a PID file: write $$ to /var/run/job.pid on start, check whether that file exists on the next run, bail if it does. It almost works. Then one run gets kill -9 'd, or the box reboots mid-job, and the PID file is left behind pointing at a process that died on Tuesday. Now every future run sees a "lock" owned by a PID that no longer exists, and the job never runs again — the opposite failure, just as silent. There's also a race between the check and the write, and the times you most need the lock to be clean are exactly the times cleanup didn't happen, because the process died before it could clean up. flock has none of that. The lock isn't a file you create and delete — it's a lock the kernel holds on an open file descriptor , and the kernel releases it automatically the instant that descriptor closes. The process exiting closes it. So does crash

Having spent over 25 years in software development and managing countless Linux environments, I've accumulated a vast collection of custom bash scripts, containers, and CLI tools. Remembering their exact paths and managing them efficiently directly from the terminal is a common challenge. To solve this, I built mytuis . mytuis is a small, attractive terminal UI for managing a personal catalogue of applications. It is built with gum and plain bash, with persistent storage in a human-readable YAML file. GITHUB REPO : https://github.com/horaciod/mytuis Why mytuis? I wanted a tool that didn't require heavy dependencies or a complex setup, but still looked great and provided a smooth user experience. Here is what mytuis brings to the terminal: CRUD operations: You can create, read, update, and delete application entries from a single menu. Quick launch: Pick an app from the filterable list and it is launched immediately. It replaces the manager process via exec, meaning no extra shell window is left behind. Smart path handling: It accepts absolute paths (like /usr/bin/firefox), relative paths (./scripts/myscript.sh), tilde paths (~/bin/foo), or plain command names looked up in your $PATH (firefox). Persistent metadata: Every entry stores its name, description, absolute path, creation date, and last-used date. Friendly TUI: You get clear menus, color-coded messages, and clean borders, all powered by gum. Under the Hood: Plain Text and Standard Utils Simplicity and standard compliance were key goals. mytuis requires bash ≥ 4 and standard Unix utilities like awk, sed, grep, date, and tput. Your catalogue is stored at ~/.mytuis.yaml. Because it is a standard YAML file, it can be inspected, edited, or backed up with any text editor. It is also completely safe to sync with a dotfiles repository or version-control. To ensure data integrity, all file operations are performed atomically by rewriting the YAML file from scratch on every change, so there is no risk of leaving the fi

Bash is the easiest language for AI to write and the easiest language to get devastating output from. A 20-line script that "just cleans up old files" can recursively delete a home directory because the model assumed a variable would always be set. A "simple log shipper" can write your secrets to a remote server because the model used set -x for debugging and forgot to remove it. I have run AI-generated bash that I should not have. Most engineers I know have too. After enough close calls, there's a short checklist that catches the worst of it. This is that checklist. The five things to check before running any AI-generated bash 1. Does it start with a strict pragma? The first lines of any non-trivial bash script should be: #!/usr/bin/env bash set -euo pipefail IFS = $' \n\t ' What each does: set -e — exit on any command failure. Without this, a failure in line 5 doesn't stop the script from happily running lines 6-50. set -u — error on undefined variables. This is the one that saves you from rm -rf $UNDEFINED/ . set -o pipefail — propagate failures through pipes. Without it, failing-command | grep something succeeds because grep succeeds. IFS=$'\n\t' — sane field splitting. Defends against word-splitting bugs in filenames. If the AI-generated script doesn't have these, add them and re-read the script. You'll often discover bugs the pragma now flags. 2. Is every variable expansion quoted? # Wrong rm -rf $TARGET_DIR # Right rm -rf " $TARGET_DIR " The wrong version is what causes the "I deleted the root directory" stories. If $TARGET_DIR is empty or contains a space, the command becomes rm -rf (delete current directory) or rm -rf foo bar (delete two unintended things). Models default to the wrong version about half the time because the right version is harder to write in chat ("escape the quotes!") and the wrong version is what most blogs show. Fix: When reading AI bash, mentally check every $VAR for quotes. Add them if missing. This is the single biggest source of bas

If you are just getting started with Azure CLI and Bash scripting, this post is for you. I will walk you through how I automated the creation of Azure resource groups for multiple environments using a single Bash script — something that was taking a cloud admin several manual steps every week. This is Project 2 in my TechRush Cloud Engineering bootcamp series. If you want to see where this journey started, you can read my previous post where I tackled deploying a web app across two Azure regions for the first time . That project involved real blockers — quota limits, CLI version mismatches, and a deep dive into Azure Resource Providers. This one went smoother, and I think that is because the previous project was the hard school. The Problem Imagine a cloud administrator who has to create five resource groups every single week, one for each active project: Project-A-RG Project-B-RG Project-C-RG Project-D-RG Project-E-RG Every week. By hand. Management's response was simple: automate it. But here is where the task gets more interesting. Instead of creating one flat resource group per project, the better approach is to create four resource groups per project — one for each environment: Dev Test UAT Production This matters because each environment needs its own access controls, cost tracking, and lifecycle rules. You do not want your Development environment sharing a resource group with Production. Keeping them separate is a real-world cloud best practice, not just a bootcamp exercise. What You Will Need Before running this script, make sure you have the following set up: Azure CLI installed on your local machine. You can follow the official installation guide . An active Azure account . A free account works fine for this. A terminal that runs Bash — Linux, macOS, or WSL on Windows. Understanding the Design The core idea behind this script is parameterization . Instead of hardcoding project names, the script accepts a project name as input and uses it as a prefix for ev

The Scenario: The Help Desk Bottleneck From 2019 to 2021, while serving as Lead Backend Software Engineer at a fast-growing company, I occasionally support our Linux System Administration tasks. When the DevOps team encountered a critical bottleneck during an initiative to scale dozens of new server deployments, I stepped in to streamline the infrastructure processes. The DevOps team was being hampered by constant, fragmented requests from the help desk to manually create new Linux accounts for recruits testing the latest application. These interruptions were not only time-consuming but were directly preventing the team from focusing on the high-priority infrastructure deployments that define their core responsibilities. I realized that we weren't just struggling with a task; we were struggling with a scaling bottleneck. To regain the team's focus and ensure we hit our project deadlines, I decided to automate this workflow. The First Step: The Interactive Script My first objective was to develop a robust, automated shell script to efficiently create new Linux user accounts. I started with an interactive Bash script (create-user-interactive.sh) that prompted for input. This was a good educational exercise for learning the fundamentals of Bash—like useradd, passwd, and shell variables. However, I quickly learned that while interactive scripts are great for learning, they are rarely used in professional DevOps environments. Why Manual Scripts Don’t Scale As I transitioned into a more infrastructure-focused role, I realized that manual scripts fail for three key reasons: Lack of Automation: DevOps is about "Infrastructure as Code" (IaC). Asking an engineer to sit at a terminal and type prompts is slow, error-prone, and destroys the ability to automate. Lack of Centralization: In a real team, we aren't creating users on individual local machines. We manage identity across hundreds of servers. Security Risks: Hardcoding passwords or piping them through echo is a major red