CLI

前言：差點對錯誤的 cluster 下指令 某天下午，我在兩個 EKS（Amazon Elastic Kubernetes Service）cluster 之間切換除錯，staging 和 production 的 kubeconfig context 都掛在同一台筆電上。當我打完 kubectl delete deployment 按下 Enter 前的那半秒，我其實不確定自己在哪個 context。那次運氣好，是 staging。 事後檢討，問題不是粗心，是預設的終端機提示字元什麼都不告訴你。user@host ~ % 這行字 20 年來沒變過，但我們的工作環境早就變了：一個人同時面對多個 cluster、多組 AWS 帳號、十幾個專案目錄。工具沒跟上環境，靠的就只剩自律——而自律總有失靈的一天。 這篇文章整理我把終端機全面現代化的過程：六個主力工具，加上一批不用安裝任何東西的原生 shell 技巧。每個工具都回答三個問題：為什麼要換、不換的代價是什麼、以及會踩到哪些坑。 六個升級，按痛點排序 1. starship — 操作 EKS 前，先看一眼提示字元 starship 是用 Rust 寫的跨 shell 提示字元引擎。裝完之後，每行指令前會自動顯示：目前路徑、git 分支與狀態、語言版本，以及對 DevOps 最關鍵的兩個欄位——kubernetes context 和 AWS profile： ~/work/api-server on main via 🐍 v3.11.4 ☸ arn:aws:eks:ap-northeast-1:123456789012:cluster/prod-cluster (default) ❯ 為什麼這樣做？ 防呆的本質是把「需要主動確認的事」變成「被動就會看到的事」。kubectl config current-context 誰都會打，但沒有人會在每一條指令前打一次；提示字元每次都在，你想忽略都難。 ...