Know Your Tools – Terminal and Bash

http://www.spacecowboyrocketcompany.com/2015/02/know-your-tools/

by zan • 11 years ago

64 47 11 years ago

spacecowboyrocketcompany.com

lukabratos• 11 years ago

http://xkcd.com/1168/ ^_^

zan3• 11 years ago

haha exactly! :)

lfowles4• 11 years ago

Lately, all of my tar use has been `tar -xvf filename`. I don't remember it always being the case that those options would automatically gunzip/uncompress, but they do now!

chadzawistowski• 11 years ago

The best mnemonic I've encountered for remembering those flags is visualizing Arnold Schwarzenegger yelling them: "eXtract Ze File!!!"

atmosx• 11 years ago

Hm, what OS? They didn't in the past. You needed to use 'tar -zxvf' for gunzip and 'tar -jxvf' for bzip2 IIRC. I still use it today to wrap files and move them on my server. On the server I use 'lzma' as default compression for archiving files (sql schemas, conf files, etc.)

function_seven• 11 years ago

I forget where I got this from, but this is how I remember it:

    tar -xzf # eXtract Ze Files!

EDIT: I missed chadzawistowski's similar comment below

endur5• 11 years ago

After googling this three separate times I finally just aliased it to an 'untar' command. I'll remember this for when I'm ssh'ed somewhere!

Apofis• 11 years ago

I don't understand why you need options at all... If you point it at a file/directory it should automatically compress and if you point it at an archive it should automatically decompress. The options should be there for advanced tasks not 90% of the tasks you need the app for. It's really poor ui design.

blueblob• 11 years ago

don't type `cd ~` just type `cd`

guruparan183• 11 years ago

Or type `cd ~username` to goto that user's home path

lfowles4• 11 years ago

Also: Accidentally ran `cd`? Run `cd -` to return

I think there are some pop/push mechanics for working directory too, but I can't find them right now.

spike021• 11 years ago

Oh handy! Hadn't come across that before. Thanks.

GauntletWizard• 11 years ago

The commands are pushd and popd, and they're bash (and zsh, and most sane shell) builtins. Pushd to get to a new directory, popd to go back to the last one on the stack.

guruparan183• 11 years ago

Very true. I have difficulties in training new recruits with UNIX. For some reason, beginners have developed an aversion to UNIX/shell scripting. I myself have started more and more of Ruby/AWK/Python, but it is always SHELL that blows me off with the sort of impact it has on the daily work.

I ended up highly optimizing my work environment to replace long ssh connections with `conn prod` (will use my RSA key and connect). File tranfers with `go get prod filename` or `go send prod filename`. Another script that can remember directory paths (I have to go over lot of them every day, and typing long lengthy ones does not help).

To me, UNIX shell scripting is a lazy men's most effective tool, only if you know how to use that rightly.

Loved the post. And thanks much.

codyb• 11 years ago

I'm a relative newbie in the field, but I really love using terminal (I do all my C work for grad school in ViM), it's really essential at work, there's no faster way to do batch file processing a lot of times (especially with ffmpeg, awesome).

I'm surprised people don't like terminal, I love using it. It makes me feel old school, sort of like one of those hackers in the movies. That's probably just a personal thing.

I was familiar with most of the concepts but the links section made things click in that regard. Enjoyed the post as well.

endur5• 11 years ago

It just takes a while to be faster in the terminal than with the gui, and most people won't switch from the thing they're used to until they see significant advantages.

I remember when I first started using the terminal, it was slow and confusing. You had to read the man pages for every little thing. Discovering the command you want is tough, I'd be screwed without the internet.

Now I hate when I need to take my hands of the keyboard to use the mouse. What a waste of time!

madsravn2• 11 years ago

When I was a student programmer, my boss came over to my desk to introduce my new project. He then fired up a terminal, ssh'd into the box where I would find the data. He then presented me the data by doing all kinds of bash magic. I was fairly impressed each time. I used some time just trying to make sense of what he did and how.

It's insanely useful.

zo12• 11 years ago

It's not just UNIX, hey. I come across a lot of programmers that have no idea how to browse the basic command line in windows. I.e. They have no concept of relative paths, browsing through folders, command parameters. It's all incomprehensible "mumbo jumbo" for them.

Which is fine, not everyone has been exposed to it. Eventually, by the fifth time I have to tell them how to move one folder up (Cd ..), I realize that something is very, very wrong.

endur5• 11 years ago

Bash scripts are great if they're yours. My current project has ~20 large bash scripts that do all sorts of different things. They were all written by people who haven't worked on the project for two years. Anyone who needs to make changes there spends far too long trying to figure out what's going on. The scripts could have been written in the same language as the project, and it wouldn't take a whole day to make changes to them.

I think they wrote in Bash to avoid the interpreter startup time. But the scripts are run very infrequently and most of them start/stop long-running services.

That being said, getting a bash script to do the right thing is very satisfying!

warfangle• 11 years ago

Bash scripts for very simple series of commands; higher level scripts for when those sets of commands need logic wrapped 'round 'em. For example: provisioning for packer|vagrant, if you don't need to go overkill with puppet|chef.

halisaurus• 11 years ago

If you didn't know you can put ssh configurations (hosts, ports, keys, etc) in ~/.ssh/config. You can use it in scp like 'scp prod:path/to/file path/to/destination'. Not sure if there's a pro/con to mapping an alias.

guruparan183• 11 years ago

