6 ms·

Ask HN: how did you learn the command line?

27 points by lakeeffect 14y ago

Is there a great book or online tutorial for all things command line?

nostrademons 14y ago
My Windows laptop was outta commission for a few weeks in college. I could use the public computer labs to do my homework, but the only way I could do any programming was to SSH into remote UNIX boxes that I had access to and write the code directly on the server. (I was doing mostly PHP development at the time, and had laboriously setup PHP/Apache/MySQL on my Windows box until it died.) When your only window into the world is an SSH terminal, you pick up the command line and vim fairly quickly.
OafTobark 14y ago
If you're new, start here: http://cli.learncodethehardway.org/book/ http://cli.learncodethehardway.org/book/
ColinWright 14y ago
I came to answer your question and say that when I started computing there was only the command line - there were no windows, effectively no graphics, and the only thing you could do was type commands. But then you ask if there are tutorials, and that I can't help you with. Having said that, I tried this search: http://www.google.co.uk/search?q=command+line+tutorial http://www.google.co.uk/search?q=command+line+tutorial and I got lots of hits, including these: * http://www.davidbaumgold.com/tutorials/command-line/ http://www.davidbaumgold.com/tutorials/command-line/ * http://stackoverflow.com/questions/8170/best-windows-command-line-tutorial-for-beginners http://stackoverflow.com/questions/8170/best-windows-command... * http://www.tuxfiles.org/linuxhelp/cli.html http://www.tuxfiles.org/linuxhelp/cli.html I'm not a beginner on the command line, so I can't assess how well they meet your needs.
- ableal 14y ago
  What he said. It seemed a good idea at the time, considering that, back then, the alternative to a CLI on a 80x24 monochrome terminal were decks of punch cards, featuring 30-60 minutes turnaround time, with output on greenbar paper. Besides, VMS had a pretty nice "help" command. Barely had to crack open any of the orange binders in the 10 feet or so shelf of manuals. (For entertainment purposes only. Do not attempt this at home. Get off my lawn ;-)
