Add shebang to bash code blocks

Author: webstackdev

_TODO.md

@@ -243,6 +243,8 @@ See comp images in Breadcrumbs component directory
 
 - Newsletter component "home" and "page" variants needs work on spacing, "home" needs image added
 
+- Determine if any of the python code blocks should have `#!/bin/python` added
+
 ## Header
 
 - Need to improve the "squish" animation where the header reduces in size on scroll down, and returns to full size on scroll up. Maybe reduce and expand the text and search / themepicker / hamburger menu sizes in place, and then slide them horizontally.

src/content/articles/argocd-sync-failures-gitops-debugging-troubleshooting/index.mdx

@@ -98,6 +98,8 @@ When sync fails, resist the urge to poke at random things. A systematic approach
 Start broad and narrow down:
 
 ```bash title="debug-argocd-sync.sh"
+#!/bin/bash
+
 # Get application status overview
 argocd app get myapp
 
@@ -124,6 +126,8 @@ The `--show-operation` flag shows which phase the sync is in. "Running PreSync h
 ArgoCD has several components, each handling different parts:
 
 ```bash title="check-argocd-logs.sh"
+#!/bin/bash
+
 # Application controller logs (sync decisions, health checks)
 kubectl logs -n argocd -l app.kubernetes.io/name=argocd-application-controller | grep "myapp"
 
@@ -139,6 +143,8 @@ Most sync failures show up in application-controller logs. If you're seeing "man
 ArgoCD reports what Kubernetes tells it. Verify what's actually happening:
 
 ```bash title="inspect-kubernetes-state.sh"
+#!/bin/bash
+
 # Check pod status and events
 kubectl get pods -n myapp
 kubectl describe pod -n myapp -l app=myapp
@@ -155,6 +161,8 @@ The `kubectl describe` Events section is often the most useful—it shows why po
 ArgoCD provides options for testing before committing:
 
 ```bash title="test-argocd-fix.sh"
+#!/bin/bash
+
 # Dry-run to see what would happen
 argocd app sync myapp --dry-run
 

src/content/articles/argocd-sync-failures-gitops-debugging-troubleshooting/pdf.mdx

@@ -226,6 +226,8 @@ When a dependency is missing, pods fail to start with characteristic error messa
 The fix is usually straightforward: put the dependency in an earlier sync wave. But first you need to identify which dependency is missing:
 
 ```bash title="debug-dependency-failure.sh"
+#!/bin/bash
+
 # Check what secrets a deployment needs
 kubectl get deployment app -o jsonpath='{.spec.template.spec.containers[*].envFrom[*].secretRef.name}'
 
@@ -402,6 +404,8 @@ Now that you understand _what_ can fail, let's talk about _how_ to investigate w
 Start broad and narrow down. The ArgoCD CLI gives you a quick overview of what's happening:
 
 ```bash title="debug-step-1.sh"
+#!/bin/bash
+
 # Get application status overview
 argocd app get myapp
 
@@ -425,6 +429,8 @@ The `--show-operation` flag shows the current or last sync operation, including
 Once you know roughly where the failure is, check the logs for the relevant ArgoCD component. ArgoCD has several pods, and each handles different parts of the sync process:
 
 ```bash title="debug-step-2.sh"
+#!/bin/bash
+
 # ArgoCD application controller logs (sync decisions)
 kubectl logs -n argocd -l app.kubernetes.io/name=argocd-application-controller -f
 
@@ -455,6 +461,8 @@ Most sync failures show up in the application-controller logs. If your issue is
 ArgoCD's view of the world comes from Kubernetes, so when ArgoCD reports a problem, verify what's actually happening in the cluster. Sometimes ArgoCD's status is stale, or the problem is a Kubernetes issue that ArgoCD is just reporting.
 
 ```bash title="debug-step-3.sh"
+#!/bin/bash
+
 # Check deployment rollout status
 kubectl rollout status deployment/app -n myapp
 
@@ -480,6 +488,8 @@ The `kubectl describe` output for pods is often the most useful. Look at the Eve
 Once you understand the failure, you need to fix it and verify the fix works. ArgoCD provides several options for testing changes before committing them:
 
 ```bash title="debug-step-4.sh"
+#!/bin/bash
+
 # Dry-run sync to see what would happen
 argocd app sync myapp --dry-run
 
@@ -899,6 +909,8 @@ ArgoCD doesn't deploy your YAML files directly—it renders them through Helm, K
 The most common surprise is values resolution in Helm. ArgoCD might be using different values files than you're testing locally, or environment-specific overrides might not be applied in the order you expect.
 
 ```bash title="debug-manifest-generation.sh"
+#!/bin/bash
+
 # See what ArgoCD generates from your repo
 argocd app manifests myapp
 
