The Command Line Challenge.
blog.chavezgu.com
blog.chavezgu.com
Also, I'm annoyed at other commenters' equating "command line" with primitive: just because GUIs are newer does not mean they are superior or that the command line is obsolete! For a large range of tasks like file management or system administration it is actually superior; for quite a lot of other things it's completely usable. I'm not saying GUIs are useless or that the command line is perfect for everything, but it is far from obsolete or inferior.
Now, doing everything in a terminal is overkill, which is why this is a challenge--you're not expected to use a terminal forever, just long enough to get sufficiently acquainted with it so that when you do things the terminal is great at--which you will--you will be able to use it as efficiently as possible. And, since all the readers here doubtlessly spend very large amounts of time behind a computer, being as efficient as possible there should be a priority.
Coincidentally, I say all this as somebody who started using a computer with Windows 95. I only learned how to use the command line (first a bit on Windows then on Linux) because it looked cool; I continue using it because it turned out to be more efficient at a whole host of tasks than using a GUI.
Try spending a week using just ed, mail, and curl. Those are actual command-line programs, not just terminal-based programs. The litmus test is whether they would work with a real paper teletype.
"When I log into my Xenix system with my 110 baud teletype, both vi and Emacs
are just too damn slow. They print useless messages like, ‘C-h for help’ and
‘“foo” File is read only’. So I use the editor that doesn't waste my VALUABLE time.
Ed, man! !man ed"
I'd say the keyboard-centricness still separates them from, say, Eclipse.
The real challenge these days is javascript. I'm not aware of a text-mode browser that interprets javascript.
I'd also like to give a plug for w3m. It's far more user-friendly than lynx, and IMO more advanced than elinks.
I think we can be more purist still: menu-driven UIs are not really command line either. MH has a truly command-line UI for mail, while the mail program doesn't.
Some years back, I spent a couple of days trying to use ed for some serious text preparation work before I decided this was not the kind of experiment one should do when better tools are available and real work needs to be done. Using nmh (an MH reimplementation) used to be a pleasure, until its clumsy handling of HTML (quite a bit worse than mutt) began to overwhelm the whole user experience.
Something to be said for leaning by immersion.
I was using Debian on a compaq dual 200MHz Pentium Pro desktop until about '02. I was pretty much 100% of the time on the shell so I really didn't need anything more.
Mutt for email, irssi for IRC, links for browser, vi for the editor and a 512k ADSL connection. That was about it.
The whole machine cost me 10GBP (about $15). It replaced an old Sun machine I found in a skip in 1997.
I bought my first new computer in 2004 :)
The console rocks.
Lynx/links/elinks are not acceptable substitutes for a modern browser.
The command line is a powerful tool, and it has its place, like any other tool. This just reeks of "all I have is a hammer..." syndrome.
The best way to rid yourself of "I have this hammer..." syndrome is to get rid of the hammer temporarily, and force yourself to use the alternatives for a while. That way you get to know them, and can recognize when they're a better choice than a hammer. After that you start using the hammer again, but now you can put it aside when you need to.
That's why the author suggests giving up your GUI-based tools for a short time.
I have to say that I haven't seen such a fair argument in favor of emacs or vi for years.
I love command lines, and I use them every day. Most of my work is on a command line... in a term window in X. The Linux virtual terminal system was a great advantage. The ability to run multiple terminal windows on-screen at the same time, with a clipboard! that was an amazing achievement. Virtual desktops? Great.
All of these things are advantages, and you don't need to stop using the good stuff that works in order to use the new stuff that works. Today I click on one of my sidebar icons to summon the terminal windows in which I do most of my work. I have enough RAM that I can keep heavy graphical browsers open -- FF and Chrome -- with hundreds of tabs open.
I'm happy to be able to use everything. I'm happy to have choices.
I've never understood why lynx gets so much more love and respect than elinks. Elinks has tabs, lynx doesn't. Elinks supports some EMCAscript, lynx does not. What are these special features that only lynx has?
I just happen to be able to get a lot done using a terminal. However, that does not mean I want to be doing something Excel-ish in anything but Excel.
Which is hard, b/c it's so flexible that it gets adapted to a lot of stuff it really shouldn't be. A big chunk of Corporate America uses Excel the way our foreprogrammers used Perl or Bash, adapting it to all manner of tasks because it's what they know. I admire their resourcefulness (and scorn their IT environment for limiting their access to better tools) but that handiness leads them into solutions that are fragile, unmaintainable, uncheckable and unscaleable.
The step from Excel to broader, more flexible tools is the move away from graphically delineated relationships to logically stated relationships. It's a very hard step, and one most people won't make unless they force themselves through a period of clumsiness while they orient themselves to a new approach.
Exercises like the OP are a great way to do just that: "I'm going to force myself in this direction by setting some simple but arbitrary obstacle that will build capabilities I can use elsewhere." Doing so on tasks that are well understood may help even more -- "I know how I would do this in Excel, how do I do it in Python?" -- because your knowledge of the problem frees you to learn the new things about this new sort of solution.
The OP isn't saying the CLI is the right tool for everything, he's saying this is a way to build the understanding that lets you move to it freely when it is the right.
But then again I'm a little biased, since I work for a company that makes our own vi, perl, awk port of entire POSIX APIs for Windows and UNIX shells etc. And cross platform ALM suite of applications (Linux, Solaris, AIX, HPUX, Windows, Mac OS X). I can't imagine being a developer and not being in the CLI 99% of the time.
You can use the (terribly named.) libcaca. Or you can use fbi as root and take advantage of having a display that isn't a physical teletype.
IMHO, bigotry is not only bad in politics. We have to embrace the change, learn new tools, improve, share our knowledge and not only make our jobs better for ourselves, but also for others. Especially for rookies, who will have to be doing more tomorrow than what we do today. I don't believe `libcaca` has anything to serve this purpose.
Using mutt instead of gmail; I'd ask "Why?". We don't need to stick with the tools we've used 10 years ago. If I'd be looking for a challenge as a sysadmin, I'd learn ways to better utilize cloud environments, look for better ways to serve static content for large volume systems, improve my tool base for managing geographically distributed servers, learn about the requirements of the new era of real time web, how to deploy node.js on my servers, etc.
For people who haven't used CLI before; or who don't have much experience of the command line: it makes some things about the Unix way a bit clearer. One program does one task, but does it well. You pass the output from one command into the input of another. Input and output are text, because text is universal.
These are important powerful concepts and I'm disappointed that they've largely been forgotten in the GUI world.
I'm also baffled that my vastly powerful computer has areas of lagginess when grinding through some seemingly trivial things. A pure-CLI trivially-easy-to-install distro[1] isn't going to happen, but imagine the use people could get from all those old computers which are not coping with modern OSs.
[1] Linux from scratch definitely does not count. TinyCore doesn't really count. Arch sort of comes close, but would need to be i) Much easier to install and ii) have a specific repository for CLI / Curses / etc software.
For this exact reason, in my first experiences with GNU/Linux, I reinstalled the distro every time X was screwed.
Both have their place.
I can understand the browser - I use a graphical one too - but except for CD covers there's really no content a music player needs images for.
Ncmpcpp has a clear, nice interface with features like automated lyrics downloading, database management, tags editor, playlists, etc. And the advantage is that since it's only an MPD frontend, you can still use mpc to script stuff.