터미널 꾸미기: 당신만의 셸을 공유해 주세요!

Text settings Story text Size Small Standard Large Width * Standard Wide Links Standard Orange * Subscribers only Learn more Minimize to nav I spend more time today than ever before interacting with terminal windows, which is something I don’t think Past Me would have believed in the early ’90s. Back then, poor MS-DOS was the staid whipping boy of the industry, and at least on the consumer side, graphical environments like Windows (and maybe even odder creatures like AmigaOS ) seemed poised to stamp the command line into oblivion, leaving text interfaces behind as we all blasted into the ooey-GUI future. As it turns out, though, the command line is still the best tool for some jobs—many jobs, in fact. I read a wise post some years ago (probably on Slashdot) arguing that a mouse-driven point-and-click interface essentially reduces the user to pointing at something on the screen and grunting, “DO! DO THAT!” at the computer. (The rise of right-click context menus adds the ability for the user to also grunt “MORE THINGS!” but doesn’t otherwise add vocabulary.) The command line, by contrast, gives the user the opportunity to precisely tell the computer what they want done, using words instead of one or two gestalts that the computer must interpret based on context. It sounds kind of silly to say it, but the command line is what finally dragged me off Windows as my daily driver back in 2007. At the time, I’d been forced into regular bash usage at work as I took over the day-to-day administration of Boeing Houston’s fleet of then-brand-new EMC Celerra NSX enterprise NAS appliances , and while there were GUI management options available (I am perhaps triggering trauma in a small subset of older readers by saying the words “EMC Control Center”), the environment I’d inherited was firmly held together by bash scripts. At first, I had turned up my nose at the Linux-ness of it all, but kind of like the fungus in The Last of Us , the shell’s tendrils slowly infected my brain. I began to realize that sad old cmd.exe and MS-DOS batch files really were kind of terrible, and that maybe, just maybe , the Linux-y ravings of my angry graybeard sysadmin mentor were not as crazy as they seemed. I didn’t think I’d ever arrive at his method of only running manually compiled Slackware —and, indeed, 20 years on, I’m still not even close—but the guy had a point. The more I used a Unix-y shell at work, the more I began to miss it at home. Windows Vista and its early WDDM woes had reduced my previously badass main PC with two Nvidia 7900GT cards in SLI to a stuttering BSOD-spitting mess, and the future of Microsoft OSes looked bleak—Windows 7 wouldn’t be along to change the situation for years. Exposure therapy to the bash shell brought me to the tipping point, and I jumped ship to the Macintosh side of the house. It was a move calculated to give me the best of all possible worlds—a good graphical interface with the same bash shell under the hood that I’d come to depend on at work. The before… Lee Hutchinson The before… Lee Hutchinson …and the after. Lee Hutchinson …and the after. Lee Hutchinson The before… Lee Hutchinson …and the after. Lee Hutchinson I haven’t looked back. These days, I run three different operating systems at home. MacOS is still my daily driver on the desktop; Windows lives on the gaming PC in the corner; and Linux (in the form of Ubuntu server LTS) is headless in the closet, where it belongs. God is in his heaven, and all is right with my computing world—and still, as with every day since sometime in early 2007, I spend at least an hour or two with a terminal window doing things the old-fashioned, text-y way. The fish shell long ago became my default on my Mac, in no small part because I like fish’s colors and find them helpful (don’t judge me!). When I’m logged into Linux, though, I stick with good old bash. I know zsh and other modern alternatives have their fans, but I’ve found my happy place, and I’m content to stay there. Being a child of the BBS era , when ANSI graphics were the hotness, I have spent about as much time as any other terminal-enjoying admin customizing my environment and making it into a place where I feel comfy working. … Oh God, I’m doing it. I’m doing the thing they do on recipe sites where all the reader really wants is directions for making pecan pie but instead gets a giant personal backstory. Forgive me. I’m old. Let’s get to the pie, and by pie, I mean the screenshots and code! My favorite thing: The terminal timer It’s incredibly handy, at least for me, to have an easy-to-see reference of how long the last command took to run. (You don’t need that kind of thing until you need it, and then you often really need it.) To that end, I have some functions living in my .bashrc file that time each command and then append that time—and the last error code emitted—to the next bash prompt. In practice, it looks like this: I dig this. Coupled with printing the current time as part of the prompt, it gives you a good idea of not just how long the last few commands took to run but also when you were running them. That’s very handy for absentminded admins (/me raises hand) who leave terminal sessions up for days at a time with important work sitting in them. Here’s the code to make this happen, which you should feel free to adapt to your needs. As noted, I keep this in .bashrc as part of my PS1 prompt statement: color_prompt=yes if [ "$color_prompt" = yes ]; then _TIMER_FILE="/tmp/.bash_timer_${$}" function _timer_record_start { date +%s%N > "$_TIMER_FILE" } function timer_stop { if [[ ! -f "$_TIMER_FILE" ]]; then timer_show=0us return fi local timer_start timer_start=$(< "$_TIMER_FILE") rm -f "$_TIMER_FILE" local delta_us=$((($(date +%s%N) - timer_start) / 1000)) local us=$((delta_us % 1000)) local ms=$(((delta_us / 1000) % 1000)) local s=$(((delta_us / 1000000) % 60)) local m=$(((delta_us / 60000000) % 60)) local h=$((delta_us / 3600000000)) # Goal: always show around 3 digits of accuracy if ((h > 0)); then timer_show=${h}h${m}m elif ((m > 0)); then timer_show=${m}m${s}s elif ((s >= 10)); then timer_show=${s}.$((ms / 100))s elif ((s > 0)); then timer_show=${s}.$(printf %03d $ms)s elif ((ms >= 100)); then timer_show=${ms}ms elif ((ms > 0)); then timer_show=${ms}.$((us / 100))ms else timer_show=${us}us fi } PS0='$(_timer_record_start)' #Prompt and prompt colors function set_prompt { local Last_Command=${1:-$?} FancyX='\342\234\227' Checkmark='\342\234\223' export PS1="\n$WHITE[\t] " if [[ $Last_Command == 0 ]]; then PS1+="\$? $GREEN$Checkmark " else PS1+="\$? $RED$FancyX " fi timer_stop PS1+="$WHITE($timer_show)" PS1+="\n\[$HOSTCOLOR\]\u@\h\[$WHITE\]:\[$BLUEBOLD\]\w\[$WHITE\] \\$ " } function timer_prompt_command { local last_command=$? set_prompt "$last_command" } PROMPT_COMMAND='timer_prompt_command' fi This mess of functions will jam all that goodness into your prompt, complete with a fancy green “check” if the program exited with error code 0 or a red “X” and the error code if it exited with something else. The color definitions— $WHITE , $BLUEBOLD , $HOSTCOLOR , and others—are just plain ol’ ANSI escape sequences defined elsewhere in .bashrc and not presented here to try to keep the code excerpts from being too long. You can and should replace them with whatever tickles your fancy. The timer_stop function also has the job of converting the timer into a human-readable format, and it’s probably messier than it needs to be. I’m no developer, though, so this is what Past Lee settled on after a few hours of searching through examples. Doing it in fish for folks like me That’s for bash when I’m ssh’d into one of my Linux hosts, but I run fish on MacOS. I have a separate fish function for getting the same results there, complete with gross hacks for turning the measurement into human-readable form. I made this code, and I am unapologetic. Witness my cobbled-together StackOverflow-sourced kludge. function fish_prompt --description 'Write out the