@@ -927,6 +939,8 @@ The `argocd app manifests` command is your friend here—it shows you exactly wh
 Sometimes ArgoCD's internal state becomes inconsistent with reality. This can happen after failed upgrades, network partitions, or manual resource modifications that confuse the controller. The symptoms vary—perpetual OutOfSync, missing resources in the UI, or sync operations that silently do nothing.
 
 ```bash title="recovery-commands.sh"
+#!/bin/bash
+
 # Step 1: Try this first - force refresh from Git
 argocd app get myapp --hard-refresh
 

src/content/articles/database-schema-migrations-continuous-deployment-zero-downtime/pdf.mdx

@@ -473,6 +473,8 @@ What makes gh-ost particularly useful in production: you can pause and resume mi
 Here's a typical gh-ost invocation for adding a column:
 
 ```bash title="gh-ost-example.sh"
+#!/bin/bash
+
 # Add column to large MySQL table without locking
 
 gh-ost \

src/content/articles/eol-runtime-upgrade-dependency-hell-migration/pdf.mdx

@@ -95,6 +95,8 @@ The diagram shows a typical pattern: three direct dependencies fan out to ten tr
 Your first step is making this hidden graph visible. Every package manager provides tooling to dump the full tree and trace why a particular package exists in your dependency graph.
 
 ```bash title="visualizing-dependency-depth.sh"
+#!/bin/bash
+
 # npm: Show full dependency tree
 npm ls --all
 
@@ -218,6 +220,8 @@ Web Forms deserves special mention. There is no migration path. If your applicat
 Microsoft provides tooling to help analyze and automate parts of the migration. The .NET Upgrade Assistant scans your solution, identifies incompatibilities, and can perform some automated transformations.
 
 ```bash title="dotnet-upgrade-assistant.sh"
+#!/bin/bash
+
 # Install the .NET Upgrade Assistant
 dotnet tool install -g upgrade-assistant
 
@@ -274,6 +278,8 @@ Native modules are compiled C++ addons that link against Node's internal APIs. W
 The first step is identifying which packages in your dependency tree include native code. Any package with a `.node` file in its build output is a native module.
 
 ```bash title="find-native-modules.sh"
+#!/bin/bash
+
 # List all native modules in your project
 find node_modules -name "*.node" -type f 2>/dev/null | \
   sed 's|node_modules/||' | \
@@ -492,6 +498,8 @@ Overrides change _which version_ is installed. Patches change _the code itself_
 The `patch-package` tool for npm/yarn makes this workflow practical:
 
 ```bash title="patch-workflow.sh"
+#!/bin/bash
+
 # Install the tool
 npm install patch-package --save-dev
 

src/content/articles/helm-release-management-drift-detection-debugging/index.mdx

@@ -59,6 +59,8 @@ The best time to discover drift is during business hours, not during an incident
 Install it and run it against your releases:
 
 ```bash title="drift-check.sh"
+#!/bin/bash
+
 # Install the helm-diff plugin
 helm plugin install https://github.com/databus23/helm-diff
 

src/content/articles/helm-release-management-drift-detection-debugging/pdf.mdx

@@ -122,6 +122,8 @@ Knowing drift happens isn't enough—you need to catch it before it causes probl
 The `helm-diff` plugin is the quickest way to compare Helm's view against cluster reality. It shows what would change on an upgrade, but more importantly for drift detection, it can compare the current release against live state.
 
 ```bash title="drift-check.sh"
+#!/bin/bash
+
 # Install the plugin once
 helm plugin install https://github.com/databus23/helm-diff
 
@@ -334,6 +336,8 @@ _Rolling namespace upgrades_ work well for multi-tenant deployments where each n
 For zero-downtime requirements on stateless services, you can run two releases side-by-side:
 
 ```bash
+#!/bin/bash
+
 # Deploy new version as separate release
 helm install my-app-v2 ./my-chart \
   --namespace production \

src/content/articles/kubernetes-cluster-upgrade-playbook-risk-reduction/pdf.mdx

@@ -46,6 +46,8 @@ _Cluster health_ establishes your baseline. All nodes should show Ready status.
 _Backup and recovery_ is your safety net. Take an etcd snapshot before starting. Document current cluster state with `kubectl get all -A -o yaml`. Most importantly, document and _test_ your rollback procedure in a non-production environment before you need it.
 
 ```bash
+#!/bin/bash
+
 # Take etcd backup before upgrade (kubeadm clusters)
 etcdctl snapshot save /backup/etcd-pre-upgrade-$(date +%Y%m%d).db \
   --endpoints=https://127.0.0.1:2379 \
@@ -148,6 +150,8 @@ _Phase 3: Add-ons_ (15-30 minutes). Upgrade cluster add-ons to versions compatib
 _Phase 4: Worker nodes_ (10-15 minutes per node). For each worker node: cordon it (prevent new pod scheduling), drain it (evict existing pods), upgrade the kubelet, then uncordon it. Verify the node shows Ready before moving to the next one.
 
 ```bash
+#!/bin/bash
+
 # Worker node upgrade sequence
 NODE="worker-1"
 kubectl cordon $NODE
@@ -230,6 +234,8 @@ For production clusters, I recommend blue-green node pools. The sequence:
 7. If healthy, delete the old pool. If not, uncordon the old pool and delete the new one.
 
 ```bash title="blue-green-node-pool.sh"
