Hacker News Reader

Comment by bitwize | Hacker News Reader

I don't want my terminal badassified; I want to get work done. Rather than bling out my command prompt I simply try to do what real developer, data, and sysadmin badasses do:

* Learn your shell language -- really learn it. Learn how to fit programs together, how to manage jobs, and all of the control structures in your shell language. Avail yourself of aliases and shell functions.

* Learn the Unix command set, sed, and awk. Practice using these tools to do complex data or textual manipulation tasks.

* Make a personal ~/bin directory and add it to your $PATH. Put shell scripts that do useful things in there.

* Learn enough of a real programming language such as C or Python to write small programs to do common things that would be slow or cumbersome to do in shell. Put them in your ~/bin.

There, you'll be Unixing like a boss with a minimum of prompt ricing.

View on HN

Agreed with everything you list here. I do think it's valuable to learn how to pretty-up and polish the shell prompt. I've set mine up to display the time as well as the exit status of the previous command, along with the usual tidbits of user, host, and cwd.

In terms of languages to learn, the most important is your shell, generally bash for most people. 99% of the time, bash is Fast Enough, even though it can often be very slow. Bash is incredibly ugly, but using its features and the userland tools that are standard on most Unices, you can do a lot of amazing things relatively easily.

For speedy programs, Perl can't be beat. For text manipulation, even C programs sometimes run slower than Perl and generally require more code and are much harder to maintain. Perl is nearly as ugly as Bash and has even more annoyances, but for raw text-processing throughput there's no competition.

Right, sure - but you definitely - well, probably ;) - still want iTerm2!

For Linux, try terminator: http://gnometerminator.blogspot.co.uk/p/introduction.html , or your package manager. There are doubtless tons of other options.

Why do you definitely still want iTerm2?

The only feature that I find even remotely compelling is mouse support, but so few programs handle mouse input that it largely doesn't matter. People always mention split panes, but I've never had a desire to vertically split my terminal window. If I ever did have such a desire, I'd probably just use tmux. And yes, iTerm2 claims to have some form of tmux integration, but I believe that's basically just using iTerm2 split panes to represent tmux panes, and I don't get why that's any better than just using tmux directly.

So besides mouse support and split panes, what does iTerm2 offer that Terminal.app doesn't? Some of the answers I've heard in the past are "256 colors" and "color themes", both of which Terminal.app supports.

I've tried using iTerm2's tmux support and found it to actually be less friendly than just using tmux directly. Definitely a YMMV thing, I suppose, but I was seriously baffled.

One thing I heard from several people in a previous discussion is that iTerm2 makes a thin outline around the terminal window and since they often have overlapping terminal windows (that are presumably opaque with black backgrounds), Terminal wasn't as usable. This has changed with Yosemite's Terminal, though.

Huh, I never noticed the very thin outline around Terminal windows in Yosemite. Neat. I've been using a slightly-transparent dark background with blur for years (which gets slightly more transparent for background windows). That always made it really easy to visually distinguish overlapping windows. But I can see the border being useful for people who have completely opaque windows (with black backgrounds).

I use split panes all the time. Never got on with terminal multiplexers myself. Other stuff I like about iTerm2:

- configurable word boundaries for word selection by mouse

- X-style copy/paste (middle click to paste current selection)

- dabbrev-style word completion from current buffer, though I've not ended up finding this as useful as it seems it should be

But if you don't value any of this, then maybe you don't want it? Let me edit my post to fix this.

Thanks for the response. But yeah, none of that sounds like things I'd want. Especially X-style copy/paste, I'm really glad Terminal.app doesn't do that (although interestingly, middle-click actually does paste the OS clipboard, but there's no auto-copy of selected text).

I don't use a Mac, and on Linux I use plain xterm. Does the job, is fast, and you can spawn a lot of them cheaply. Arranging them is easy with a tiling wm.

all of your bullet points are excellent advice, but:

having timestamps in my prompts has helped me straighten out what I did to get myself into a situation across a few different windows of a tmux session.

having all nonzero return codes show up automatically because of tweaking my oh-my-zsh configuration has definitely saved me time here and there.

root on my machines looks completely different visually compared to my regular user account(s) and this has stopped me from doing dumb things as root, again, while bouncing around in a tmux session.

I've done all of the above, and I've blinged out my prompt. They're not mutually exclusive :)

Using the world's most common shell in a standard configuration comes with benefits, too. Incredible portability of your code & experience.

Plus shells that try to be too smart or do too much always break, leaving you debugging your shell. Shoot me now.

"X's that try to be too smart or do too much always break, leaving you debugging your X" is, based on my observations, a true statement for values of X equal to ANY core system component: package manager, init system, build system, etc.

Agreed.

I would add 'grep' in there as an absolute must have.

The sed, grep, awk holy trinity will allow you to do pretty much any type of text manipulation and searching that you can imagine.

I have one more that I like. I call it 'rex' and it basically allows me to do a regex substitution on command line text (not stdin, but actual command line args). It mostly comes in handy when looping over files in a directory where I want to do some kind of processing based on information in the file name. For example, I can tag all of the episodes of a podcast with their track numbers (several podcasts I listen to don't do id3tags) with this command:

    for f in *.mp3; 
      do id3v2 -T `rex 's/^[^0-9]*([0-9]+).*\.mp3$/\1/` $f; 
    done

The script itself is really simple, but I can post the source if anybody's interested.

Reply on news.ycombinator.com