I decided not to use ~/.ssh/config because I wanted the program to be dynamic and record the sessions as I connect for the first time [https://raw.githubusercontent.com/guruparan18/conn/master/co...].

Same case with `scp`, I have bunch of production servers and I have to send/get files from production server all the time. This means, I have to come up with my own one-line command [https://raw.githubusercontent.com/guruparan18/go/master/go]

As I said earlier, to me, UNIX scripting is highly personal. The scripting reflects one's personality. That is why there is not always the right one. There are several way of doing.

kbaker• 11 years ago

To exit vim use <ESC> :wq, not just :wq - most of the problem is it getting stuck in insert mode, and not knowing how to escape into normal mode.

lfowles4• 11 years ago

^C also pops up this helpful dialog (after you've already pressed it once to get to normal mode, but the use case is that you're probably mashing it trying to figure out why you can't exit this crazy editor):

  Type  :quit<Enter>  to exit Vim

chriswarbo• 11 years ago

My first experience of vim was trying to fix my xorg.conf from a tty. I figured out how to save the file, but couldn't exit. In the end I hard-rebooted :$

zo12• 11 years ago

I could never remember that darned syntax. At some point, though, I came across an alternative to it:

shift+z shift+z

I.e. You're in command mode, and essentially type two capital Z letters. It saves your document and quits.

Anywho, it's stuck with me ever since.

babuskov• 11 years ago

Two very basic tips for vi:

You can use slash(/) and question mark(?) to search for text (forward and backward) in vi. It's useful to know these, because they also work with less(1).

If you are Windows user and used to press Ctrl+S to save the file and you accidentally do that in Vi, your terminal would get stuck. But you can use Ctrl+Q to unfreeze it.

madsravn2• 11 years ago

vi move commands works a lot of places in the UNIX world.

bcook• 11 years ago

My most used bash command is probably "sudo !!", which runs the previous command with "sudo" prepended.

The book "Unix Power Tools" showed me that higher-level programming languages (Perl, Python, Ruby, etc) are not needed to accomplish most administrative tasks. Awk is incredibly useful (but also very confusing, imo).

endur5• 11 years ago

I really like '!$' and '!:1' in bash. '!$' holds the last argument of the last command and '!:n' holds the nth argument.

$ cd /big/long/path/to/this.txt Oops $ vim !$

458QxfC2z3• 11 years ago

If using readline (emacs) keybindings, press Alt and period for the same effect as !$.

DougMerritt• 11 years ago

It should be noted for onlookers that this is the abbreviated form; !-3:4 goes back to the third-to-last command and refers to its fourth argument, and similarly !-3:$ is its last argument.

It's also apparently not universally known that bash has csh-style (similar to sed) editing, so "s^foo^bar" will repeat the previous command with "bar" substituted at for bar. So "ls foo" becomes "ls bar".

Similarly with !-3:s^foo^bar

I freely mix these things with readline-editing, depending on what needs to be done.

Since csh gets a lot of disrespect these days, to give credit where due: these are all Bill Joy features from the original csh -- it's a good thing that bash borrowed innovations from various shells beyond Bourne shell and ksh.

Historical footnote: We donated code to him to do readline-style editing circa 1978, but he said raw mode was bogging down the pdp 11 too much. Systems were a bit slower back then.

tieTYT• 11 years ago

This is probably misunderstanding the demographic, but why does he suggest using nano over vim?

tensorproduct2• 11 years ago

Maybe they just prefer nano?

More likely, if this is meant to be a gentle introduction to the command line, vim is a pretty scary place. Nano works much more like a "normal" text editor.

endur5• 11 years ago

Until you want to undo something! Nano is definitely more user-friendly though. Some of the engineers I work with still don't know basic vim shortcuts, like 'w' and 'b'

zan3• 11 years ago

knowing my demographic, that's what they prefer. If anyone wants to use vim, I point them to the vim person.

throw7• 11 years ago

1. I like tab-completion, but I can't personally stand bash's completion feature. Be aware of differences.

2. If you want to save your command without running it... comment it out with a '#'. Bang, it's in your history.

tensorproduct2• 11 years ago

The first thing I do on any bash terminal is `set -o vi`. This changes the default keybindings from emacs-like to vi-like. I find it to be a huge booster to my speed in navigating the command line.

edit: Actually, something cool I learned recently is that if you put the line "set editing-mode vi" in your ~/.inputrc then vi-like editing keys are available in any program that uses readline. This includes bash and the python repl. Presumably, a bunch of other repls and interactive command lines too.

wolfhumble• 11 years ago

How do you typically go to e.g. beginning/end of line; via insert or normal mode and which key combinations do you prefer? Always been using ctrl+a and ctrl+e in emacs mode myself . . .

voidhorse• 11 years ago

I love playing around in bash. Most of the scripts I have right now are just for setting up project templates, adding common packages etc.

Actually, I think most people who use computers at work, be they writers, designers, whatever, not just programmers, would benefit from learning some bash (or batch). You can automate a lot of useful processes with a few simple scripts.

nicksuperb• 11 years ago

"Fact of life is, as you spend time in the terminal, you're probably going to launch Vim at some point, whether willingly or not... For all other intents and purposes, just friggin use nano. Or sublime."

Words to live by.

zan3• 11 years ago

Thanks guys, I'll collect these thoughts and add them to the blogpost. After all, I want this to be available to all and every one of us!

olalonde• 11 years ago

Tip: I recently looked up the man page for "which" and found out about the -a flag which will list all instances of the executable found (instead of just the first one). Incredibly useful when you have multiple installations of the same software and it's causing problems. e.g.:

    $ which -a ruby
    /Users/olalonde/.rbenv/shims/ruby
    /usr/local/bin/ruby
    /usr/bin/ruby

Know Your Tools – Terminal and Bash

Related Stories