+#!/bin/bash
+
 # Blue-green node pool upgrade for EKS
 OLD_POOL="workers-1-28"
 NEW_POOL="workers-1-29"
@@ -270,6 +276,8 @@ Control plane rollback is the nuclear option. It's disruptive, risky, and should
 For self-managed clusters (kubeadm), rollback means restoring from the etcd backup you took before upgrading. This is why that backup isn't optional.
 
 ```bash title="etcd-restore.sh"
+#!/bin/bash
+
 # Stop all control plane components
 systemctl stop kube-apiserver kube-controller-manager kube-scheduler etcd
 
@@ -376,6 +384,8 @@ I organize post-upgrade checks into five categories, run in order of criticality
 _Infrastructure checks_ verify the cluster itself is healthy. All nodes should be Ready, control plane components should show healthy status, and the API server should respond quickly. These are blocking - don't proceed if any fail.
 
 ```bash
+#!/bin/bash
+
 # Infrastructure validation
 echo "=== Infrastructure Checks ==="
 

src/content/articles/kubernetes-dns-debugging-ndots-coredns-troubleshooting/index.mdx

@@ -63,6 +63,8 @@ Before optimizing, confirm that ndots is actually your problem. The diagnostic t
 First, launch a debug pod with DNS tools:
 
 ```bash title="launch-debug-pod.sh"
+#!/bin/bash
+
 kubectl run dns-debug --image=nicolaka/netshoot --rm -it --restart=Never -- bash
 ```
 
@@ -71,6 +73,8 @@ Code: Launch a debug pod with DNS tools.
 Once inside the pod, compare resolution times with and without the trailing dot:
 
 ```bash title="ndots-diagnostic.sh"
+#!/bin/bash
+
 # Test without trailing dot (search domains applied)
 time nslookup api.stripe.com
 

src/content/articles/kubernetes-dns-debugging-ndots-coredns-troubleshooting/pdf.mdx

@@ -90,6 +90,8 @@ The key components work together: every pod gets a `/etc/resolv.conf` that point
 Every debugging session should start by examining the pod's DNS configuration. The `resolv.conf` file tells you exactly which nameserver the pod uses, which search domains get appended, and crucially, the ndots setting that controls when those search domains apply.
 
 ```bash title="examining-resolv-conf.sh"
+#!/bin/bash
+
 # Examine DNS configuration in a pod
 kubectl exec -it debug-pod -- cat /etc/resolv.conf
 # Output:
@@ -195,6 +197,8 @@ The difference between `ndots:5` and `ndots:2` for an external API call is three
 Before optimizing, measure the actual impact in your cluster. The difference between `nslookup api.stripe.com` and `nslookup api.stripe.com.` tells you exactly how much overhead the search domains add.
 
 ```bash title="launch-debug-pod.sh"
+#!/bin/bash
+
 # Spin up a debug pod with DNS tools
 kubectl run dns-debug --image=nicolaka/netshoot --rm -it --restart=Never -- bash
 ```
@@ -204,6 +208,8 @@ Code: Launch a debug pod with DNS tools.
 Once you're inside the pod, compare resolution times with and without the trailing dot:
 
 ```bash title="measure-ndots-inside-pod.sh"
+#!/bin/bash
+
 # Compare resolution times
 echo "Without trailing dot (search domains applied):"
 time nslookup api.stripe.com
@@ -415,6 +421,8 @@ When DNS breaks, you need a systematic approach that quickly narrows down the pr
 Start by verifying the DNS infrastructure is healthy, then test from a pod to isolate pod-level versus cluster-level issues.
 
 ```bash title="dns-quick-check.sh"
+#!/bin/bash
+
 # Step 1: Is CoreDNS running?
 kubectl get pods -n kube-system -l k8s-app=kube-dns
 kubectl get endpoints -n kube-system kube-dns
@@ -432,6 +440,8 @@ Code: Quick CoreDNS health check.
 Once you've verified CoreDNS is running, test from inside a pod. This is critical because node-level DNS and pod-level DNS are configured differently.
 
 ```bash title="launch-dns-debug-pod.sh"
+#!/bin/bash
+
 # Spin up a debug pod with DNS tools
 kubectl run dns-debug --image=nicolaka/netshoot --rm -it --restart=Never -- bash
 ```
@@ -441,6 +451,8 @@ Code: Launch a debug pod.
 Once inside the pod, run through this diagnostic sequence:
 
 ```bash title="dns-diagnostic-sequence.sh"
+#!/bin/bash
+
 cat /etc/resolv.conf                    # Check DNS config
 nslookup kubernetes.default             # Test internal DNS
 nslookup google.com                     # Test external DNS