- nonamegiven 14y ago
  Me too, that's all there was. And that may be the answer: only allow yourself the command line for longer and longer periods of time. Force yourself to learn it. I really like this book, even today: http://shop.oreilly.com/product/9780596003302.do http://shop.oreilly.com/product/9780596003302.do The key to being proficient at the command line (as distinct from writing shell scripts) is to think of it as composition. For example, run this: $ file $(which $(man -k python | cut --delimiter " " --fields 1)) (The first '$' is your command line prompt, yours may differ; you don't type that. The other '$' characters you do type.) Now run each command from the inside out, starting with the man command. See what each command does. Build it up bit by bit, that's exactly what I did, like this: - the man command - the man command piped into the cut command - the man command piped into the cut command after reading "man cut" to remember about the --delimiter option - the output of that pipeline fed to which - the output of which fed to file Note that I didn't use any for loops or variables, the shell did the right thing for me. Read the man pages for each of those commands. set -o vi or set -o emacs (or their equivalent in .inputrc) helps a lot when you compose things incrementally. esc-k k k (etc) is your friend if you set -o vi. Read man bash. It will take you a long time. For today, read the section on READLINE. While in man bash, search for the word READLINE at the front of the line, like this: /^READLINE Slash = search ^ = anchor the search to the front of the line READLINE = what you're searching for in the current man page. For now, all you need in your ~/.inputrc file is: set editing-mode vi This will give you vi command line editing in bash, as well as any other program that uses readline, like the python REPL. For more info on .inputrc, $ man readline which is documentation for the C interface to readline, but is mostly about how readline is used by a user. For example, in man readline /VI Mode bindings gives you all your command line editing commands when you use vi mode. Get a mostly table of contents of man bash, for your searching pleasure: $ man -P cat bash |egrep -v "^ " |egrep -o "^[^ ]+" Sort it: $ man -P cat bash |egrep -v "^ " |egrep -o "^[^ ]+" |sort
  - nonamegiven 14y ago
    And ... I realized/remembered while reading the other comments that knowing what's available is a necessary part of "just use the command line a lot." So try this, to get a good list of what's available (and for more command line composition) $ man -k $(ls -1 /usr/bin |egrep -v "\[") 2>&1 |egrep -v "nothing appropriate" See if you can figure out what 2>&1 does (it's a very common idiom, probably easy to find), and figure out why it's needed here. That's a long list of stuff, look at it a page at a time: $ man -k $(ls -1 /usr/bin |egrep -v "\[") 2>&1 |egrep -v "nothing appropriate" |less That's still a lot of stuff, save it off in a file in your home directory for later: $ man -k $(ls -1 /usr/bin |egrep -v "\[") 2>&1 |egrep -v "nothing appropriate" > ~/wholelottacommands.txt
Jach 14y ago
I didn't really learn or rely upon much of the command line until I went through the process of installing Gentoo Linux[1] from a minimal CD. [1] http://www.gentoo.org/ http://www.gentoo.org/
Achshar 14y ago
I am not a command line pro either but whatever limited experience i have came from working from mercurial and from college unix lectures. I would suggest you incorporate command line in some of your routine work (source control for example).
Kluny 14y ago
I think I first got into it when I was trying to get some sort of video to play in QuickTime - since then I've switched to VLC, cause I didn't have much luck. Then I started doing Learn Python the Hard Way, which taught me the easy stuff like ls, cd, rm, and so on. Then I had a course in Linux Systems Administration, where I had no choice but to master it as fast as possible.
canadev 14y ago
I started in DOS watching over my brother's shoulder. (There was no GUI back then.) I used to make batch files and such. Eventually I grew to love bash. I am sure there are plenty of keyboard shortcuts I don't know, but I find using the command line to be quicker than any other form of communicating with the computer. I use keyboard shortcuts in Firefox, and occasionally dream of an Awesome Bar that works like bash. I also really like using the 'move-cursor-a-word-left/right' and 'move-cursor-to-end/beginning-of-line' and 'move-cursor-to-top/bottom-of-textarea' functions you can find in almost every GUI. Finally, I use Spotlight to load all my applications: I hit cmd-space and then it's usually 1 key to load my most commonly used applications, and generally 3-4 in worst case. My suggestion: use the Terminal for everything: Learn to edit text files in emacs or vi, use a command line SQL browser, do source control from the command line, and learn sed, awk, and cut (plenty of tutorials out there). Use the keyboard in the browser and in GUI textareas as much as possible. Here is a neat site which has turned up in a few of my Google searches: http://www.commandlinefu.com/commands/browse http://www.commandlinefu.com/commands/browse Finally, shameless self-plug, I have been using this simple piece of code every day for a couple of years, a command-line (tab-completed) notebook for bash: https://github.com/nchelluri/notes https://github.com/nchelluri/notes . HTH. Edit: I keep looking at this page every few months, but it never seems to be compatible with my version of Firefox: http://paulrouget.com/e/jsterm/ http://paulrouget.com/e/jsterm/ :(
- protospork 14y ago
  >I use keyboard shortcuts in Firefox, and occasionally dream of an Awesome Bar that works like bash. This reminded me to check up on Ubiquity[1]. Mozilla doesn't even host a page for it anymore, but apparently someone adopted it[2]. I'm going to have to play around with this tomorrow; I'll be happy if it's half as useful as I remember. [1]: https://en.wikipedia.org/wiki/Ubiquity_%28Firefox%29 https://en.wikipedia.org/wiki/Ubiquity_%28Firefox%29 [2]: https://bitbucket.org/satyr/ubiquity/overview https://bitbucket.org/satyr/ubiquity/overview
justplay 14y ago
thanks to HN who provide me this[1] link . It is awesome and contain many useful information . [1]:http://cb.vu/unixtoolbox.xhtml http://cb.vu/unixtoolbox.xhtml
klrr 14y ago
$ man man # best way to start I could also recommend TUPE[1], it teaches you how to effectively use the command line and write shell scripts. 1. The Unix Programming Environment by Brian Kernighan and Rob Pike.
secos 14y ago
I started with DOS 4.01, and a DOS manual. I went command by command, until I got to format "hey, we have a lot of files, it would be nice to have them formatted..." That day I learned about OS installation as well. And then continued.
picomancer 14y ago
Once upon a time (c. 1990-1997), most programs were written for DOS, and some amount of command line knowledge was required to run them. Installers were typically batch files (the DOS equivalent of shell scripts), which was really cool: You could see exactly what they were doing [1], and you could improve your command-line-fu by seeing the techniques people used [2]. [1] Usually it was just copying the application files from directory to directory. Nowadays installers generally muck with the Registry, C:\Progra~1 [3], C:\Users\Applic~1 [3], the Desktop (who knows where that is), the Start Menu, and the Windows equivalent of /etc/init.d (I remember there are several of them, and your system will get slower...and...slow...er...if you don't clean them out regularly) [2] Like environment variables or @ECHO OFF. [3] Spaces in filenames need to die. Whenever possible I use the 8-character names Windows generates for backwards compatibility with DOS.
crynix 14y ago
I learned the command line by using the command line. When I switched to Arch Linux, using bash was inevitable. It took many Google queries and reading many man pages to finally become comfortable in it.
mr_penguin 14y ago
Found this on HN - excellent starting point / read: http://linuxcommand.org/tlcl.php http://linuxcommand.org/tlcl.php
venusaur 14y ago
I learnt by immersing myself in the command line - needing to get stuff done is the perfect catalyst.
antm 14y ago
Peepcode has a great set of quality, affordable, screencasts. I went through them both and they helped a ton. https://peepcode.com/products/meet-the-command-line https://peepcode.com/products/meet-the-command-line https://peepcode.com/products/advanced-command-line https://peepcode.com/products/advanced-command-line Experimentation is another good option, and goes a long way, but it can be scary. If you're at all worried about doing permanent damage, install a virtual machine (i.e. VirtualBox + the server version of Ubuntu or whatever OS you want). That way you can experiment away without fear of doing permanent damage. If it happens just trash the the VM and start again.
sciencerobot 14y ago
Trying to get Wi-Fi to work on Ubuntu
pajju 14y ago
The best way to learn is by doing and using it often. Don't read, use it often! There must be a strong reason to learn, and don't just learn for the sake of learning! I have been using Linux daily, its around 5+ yrs. I play around with numerous VPS remote boxes and still I'm learning, but everyday getting better at it. This way, it should only get better and better over time! The more you use in your daily workflows, the more you appreciate and understand the internals too. And there are no other shortcuts to learn command line tools. Courses or short tutorials won't help much. You have to involve command line tools in your daily workflow's. Its a long term process, so keep learning, improving and don't ever stop!
- deleted 14y ago
  [deleted]
IvyMike 14y ago
I was on a gigantic Sequent machine with hundreds of users at UIUC. When I got my account, I given a user agreement paper with rules and regulations that, at the very bottom, had a dozen or so commands on it. There were some very terse and cryptic descriptions. ("cd: change directory; man: read a manual page; ps: print running processes; grep: search for a string") Eventually I bootstrapped my way up to doing "ps -augx" to see what other people were running. Then I would try whatever they were doing.
quarterto 14y ago
I remember at age five being taught by my dad how to run DOS games. Type 'cd ' and press tab. 'cd' is like clicking on a folder.
- oneweekwonder 14y ago
  Exactly the same for me, before I could read, write or speak english. My dad gave me a list of commands. It was a bit hard to get out of the station in police quest and only years later did I understand why my dad didn't want to help me to get into this game where a "man" is floating from left to right and you need to answer a question to play.
chacham15 14y ago
I dont know about other people, but I learned based upon need. I needed to be able to manage files so I learned cd,mv,cp,ls. Then I needed to write the output to files so I learned about piping and the redirect operator. Then I needed to search through the output so I learned grep, etc.
Moto7451 14y ago
The hard slow way over the course of a few years. If I did it over again I'd buy books on bash, grep, sed, etc and learn it in one shot.
trumbitta2 14y ago
I can say how I started: In 1997, a friend of mine came to visit, installed Debian 2.0 on my 486 with a unsupported Intel i740 videocard, showed me how to log in, 'man -k <something>' and 'man man', then said "See ya next week, have fun". And I had.
attheodo 14y ago
Ultimately, the best and proper way to be a console master is to install a Unix distribution on your one and only everyday machine and avoid any sorts of X or Window manager at all.
wging 14y ago
Know how to get help with specific topics. (1) At the terminal, via man <command> or apropos <command> and (2) online by googling. These are useful when you have a specific task you want to get done, not so much otherwise. Therefore, (3) Try to do things at the command line that you would normally do via mouse. If you have no idea how, google or 'apropos'. If you learn of a tool and have no idea how to use it, google more or 'man'. (3a) Do the simple stuff via the CLI--removing and moving files, examining directory contents, et cetera. (Be careful with rm! It will not warn you by default.) (3b) More complex stuff too--try editing text with a terminal editor. Many people swear by emacs and vim. They have learning curves of their own but they are worth it. Pick one. (4) Pipes and input redirection. Send the output of one command as the input to another, send the output to a file, etc. This is where your standard Unix shell gets really powerful.
- canadev 14y ago
  apropos is a great command. Just learned about that one a few weeks ago. Turns out it's a synonym for "man -k".
asveikau 14y ago
The first computer my family owned was an IBM PC XT, which was my introduction to the concept of a command line interface being normal. I do wonder what it'll be like for the generation of potential hacker types who won't even remember a world before slick iOS UIs and ubiquitous internet in your pocket. Computers were a kind of source of wonder for me in my childhood, and what I see from young children today is they view them as very mundane, which I suspect hurts their curiosity. Years detached from those experiences with the XT, I picked up Linux in the late 90s. It was a bit of a learning curve from DOS. But I picked up some very dated book at the local library about Unix and it kind of set me straight. The real revolution in my thinking came in 2001, when I was unfortunate enough to buy a motherboard with an ALI 1647 chipset (it's sad that I have brain cells devoted to remembering that model number). That chipset, when combined with an NVIDIA video card, would make X crash and lock up after about 30 minutes of use (before you start bashing on Linux, I'd been told the same thing would happen on Windows with this hardware combination). For six months months I was in denial of this problem. I kept thinking the next BIOS update or the next driver would fix the problem. In the meantime I used nothing but console mode, because it was the only thing that was stable. Six months or so later I sold the old motherboard, paid my quarter to get myself a "real motherboard" (ok, it was more like USD$200), and got X working again. It was good and all to have a GUI again but one thing I did notice was that my command line skills were much improved.
NateDad 14y ago
Everyone's assuming the poster means Linux, but he didn't actually specify. Lots of things have command line interfaces. What command line are you actually talking about?
- wging 14y ago
  Much of this advice is applicable to any Unix. For instance 'man man' is good advice on a Mac, too.
tingletech 14y ago
I learned from commands written on chalk boards in computer labs (during the days when all over campus were rooms of green or amber screened terminals that were open 24 hours). Then one day I saw and typed 'man man' 'apropos' was also written on the board that day
appplemac 14y ago
When I was 16, I got my first VPS box. The hoster only offered SSH connection, so the shell was the only way to proceed. Spent half a year without knowing about '&' and 'nohup' and 'Ctrl-Z', but learned what patience actually is. Then watched the video course on Vim by Derek Wyatt. There's a small book about shell by Zed Shaw, recommended: http://cli.learncodethehardway.org/book/ http://cli.learncodethehardway.org/book/
ebobster 14y ago
My solution isn't the easiest because it requires a lot of discipline but it you force yourself to stick to it you will come to dominate the command line. Everytime I wanted to do something in the command line as well as everytime I had to do something in it, I would then write down what the command was in a text file as well as my understand of what the command did. If you program a keyboard shortcut to launch the text file with but one keystroke it's a not as bad as it sounds. The reason I did this was because I would always enter a command and totally forget it and then need to look it up again and so I forced myself to stop wasting time by compiling my own command line glossary. If you are new to UNIX, don't go poking around the MAN pages because you'll be lost, discouraged and less likely to acheive your goal of terminal excellency. It's really not something you can just pickup overnight unless you're very very diligent and proficient with another language and very familiar with all things computers. If you can take a Unix course some where in person, do that. always the best to have a pro help you out while you're starting. And one last point of particular importance. Respect the Sudo. I can't tell you how much frustration I endured while messing with the sudo--it's not a good thing to be bushwhacking no the command like as the root user which I did at first because I am just a curious kid and didn't know any better. My advice is to abstain from messing with things like the ACL, file ownership, and the wheel group until you know the hierarchy cold.
oinksoft 14y ago
The greatest obstacle for me was knowing which tools did what. Many things I wanted to do in the shell I did not know were possible, and even Google is of limited value when your query is necessarily vague, though this has gotten a whole lot better in recent years. Have an IRC connection to Freenode open so you can ask about these sorts of things that are more easily understood by humans (#bash, ##linux, ##workingset are good channels to be in). If you're really lucky, you have some knowledgeable mentor around who doesn't mind you asking them about the best way to perform some task (I was not so blessed).
sixofhearts 14y ago
I bought a couple of Sam's Teach Yourself books: -Sam's Teach Yourself Unix in 24 Hours -Sam's Teach Yourself Shell Programming in 24 Hours These won't make you a shell genius immediately, but they'll create a good basis for future, specialized learning. Also, I try not to be a material snob, but buying the book instead of using a website or .pdf file made a world of a difference (especially during a morning commute).
bubujka 14y ago
my way: life without file managers. ls, cp, mv, mkdir, rm, find, grep... and vim, vim, vim =)
BariumBlue 14y ago
I seem to be one of the few people to have learned from a class. Over a semester, I learned all the important commands, and commands I probably have otherwise learned, like uniq -c, dmesg, or cut (although I can't imagine ever actually using awk), as well as the bash scripting language and syntax.
madao 14y ago
Seriously use it or lose it, it's really that simple when you don't know what you need to do just check out the man pages or,google your little heart out.
cheeseprocedure 14y ago
I cut my Linux teeth on Gentoo stage 1 and 2 installs, which I found enormously frustrating and equally educational. Today, I'd recommend working through Linux From Scratch. You'll develop a rich understanding of how a UNIX-like OS fits together, including a fair bit of shell functionality: http://www.linuxfromscratch.org/lfs/ http://www.linuxfromscratch.org/lfs/ My favourite dead-tree UNIX book would be UNIX Power Tools, 3rd Edition (http://www.amazon.com/Power-Tools-Third-Shelley-Powers/dp/0596003307 http://www.amazon.com/Power-Tools-Third-Shelley-Powers/dp/05...). It may be a while before it's a truly valuable resource, but keep it in mind.
Tichy 14y ago
This xkcd cartoon on tar might be comforting: http://xkcd.com/1168/ http://xkcd.com/1168/
gosu 14y ago
Like others here, I learned simply by doing and fumbling my way around until I was comfortable. That said, I think the most important thing for you to learn is how to get help. Learn how to find man(ual) pages, and how to interpret the very precise language and syntax that programmer-authors like to use. Then try reading the man pages of the systems that you want to learn - like 'man bash'. Also, some tools have nicer pages accessible via the 'info' command, so try 'info emacs'. That'll generally be the best way to learn how to use any tool. The only trick past that is to learn which tools exist, and google/stackoverflow will usually suggest appropriate tools when you tell it precisely which problem you want to solve.
bitwize 14y ago
I learned Unix on my dad's Tandy Model 16 machine -- one of the first commercially available Unix micros (along with the Sun Workstation). XENIX (Microsoft's Unix) came with a program called "learn" which was a tutorial. It would show you how to do something, then give you a goal and drop you into a mock shell. Most of the commands had their usual effects inside the mock shell, but you could always quit the lesson and restart if you screwed up. That's how I picked up the basics. When I discovered Unix machines -- and Linux -- on my university campus some eleven years later, all the old skills translated and I learned some new ones along the way.
tunesmith 14y ago
I think that in order to learn the command line, you have to immediately develop a different goal that requires proficient use of the command line. That way it'll force you to learn by doing. Command line is not one of those self-contained "deep" knowledge bases where everything links together. It's broad, shallow, unlinked - the concepts and practices do not always imply themselves. For bodies of knowledge that fit that pattern, you have to learn by doing - you can't simply derive the knowledge through study and thought. And the best way to learn by doing is to immediately apply it to something useful.
bdunbar 14y ago
How did _I_ learn the command line? By doing. Some reading, sure, but .. more doing than thinking. Like this; I was a brand-new programmer (COBOL). The Marines assigned me to a billet in the LAN team at my new command. A corporal wrote down exactly what to type on the computer after the NIC was installed. After that, I was off and running.
dps 14y ago
I learned mostly thru trial and error with Linux as a teenager, but during my CS degree this course filled in some missing gaps:http://www.cl.cam.ac.uk/teaching/2005/UnixTools/ http://www.cl.cam.ac.uk/teaching/2005/UnixTools/
DrinkWater 14y ago
must have been 1999/2000. My boss made me, the ultimate noob, the "administrator" of a Solaris Box. I didn't know SHIT! absolutely NOTHING. I was just a dumb Windows User. There was just this blinking cursor (that motherfucker) and me. i browsed the web and had to look up stuff like "cd" and "ls". Steep learning curve, i guess, but nothing teaches you better than "trial and error". Funny sidenote: Not only was i totally overwhelmed with all the commands and quirks of the command line, but the web always mentioned vim as THE editor for Unix. So i also started messing around with the most obscure editor on this planet. These were rough times for me, but i have learned so much, and i am thankful for that.
talleyrand 14y ago
Like everything else. Google.
jkmcf 14y ago
Find a mentor or an irc chatroom. My sophomore roommate knew a ton. I annoyed him to no end w/ questions (many RTFM comments…). A lot of the commands aren't named obviously, though the 'apropos' command may help.
dgunn 14y ago
What is it you want to do? Just learn or do something with it? You won't learn something like that by reading. You have to actually use a terminal to accomplish things. Often. Start using linux and develop something. You'll use about 3 terminal instances all the time. That's the way to learn.
uslic001 14y ago
This is a good book: http://www.amazon.com/gp/product/013308504X/ref=oh_details_o01_s00_i00?ie=UTF8&psc=1 http://www.amazon.com/gp/product/013308504X/ref=oh_details_o...
codemonkeymike 14y ago
Download linux on your computer(Mint or Ubuntu id recommend). Then look up the basic commands and use them (ls, cd ...). Then move on to making your own aliases(search up 'making bash aliases'). By this point you can now start trying some more advanced things like having aliases which start up programs and open your project folders(search up 'dotfiles bash'). Lastly learning some shell script can help you better understand and utilize the terminal(as you can write complex shell scripts for your aliases). As a side note using vim(or emacs) as your default text editor will keep you in the terminal longer helping you get used to using it.
presty 14y ago
> how did you learn the command line? I grew up with it
lutusp 14y ago
> Ask HN: how did you learn the command line? I had no choice -- for most of my computing career, there wasn't anything else. in fact, when I first got into computing, I would have sold my left arm to gain access to a command line interface. When I see a typical modern command line (a shell session), it's enclosed in a separate window, and I'm reminded how far we've come in a short time. Before I had access to a terminal, I was writing programs anyway -- http://arachnoid.com/programmable_calculators http://arachnoid.com/programmable_calculators -- and my first terminal's output (while working for NASA in the early 1970s) was a roll of paper. So that's my answer -- I had no choice. Oh, p.s., here's my Bash tutorial: http://arachnoid.com/linux/shell_programming.html http://arachnoid.com/linux/shell_programming.html
bowietrousers 14y ago
In 1995, all we had at university had was a bunch of SunOS & HP-UX workstations. Yes, they had X, mwm and (later) CDE, but you just had to learn the command line to do anything particularly useful. Man pages, a few of the IT service's leaflets (How to use troff/LaTeX), searching the web (Altavista! Dogpile! Webcrawler!) and asking in Usenet groups when I hit a real roadblock. I started building small shell scripts out of need to automate some things, and learned about the shell environment and the overall Unix philosophy doing that. This was over a period of years rather than weeks or months - I probably can't say that I was proficient on the CLI until around 1999 when I really started getting stuck into Linux and building everything from scratch. I find that young developers today expect to learn everything immediately, expecting a one-true-way to wisdom, rather than accepting that true mastery seeps in over time, largely through doing and getting things wrong. So, experiment, and don't give up when you can't figure out something immediately.

27 points by lakeeffect 14y ago

Is there a great book or online tutorial for all things command line?

My Windows laptop was outta commission for a few weeks in college. I could use the public computer labs to do my homework, but the only way I could do any programming was to SSH into remote UNIX boxes that I had access to and write the code directly on the server. (I was doing mostly PHP development at the time, and had laboriously setup PHP/Apache/MySQL on my Windows box until it died.) When your only window into the world is an SSH terminal, you pick up the command line and vim fairly quickly.

OafTobark 14y ago

If you're new, start here: http://cli.learncodethehardway.org/book/ http://cli.learncodethehardway.org/book/

ColinWright 14y ago

I came to answer your question and say that when I started computing there was only the command line - there were no windows, effectively no graphics, and the only thing you could do was type commands. But then you ask if there are tutorials, and that I can't help you with. Having said that, I tried this search: http://www.google.co.uk/search?q=command+line+tutorial http://www.google.co.uk/search?q=command+line+tutorial and I got lots of hits, including these: * http://www.davidbaumgold.com/tutorials/command-line/ http://www.davidbaumgold.com/tutorials/command-line/ * http://stackoverflow.com/questions/8170/best-windows-command-line-tutorial-for-beginners http://stackoverflow.com/questions/8170/best-windows-command... * http://www.tuxfiles.org/linuxhelp/cli.html http://www.tuxfiles.org/linuxhelp/cli.html I'm not a beginner on the command line, so I can't assess how well they meet your needs.

ableal 14y ago
What he said. It seemed a good idea at the time, considering that, back then, the alternative to a CLI on a 80x24 monochrome terminal were decks of punch cards, featuring 30-60 minutes turnaround time, with output on greenbar paper. Besides, VMS had a pretty nice "help" command. Barely had to crack open any of the orange binders in the 10 feet or so shelf of manuals. (For entertainment purposes only. Do not attempt this at home. Get off my lawn ;-)
nonamegiven 14y ago
Me too, that's all there was. And that may be the answer: only allow yourself the command line for longer and longer periods of time. Force yourself to learn it. I really like this book, even today: http://shop.oreilly.com/product/9780596003302.do http://shop.oreilly.com/product/9780596003302.do The key to being proficient at the command line (as distinct from writing shell scripts) is to think of it as composition. For example, run this: $ file $(which $(man -k python | cut --delimiter " " --fields 1)) (The first '$' is your command line prompt, yours may differ; you don't type that. The other '$' characters you do type.) Now run each command from the inside out, starting with the man command. See what each command does. Build it up bit by bit, that's exactly what I did, like this: - the man command - the man command piped into the cut command - the man command piped into the cut command after reading "man cut" to remember about the --delimiter option - the output of that pipeline fed to which - the output of which fed to file Note that I didn't use any for loops or variables, the shell did the right thing for me. Read the man pages for each of those commands. set -o vi or set -o emacs (or their equivalent in .inputrc) helps a lot when you compose things incrementally. esc-k k k (etc) is your friend if you set -o vi. Read man bash. It will take you a long time. For today, read the section on READLINE. While in man bash, search for the word READLINE at the front of the line, like this: /^READLINE Slash = search ^ = anchor the search to the front of the line READLINE = what you're searching for in the current man page. For now, all you need in your ~/.inputrc file is: set editing-mode vi This will give you vi command line editing in bash, as well as any other program that uses readline, like the python REPL. For more info on .inputrc, $ man readline which is documentation for the C interface to readline, but is mostly about how readline is used by a user. For example, in man readline /VI Mode bindings gives you all your command line editing commands when you use vi mode. Get a mostly table of contents of man bash, for your searching pleasure: $ man -P cat bash |egrep -v "^ " |egrep -o "^[^ ]+" Sort it: $ man -P cat bash |egrep -v "^ " |egrep -o "^[^ ]+" |sort
- nonamegiven 14y ago
  And ... I realized/remembered while reading the other comments that knowing what's available is a necessary part of "just use the command line a lot." So try this, to get a good list of what's available (and for more command line composition) $ man -k $(ls -1 /usr/bin |egrep -v "\[") 2>&1 |egrep -v "nothing appropriate" See if you can figure out what 2>&1 does (it's a very common idiom, probably easy to find), and figure out why it's needed here. That's a long list of stuff, look at it a page at a time: $ man -k $(ls -1 /usr/bin |egrep -v "\[") 2>&1 |egrep -v "nothing appropriate" |less That's still a lot of stuff, save it off in a file in your home directory for later: $ man -k $(ls -1 /usr/bin |egrep -v "\[") 2>&1 |egrep -v "nothing appropriate" > ~/wholelottacommands.txt

Jach 14y ago

I didn't really learn or rely upon much of the command line until I went through the process of installing Gentoo Linux[1] from a minimal CD. [1] http://www.gentoo.org/ http://www.gentoo.org/

Achshar 14y ago

I am not a command line pro either but whatever limited experience i have came from working from mercurial and from college unix lectures. I would suggest you incorporate command line in some of your routine work (source control for example).

Kluny 14y ago

I think I first got into it when I was trying to get some sort of video to play in QuickTime - since then I've switched to VLC, cause I didn't have much luck. Then I started doing Learn Python the Hard Way, which taught me the easy stuff like ls, cd, rm, and so on. Then I had a course in Linux Systems Administration, where I had no choice but to master it as fast as possible.

canadev 14y ago

I started in DOS watching over my brother's shoulder. (There was no GUI back then.) I used to make batch files and such. Eventually I grew to love bash. I am sure there are plenty of keyboard shortcuts I don't know, but I find using the command line to be quicker than any other form of communicating with the computer. I use keyboard shortcuts in Firefox, and occasionally dream of an Awesome Bar that works like bash. I also really like using the 'move-cursor-a-word-left/right' and 'move-cursor-to-end/beginning-of-line' and 'move-cursor-to-top/bottom-of-textarea' functions you can find in almost every GUI. Finally, I use Spotlight to load all my applications: I hit cmd-space and then it's usually 1 key to load my most commonly used applications, and generally 3-4 in worst case. My suggestion: use the Terminal for everything: Learn to edit text files in emacs or vi, use a command line SQL browser, do source control from the command line, and learn sed, awk, and cut (plenty of tutorials out there). Use the keyboard in the browser and in GUI textareas as much as possible. Here is a neat site which has turned up in a few of my Google searches: http://www.commandlinefu.com/commands/browse http://www.commandlinefu.com/commands/browse Finally, shameless self-plug, I have been using this simple piece of code every day for a couple of years, a command-line (tab-completed) notebook for bash: https://github.com/nchelluri/notes https://github.com/nchelluri/notes . HTH. Edit: I keep looking at this page every few months, but it never seems to be compatible with my version of Firefox: http://paulrouget.com/e/jsterm/ http://paulrouget.com/e/jsterm/ :(

protospork 14y ago
>I use keyboard shortcuts in Firefox, and occasionally dream of an Awesome Bar that works like bash. This reminded me to check up on Ubiquity[1]. Mozilla doesn't even host a page for it anymore, but apparently someone adopted it[2]. I'm going to have to play around with this tomorrow; I'll be happy if it's half as useful as I remember. [1]: https://en.wikipedia.org/wiki/Ubiquity_%28Firefox%29 https://en.wikipedia.org/wiki/Ubiquity_%28Firefox%29 [2]: https://bitbucket.org/satyr/ubiquity/overview https://bitbucket.org/satyr/ubiquity/overview

justplay 14y ago

thanks to HN who provide me this[1] link . It is awesome and contain many useful information . [1]:http://cb.vu/unixtoolbox.xhtml http://cb.vu/unixtoolbox.xhtml

klrr 14y ago

$ man man # best way to start I could also recommend TUPE[1], it teaches you how to effectively use the command line and write shell scripts. 1. The Unix Programming Environment by Brian Kernighan and Rob Pike.

secos 14y ago

I started with DOS 4.01, and a DOS manual. I went command by command, until I got to format "hey, we have a lot of files, it would be nice to have them formatted..." That day I learned about OS installation as well. And then continued.

picomancer 14y ago

Once upon a time (c. 1990-1997), most programs were written for DOS, and some amount of command line knowledge was required to run them. Installers were typically batch files (the DOS equivalent of shell scripts), which was really cool: You could see exactly what they were doing [1], and you could improve your command-line-fu by seeing the techniques people used [2]. [1] Usually it was just copying the application files from directory to directory. Nowadays installers generally muck with the Registry, C:\Progra~1 [3], C:\Users\Applic~1 [3], the Desktop (who knows where that is), the Start Menu, and the Windows equivalent of /etc/init.d (I remember there are several of them, and your system will get slower...and...slow...er...if you don't clean them out regularly) [2] Like environment variables or @ECHO OFF. [3] Spaces in filenames need to die. Whenever possible I use the 8-character names Windows generates for backwards compatibility with DOS.

crynix 14y ago

I learned the command line by using the command line. When I switched to Arch Linux, using bash was inevitable. It took many Google queries and reading many man pages to finally become comfortable in it.

mr_penguin 14y ago

Found this on HN - excellent starting point / read: http://linuxcommand.org/tlcl.php http://linuxcommand.org/tlcl.php

venusaur 14y ago

I learnt by immersing myself in the command line - needing to get stuff done is the perfect catalyst.

antm 14y ago

Peepcode has a great set of quality, affordable, screencasts. I went through them both and they helped a ton. https://peepcode.com/products/meet-the-command-line https://peepcode.com/products/meet-the-command-line https://peepcode.com/products/advanced-command-line https://peepcode.com/products/advanced-command-line Experimentation is another good option, and goes a long way, but it can be scary. If you're at all worried about doing permanent damage, install a virtual machine (i.e. VirtualBox + the server version of Ubuntu or whatever OS you want). That way you can experiment away without fear of doing permanent damage. If it happens just trash the the VM and start again.

sciencerobot 14y ago

Trying to get Wi-Fi to work on Ubuntu

pajju 14y ago

The best way to learn is by doing and using it often. Don't read, use it often! There must be a strong reason to learn, and don't just learn for the sake of learning! I have been using Linux daily, its around 5+ yrs. I play around with numerous VPS remote boxes and still I'm learning, but everyday getting better at it. This way, it should only get better and better over time! The more you use in your daily workflows, the more you appreciate and understand the internals too. And there are no other shortcuts to learn command line tools. Courses or short tutorials won't help much. You have to involve command line tools in your daily workflow's. Its a long term process, so keep learning, improving and don't ever stop!

deleted 14y ago
[deleted]

IvyMike 14y ago

I was on a gigantic Sequent machine with hundreds of users at UIUC. When I got my account, I given a user agreement paper with rules and regulations that, at the very bottom, had a dozen or so commands on it. There were some very terse and cryptic descriptions. ("cd: change directory; man: read a manual page; ps: print running processes; grep: search for a string") Eventually I bootstrapped my way up to doing "ps -augx" to see what other people were running. Then I would try whatever they were doing.

quarterto 14y ago

I remember at age five being taught by my dad how to run DOS games. Type 'cd ' and press tab. 'cd' is like clicking on a folder.

oneweekwonder 14y ago
Exactly the same for me, before I could read, write or speak english. My dad gave me a list of commands. It was a bit hard to get out of the station in police quest and only years later did I understand why my dad didn't want to help me to get into this game where a "man" is floating from left to right and you need to answer a question to play.

chacham15 14y ago

I dont know about other people, but I learned based upon need. I needed to be able to manage files so I learned cd,mv,cp,ls. Then I needed to write the output to files so I learned about piping and the redirect operator. Then I needed to search through the output so I learned grep, etc.

Moto7451 14y ago

The hard slow way over the course of a few years. If I did it over again I'd buy books on bash, grep, sed, etc and learn it in one shot.

trumbitta2 14y ago

I can say how I started: In 1997, a friend of mine came to visit, installed Debian 2.0 on my 486 with a unsupported Intel i740 videocard, showed me how to log in, 'man -k <something>' and 'man man', then said "See ya next week, have fun". And I had.

attheodo 14y ago

Ultimately, the best and proper way to be a console master is to install a Unix distribution on your one and only everyday machine and avoid any sorts of X or Window manager at all.

wging 14y ago

Know how to get help with specific topics. (1) At the terminal, via man <command> or apropos <command> and (2) online by googling. These are useful when you have a specific task you want to get done, not so much otherwise. Therefore, (3) Try to do things at the command line that you would normally do via mouse. If you have no idea how, google or 'apropos'. If you learn of a tool and have no idea how to use it, google more or 'man'. (3a) Do the simple stuff via the CLI--removing and moving files, examining directory contents, et cetera. (Be careful with rm! It will not warn you by default.) (3b) More complex stuff too--try editing text with a terminal editor. Many people swear by emacs and vim. They have learning curves of their own but they are worth it. Pick one. (4) Pipes and input redirection. Send the output of one command as the input to another, send the output to a file, etc. This is where your standard Unix shell gets really powerful.

canadev 14y ago
apropos is a great command. Just learned about that one a few weeks ago. Turns out it's a synonym for "man -k".

asveikau 14y ago

The first computer my family owned was an IBM PC XT, which was my introduction to the concept of a command line interface being normal. I do wonder what it'll be like for the generation of potential hacker types who won't even remember a world before slick iOS UIs and ubiquitous internet in your pocket. Computers were a kind of source of wonder for me in my childhood, and what I see from young children today is they view them as very mundane, which I suspect hurts their curiosity. Years detached from those experiences with the XT, I picked up Linux in the late 90s. It was a bit of a learning curve from DOS. But I picked up some very dated book at the local library about Unix and it kind of set me straight. The real revolution in my thinking came in 2001, when I was unfortunate enough to buy a motherboard with an ALI 1647 chipset (it's sad that I have brain cells devoted to remembering that model number). That chipset, when combined with an NVIDIA video card, would make X crash and lock up after about 30 minutes of use (before you start bashing on Linux, I'd been told the same thing would happen on Windows with this hardware combination). For six months months I was in denial of this problem. I kept thinking the next BIOS update or the next driver would fix the problem. In the meantime I used nothing but console mode, because it was the only thing that was stable. Six months or so later I sold the old motherboard, paid my quarter to get myself a "real motherboard" (ok, it was more like USD$200), and got X working again. It was good and all to have a GUI again but one thing I did notice was that my command line skills were much improved.

NateDad 14y ago

Everyone's assuming the poster means Linux, but he didn't actually specify. Lots of things have command line interfaces. What command line are you actually talking about?

wging 14y ago
Much of this advice is applicable to any Unix. For instance 'man man' is good advice on a Mac, too.

tingletech 14y ago

I learned from commands written on chalk boards in computer labs (during the days when all over campus were rooms of green or amber screened terminals that were open 24 hours). Then one day I saw and typed 'man man' 'apropos' was also written on the board that day

appplemac 14y ago

When I was 16, I got my first VPS box. The hoster only offered SSH connection, so the shell was the only way to proceed. Spent half a year without knowing about '&' and 'nohup' and 'Ctrl-Z', but learned what patience actually is. Then watched the video course on Vim by Derek Wyatt. There's a small book about shell by Zed Shaw, recommended: http://cli.learncodethehardway.org/book/ http://cli.learncodethehardway.org/book/

ebobster 14y ago

My solution isn't the easiest because it requires a lot of discipline but it you force yourself to stick to it you will come to dominate the command line. Everytime I wanted to do something in the command line as well as everytime I had to do something in it, I would then write down what the command was in a text file as well as my understand of what the command did. If you program a keyboard shortcut to launch the text file with but one keystroke it's a not as bad as it sounds. The reason I did this was because I would always enter a command and totally forget it and then need to look it up again and so I forced myself to stop wasting time by compiling my own command line glossary. If you are new to UNIX, don't go poking around the MAN pages because you'll be lost, discouraged and less likely to acheive your goal of terminal excellency. It's really not something you can just pickup overnight unless you're very very diligent and proficient with another language and very familiar with all things computers. If you can take a Unix course some where in person, do that. always the best to have a pro help you out while you're starting. And one last point of particular importance. Respect the Sudo. I can't tell you how much frustration I endured while messing with the sudo--it's not a good thing to be bushwhacking no the command like as the root user which I did at first because I am just a curious kid and didn't know any better. My advice is to abstain from messing with things like the ACL, file ownership, and the wheel group until you know the hierarchy cold.

oinksoft 14y ago

The greatest obstacle for me was knowing which tools did what. Many things I wanted to do in the shell I did not know were possible, and even Google is of limited value when your query is necessarily vague, though this has gotten a whole lot better in recent years. Have an IRC connection to Freenode open so you can ask about these sorts of things that are more easily understood by humans (#bash, ##linux, ##workingset are good channels to be in). If you're really lucky, you have some knowledgeable mentor around who doesn't mind you asking them about the best way to perform some task (I was not so blessed).

sixofhearts 14y ago

I bought a couple of Sam's Teach Yourself books: -Sam's Teach Yourself Unix in 24 Hours -Sam's Teach Yourself Shell Programming in 24 Hours These won't make you a shell genius immediately, but they'll create a good basis for future, specialized learning. Also, I try not to be a material snob, but buying the book instead of using a website or .pdf file made a world of a difference (especially during a morning commute).

bubujka 14y ago

my way: life without file managers. ls, cp, mv, mkdir, rm, find, grep... and vim, vim, vim =)

BariumBlue 14y ago

I seem to be one of the few people to have learned from a class. Over a semester, I learned all the important commands, and commands I probably have otherwise learned, like uniq -c, dmesg, or cut (although I can't imagine ever actually using awk), as well as the bash scripting language and syntax.

madao 14y ago

Seriously use it or lose it, it's really that simple when you don't know what you need to do just check out the man pages or,google your little heart out.

cheeseprocedure 14y ago

I cut my Linux teeth on Gentoo stage 1 and 2 installs, which I found enormously frustrating and equally educational. Today, I'd recommend working through Linux From Scratch. You'll develop a rich understanding of how a UNIX-like OS fits together, including a fair bit of shell functionality: http://www.linuxfromscratch.org/lfs/ http://www.linuxfromscratch.org/lfs/ My favourite dead-tree UNIX book would be UNIX Power Tools, 3rd Edition (http://www.amazon.com/Power-Tools-Third-Shelley-Powers/dp/0596003307 http://www.amazon.com/Power-Tools-Third-Shelley-Powers/dp/05...). It may be a while before it's a truly valuable resource, but keep it in mind.

Tichy 14y ago

This xkcd cartoon on tar might be comforting: http://xkcd.com/1168/ http://xkcd.com/1168/

gosu 14y ago

Like others here, I learned simply by doing and fumbling my way around until I was comfortable. That said, I think the most important thing for you to learn is how to get help. Learn how to find man(ual) pages, and how to interpret the very precise language and syntax that programmer-authors like to use. Then try reading the man pages of the systems that you want to learn - like 'man bash'. Also, some tools have nicer pages accessible via the 'info' command, so try 'info emacs'. That'll generally be the best way to learn how to use any tool. The only trick past that is to learn which tools exist, and google/stackoverflow will usually suggest appropriate tools when you tell it precisely which problem you want to solve.

bitwize 14y ago

I learned Unix on my dad's Tandy Model 16 machine -- one of the first commercially available Unix micros (along with the Sun Workstation). XENIX (Microsoft's Unix) came with a program called "learn" which was a tutorial. It would show you how to do something, then give you a goal and drop you into a mock shell. Most of the commands had their usual effects inside the mock shell, but you could always quit the lesson and restart if you screwed up. That's how I picked up the basics. When I discovered Unix machines -- and Linux -- on my university campus some eleven years later, all the old skills translated and I learned some new ones along the way.

tunesmith 14y ago

I think that in order to learn the command line, you have to immediately develop a different goal that requires proficient use of the command line. That way it'll force you to learn by doing. Command line is not one of those self-contained "deep" knowledge bases where everything links together. It's broad, shallow, unlinked - the concepts and practices do not always imply themselves. For bodies of knowledge that fit that pattern, you have to learn by doing - you can't simply derive the knowledge through study and thought. And the best way to learn by doing is to immediately apply it to something useful.

bdunbar 14y ago

How did _I_ learn the command line? By doing. Some reading, sure, but .. more doing than thinking. Like this; I was a brand-new programmer (COBOL). The Marines assigned me to a billet in the LAN team at my new command. A corporal wrote down exactly what to type on the computer after the NIC was installed. After that, I was off and running.

dps 14y ago

I learned mostly thru trial and error with Linux as a teenager, but during my CS degree this course filled in some missing gaps:http://www.cl.cam.ac.uk/teaching/2005/UnixTools/ http://www.cl.cam.ac.uk/teaching/2005/UnixTools/

DrinkWater 14y ago

must have been 1999/2000. My boss made me, the ultimate noob, the "administrator" of a Solaris Box. I didn't know SHIT! absolutely NOTHING. I was just a dumb Windows User. There was just this blinking cursor (that motherfucker) and me. i browsed the web and had to look up stuff like "cd" and "ls". Steep learning curve, i guess, but nothing teaches you better than "trial and error". Funny sidenote: Not only was i totally overwhelmed with all the commands and quirks of the command line, but the web always mentioned vim as THE editor for Unix. So i also started messing around with the most obscure editor on this planet. These were rough times for me, but i have learned so much, and i am thankful for that.

talleyrand 14y ago

Like everything else. Google.

jkmcf 14y ago

Find a mentor or an irc chatroom. My sophomore roommate knew a ton. I annoyed him to no end w/ questions (many RTFM comments…). A lot of the commands aren't named obviously, though the 'apropos' command may help.

dgunn 14y ago

What is it you want to do? Just learn or do something with it? You won't learn something like that by reading. You have to actually use a terminal to accomplish things. Often. Start using linux and develop something. You'll use about 3 terminal instances all the time. That's the way to learn.

uslic001 14y ago

This is a good book: http://www.amazon.com/gp/product/013308504X/ref=oh_details_o01_s00_i00?ie=UTF8&psc=1 http://www.amazon.com/gp/product/013308504X/ref=oh_details_o...

codemonkeymike 14y ago

Download linux on your computer(Mint or Ubuntu id recommend). Then look up the basic commands and use them (ls, cd ...). Then move on to making your own aliases(search up 'making bash aliases'). By this point you can now start trying some more advanced things like having aliases which start up programs and open your project folders(search up 'dotfiles bash'). Lastly learning some shell script can help you better understand and utilize the terminal(as you can write complex shell scripts for your aliases). As a side note using vim(or emacs) as your default text editor will keep you in the terminal longer helping you get used to using it.

presty 14y ago

> how did you learn the command line? I grew up with it

lutusp 14y ago

> Ask HN: how did you learn the command line? I had no choice -- for most of my computing career, there wasn't anything else. in fact, when I first got into computing, I would have sold my left arm to gain access to a command line interface. When I see a typical modern command line (a shell session), it's enclosed in a separate window, and I'm reminded how far we've come in a short time. Before I had access to a terminal, I was writing programs anyway -- http://arachnoid.com/programmable_calculators http://arachnoid.com/programmable_calculators -- and my first terminal's output (while working for NASA in the early 1970s) was a roll of paper. So that's my answer -- I had no choice. Oh, p.s., here's my Bash tutorial: http://arachnoid.com/linux/shell_programming.html http://arachnoid.com/linux/shell_programming.html

bowietrousers 14y ago

In 1995, all we had at university had was a bunch of SunOS & HP-UX workstations. Yes, they had X, mwm and (later) CDE, but you just had to learn the command line to do anything particularly useful. Man pages, a few of the IT service's leaflets (How to use troff/LaTeX), searching the web (Altavista! Dogpile! Webcrawler!) and asking in Usenet groups when I hit a real roadblock. I started building small shell scripts out of need to automate some things, and learned about the shell environment and the overall Unix philosophy doing that. This was over a period of years rather than weeks or months - I probably can't say that I was proficient on the CLI until around 1999 when I really started getting stuck into Linux and building everything from scratch. I find that young developers today expect to learn everything immediately, expecting a one-true-way to wisdom, rather than accepting that true mastery seeps in over time, largely through doing and getting things wrong. So, experiment, and don't give up when you can't figure out something immediately.