
Life on the Command Line - telemachos
http://lenz.unl.edu/2011/04/09/life-on-the-command-line.html
======
emanuer
This is definitely the wrong crowed to present following facts, but I feel it
might enrich the conversation.

<Quote>

    
    
      ...but I’ve seldom heard a usability expert end a discourse on human
      factors by acknowledging that graphical systems are only really 
      the “best” solution for a certain group of people or a particular 
      set of tasks. Most take the graphical desktop as ground truth – 
      it’s just the way we do things.
    

</Quote>

The Human brain has estimated 2 billions nerves in the V1 & V2 region. Those
regions are responsible for rudimentary visual recognition, of objects with
different: Form (grouping, orientation, size), Color, Motion, Spatial
position. This is one of the most powerful parallel computational systems
known to men. It takes humans about 10 milliseconds to recognize an object
standing out in those respects (e.g. gray text and one red word).

Why am I putting this down? / What are GUI's good for:

    
    
      scan 1.3 million pixels (1280*1024 screen) 
      ignore all text fields
      find all buttons
      identify a symbolic representation of the task at hand (e.g. save) 
    

The whole thing took ~40 milliseconds and most importantly: it is a task done
so fast and effortlessly by the human brain, that we don't even think about
it.

Humans are visual animals, GUI's are a result of our evolutionary history.

I am not stating that GUI's are the fastest way to get the job done. You still
have to move the mouse, etc. A skilled Command Line user can get the job done
without a 40 milliseconds delay and moving the mouse might take longer than
typing the command. However, teaching the average person to use a new piece of
software is near impossible without utilizing their incredible brain power for
visual recognition.

Graying a button out, making it red, green,... gives the skilled UX designer
the ability to convey a lot of information without making people think.

~~~
loup-vaillant
> _[…] gives the skilled UX designer the ability to convey a lot of
> information without making people think._

What if this is precisely the problem? My guess is that an environment that
don't makes you think also tend to discourage learning. This would be sub-
optimal in the long term.

More specifically, a GUI environment may be easy to manipulate at first, but
if you need anything odd (but dead simple), then you have to find a program to
do it for you, or do without it. The CLI, on the other hand, by forcing you to
write your commands (suboptimal in the short term), gives you the idea that
maybe, just maybe, you could write those 2 or 3 commands in a file so you
don't have to type them every time. The next thing you know, you want to
automate everything. And you can.

Even more specifically, take me. I use a laptop under Gnu/Linux (for serious
work), and a Desktop under Windows (mainly for games and videos). I often
download English subtitles for English or American films (I'm not a native
speaker). But those subtitles often comes with annotations between brackets
for the deaf (things like [Predator growling], [wind blowing]…). I want to get
rid of them. That would be one line of sed… But it's for films, and therefore
on my Windows desktop. Migrating it to my laptop is tedious, so I haven't
written the damn script yet.

~~~
pestaa
An environment shouldn't enforce thinking for the sake of learning. The
average user will need to think enough to figure out what to do, they don't
need brain-training puzzles as to how to do it.

Many GUIs fail to deliver in the long term, but it is not true in all cases.
Take Adobe Photoshop for example; its interface is good enough in the short
term to play around and intuitive so that the user can issue a very
sophisticated command.

Graphical interface is a huge and blurry combination of science and art, and
it still cannot solve every possible problem. Your subtitle editing case is
specifically a command-line one - but there are good GUIs that can help you
with search-and-replace in text files.

~~~
loup-vaillant
> _An environment shouldn't enforce thinking for the sake of learning._

I agree. However, I'm not sure the environment should bend over backwards to
not make you learn. Probably depends on both the task at hand and the user. If
only I could extract some generally useful heuristic…

Photoshop is an inherently graphical application, because (i) it works on
images, and (ii) it is essentially an interactive program. If however I
suddenly wanted to do _automatic_ image processing, I would very much like to
have access to some programmatic interface, most probably batch sub-programs
that one could pipe together from the shell.

> _Your subtitle editing case is specifically a command-line one_

Yep. My point was, those cases exist, though I recognize the GUI is sometimes
equally useful, if not outright superior. But the problem of GUI-only
environments (and Windows specifically) is that if you don't even know what is
a command line, you can't think of CLI tasks as CLI tasks. In my example, my
first reflex was "sed", followed by "crap, Windows". On the other hand, a
purely GUI user would have a "does a program does this?" reflex if he has any
reflex at all.

GUIs make it very hard to combine programs. So in practice, they don't. They
don't even tell the user about this concept. Instead, they tell the user that
functionality is _given from above_. If no program does this, you're out of
luck. I fear this contributes to the sense of helplessness of many users. CLI,
on the other hand, quickly makes very clear that programs can be combined,
that 5 lines scripts can be very useful. Sure, there will be a point beyond
which one will need the help of a geek friend. But he would at least _think_
of calling her.

Another point where GUIs easily fail hard is user customization. GUI programs
tend to embed every functionality, leaving very little for external programs.
For instance, Emacs or vi won't replace the built-in editing functionality of
Thunderbird or Firefox (barring dedicated extensions). So I'm kinda stuck with
the defaults.

~~~
pestaa
Graphical interfaces by definition don't have a chance to communicate with
each other, but I'd argue nowadays we have quite strong import/export
functionality everywhere, so this problem disappears in most cases.

On another note, you're also stuck with defaults if you happen to use a badly
written CLI (takes input from files only, etc).

------
planckscnst
Being able to script a program is amazingly powerful, but I find the reason I
like terminal-based programs is primarily due to the interface. The interface
of a terminal program (both command-line and interactive) is the keyboard,
which is a vastly superior input mechanism than the mouse for most things.

Any thought that goes into the interface of a terminal-based program goes
toward the keyboard interaction; there isn't a GUI to think about. Because of
this, terminal-based interfaces are usually much better than any graphical
application.

------
kellishaver
As someone with a severe visual impairment, I use the command line as much as
possible. It's easier to see and there is less I need to see. If I can type a
command instead of having to hunt for a button, it means I can work that much
faster and anything I'm looking at will be text, uncluttered, and high
contrast.

From the command line, I can navigate the filesystem, install software,
search, edit text, download files, play music, and send email all without even
looking at the monitor. Once you're comfortable with it, you can just close
your eyes and let your brain and your fingers do all of the work.

------
zdw
The fundamental part of this isn't the CLI/GUI conflict, IMO, it's this
paragraph:

 _For now, I just want to make the point that once you move to the command
line, everything is trivially connected to everything else, and so you are
mostly freed from being locked in to any particular type of tool_

The problem is people building standalone systems that aren't integrated with
the whole. For example, most people's primary text editing environment doesn't
carry over to their browser, or many GUI cases, their email program.

Solve this problem and the rest of the issues wouldn't be so severe.

~~~
palish
I often write emails in Vim, then ggSHIFT-vSHIFT-g"+yALT-TAB CTRL-vTAB ENTER.

And that, my friend, is modern day integration between gVim and GMail on
Windows.

~~~
GeneralMaximus
There is a Firefox extension that allows you to edit any text field with any
text editor. I forget the name, but a quick Google search should reveal
something.

~~~
m0tive
Vimperator can do that.
[http://vimperator.org/help/vimperator/options.xhtml#%27edito...](http://vimperator.org/help/vimperator/options.xhtml#%27editor%27)

------
kqr2
A nice essay on this topic by Neal Stephenson.

 _In the Beginning was the Command Line_

[http://artlung.com/smorgasborg/C_R_Y_P_T_O_N_O_M_I_C_O_N.sht...](http://artlung.com/smorgasborg/C_R_Y_P_T_O_N_O_M_I_C_O_N.shtml)

~~~
ysangkok
> When Ronald Reagan was a radio announcer, he used to call baseball games by
> reading the terse descriptions that trickled in over the telegraph wire and
> were printed out on a paper tape. He would sit there, all by himself in a
> padded room with a microphone, and the paper tape would eke out of the
> machine and crawl over the palm of his hand printed with cryptic
> abbreviations. (...) His listeners, many of whom presumably thought that
> Reagan was actually at the ballpark watching the game, would reconstruct the
> scene in their minds according to his descriptions.

> This is exactly how the World Wide Web works: the HTML files are the pithy
> description on the paper tape, and your Web browser is Ronald Reagan. The
> same is true of Graphical User Interfaces in general.

------
craftsman
Last year I decided to get back to basics and to dive into using emacs for as
many things as possible. It's been extremely difficult and disorienting at
times, but it has a non-quantifiable "feels right" quality to it.

I now find myself trying to do as many things as possible in emacs, but emacs
+ terminal + browser is extremely powerful. I'm not yet to the point of
running a shell (elisp shell or otherwise) in emacs, but this troika is very
powerful, and I'm extremely happy with it.

~~~
rimmjob
what programs do you use to do things that emacs cant?

~~~
omaranto
That, of course, depends on what you use your computer for, but in my case
there are very few programs I don't run inside Emacs: a browser, a pdf and
djvu viewer, Mathematica, and a media player. I do use other programs, but
mostly run them within Emacs (they're LaTeX, several compilers and
interpreters, and a shell).

------
mise
Discovering Ctrl+r (for searching through past commands) was a big jump for me
in CLI usability.

~~~
ordinary
You'll also like this little bit I yanked from my .inputrc:

    
    
      # By default up/down are bound to previous-history and next-history,
      # respectively. The following does the same but gives the extra functionality
      # where if you type any text (or more accurately, if there is any text between
      # the start of the line and the cursor), the subset of the history starting with
      # that text is searched.
      "\C-p": history-search-backward
      "\C-n": history-search-forward

~~~
telemachos
Discovering that you could so such things in .inputrc was a big lightbulb
moment for me.

    
    
        # not relevant on osx
        #$include /etc/inputrc
        
        $if Bash
            # append a '/' to show a dir is a dir
            set mark-directories on
            set mark-symlinked-directories on
            # no audible or visual bell
            set bell-style none
            # use ls -F style highlights for completion
            set visible-stats on
            # go right to showing multiple options
            set show-all-if-ambiguous on
            # ctrl-p cycles through options
            "\C-p": menu-complete
            "\C-x\C-x": exchange-point-and-mark
            "\ew": copy-region-as-kill
            # easier back and forth by word
            "\C-b": backward-word
            "\eb": backward-char
            "\C-f": forward-word
            "\ef": forward-char
        $endif
        
        # Two silly macros
        #
        # Insert double quotes & set cursor between them
        "\C-x\"": "\"\"\eb"
        #
        # Insert single quotes & set cursor between them
        "\C-x'": "''\eb"

~~~
lloeki
I did not know you could put conditions in inputrc. Useful.

~~~
telemachos
I haven't gone to much further with it, but it is very handy:
<http://tiswww.case.edu/php/chet/readline/readline.html#SEC11>

------
Auguste
I've found myself using console applications more and more recently. The only
GUI applications I use out of necessity are Firefox, Keepass and VirtualBox. I
use the console for everything else: Cmus for music, Newsbeuter for news feeds
and podcasts, TaskWarrior for to-do management, Vim for coding, etc. The
Ratpoison window manager helps me make the most of screen space and allows me
to manage my windows with keyboard commands like GNU Screen.

Unfortunately, I've never found an email client I liked, whether console or
GUI, so I just stick to Fastmail's web interface.

~~~
joelhaasnoot
VirtualBox does have a command line interface. You can start up headless
images and such pretty easily. You could even start images with a VNC server,
and control the machine from your browser. One less visual tool.

~~~
Auguste
Oh, I should clarify, I don't use it as a server or anything like that. I have
VirtualBox and a Windows XP image for any University work that requires
Windows software. Right now that's, reluctantly, Microsoft Visual Studio.

------
justinhj
The key advantages of a command line tool over a gui are power and
flexibility.

There's any number of ways I can find and filter files using the find command,
and then with xargs I can pipe them all through a sequence of simple
operations.

In a typical gui file manager that kind of stuff is just not possible. The
possibility space for what you can do is limited by the visual abstractions
the original designer came up with for file manipulation. With command line
tools that space is virtually infinite.

Often we consider the command line to be for expert users, and consider it our
job as system designers to hide it from the rest. But when you consider that
most people are able to learn basic calculus at school, a skill that has
practical use in real life in only a limited number of professions, why don't
we teach people to use the gnu tools at school? A skill that would enable them
to use computers in powerful ways for the rest of their lives?

~~~
richardk
"... In a typical gui file manager that kind of stuff is just not possible.
The possibility space for what you can do is limited by the visual
abstractions the original designer came up with for file manipulation. With
command line tools that space is virtually infinite."

whilst i certainly agree with this, i would speculate that 80-90% of the
average user's time is spent carrying out a handful of simple operations that
are better catered for by guis. for the other 10-20% we have our virtually
infinite space: the shell.

~~~
rwl
This, to me, is exactly the problem with most GUIs. If you're spending 80
percent of your time doing a handful of simple, repeatable operations, you
might as well be using a typewriter. Programs that force you to work that way
are the worst kind of chains.

------
gue5t
The biggest issue I have with the text-manipulation capabilities of the CLI is
the inability to select text in the prompt with the keyboard. Shift+navigation
buttons is standard to do this in GUI text boxes, but the CLI's slightly
different notion of the cursor (box v. line caret) comes with the inability to
select text keyboardly. How do others solve this problem? Are there e.g.
readline replacements that have this capability?

~~~
j-kidd
This is why X allows you to copy text by highlighting it, and to paste text by
middle clicking. The problem was solved a long time ago. Just grab the mouse
and stop being a keyboard elitist.

------
njharman
"I find the CLI to be faster, easier to understand, easier to integrate, more
scalable, more portable, more sustainable, more consistent, and many, many
times more flexible ... that’s a bold series of claims"

besides "easier to understand" (which depends on an individual's experience
and knowledge) I thought those were pretty much acknowledged / obvious. Not
bold at all.

no?

------
RexRollman
When I am using a Unix based system, there are three graphical programs that I
use: X11, Firefox, and Feh. Everything else I do can be accomplished inside of
a Xterm.

~~~
pyre
Do you only use mplayer with the aalib -vo option?

~~~
RexRollman
If you are talking about video, I don't play video on the computer.

------
commandar
_Unless you keep the app open all the time (I’m assuming you do that because
you have the focus of a guided missile), this is a program that you open and
close several times a day. So why, oh why, does it take so much time to load?_

This is why, even though I disagree with many of the things Apple is doing
with the OS, I think Apple is on the right track with the app lifecycle model
with Lion. Most computers ship with _far_ more memory than people actually use
these days; why _should_ you constantly open and close apps when you can just
leave them resident?

Most of the reason people even bother closing apps anymore has less to do with
the resource-juggling that made it necessary in the past, and far more to do
with workflow and window management.

~~~
cake
I was confused with this part. People actually open and close their mail
client several times a day ? Is it just closing the window or full app quit ?

For me and people I know, the mail client is the first app open after boot and
it is always "open". It takes me less than 2 sec on my 3 year old computer to
display new mail.

~~~
rch
I only check mail every few hours - when I need a break - and only actively
correspond with people at the open or close of business. I don't have an open-
door attitude at the office either.

------
shuwu83
A _pure_ CLI is an arbitrary constraint on program design. CLIs and GUIs are
not adversaries or mutually exclusive.

I see no evidence that designers are opposed to command interfaces given that
many of the graphical programs I use incorporate them where appropriate.

The world isn't black and white. GUIs can be fast and pointing can be faster
than typing. In other cases, a written command is fastest way to get exactly
what you want.

------
jiri
Keyboard is ideal for entering data, but GUI is superior to console for data
output and visualization.

It would be perfect solution if all OS/applications would have command line
but with visual output. Instead of "menu" at the top, just command line.

There some good modern approaches to this problem, for example gleeBox for
control of internet browser is nice way of integration of console style
control to GUI application.

------
joeyh
I never got into using mh, but have experienced a similar inversion when I
switched to mpd, where what was a monolithic interface for playing music was
replaced with a broad set of tools that center around the command line. It's
exhilarating to enter that kind of environment, I found myself writing dozens
of little utilities to control mpd in short order.

------
danohuiginn
One thing I've never found is a decent spreadsheet program that'll run in
curses.

Otherwise, terminal + browser gets me through 90% of the day.

~~~
4ad
I do all the things one might use a spreadsheet for in awk :-).

One might say it's slower then a spreadsheet. I don't know. I can type an one
liner awk summation/average, faster then it takes OpenOffice to load. This is
to me the most common spreadsheet operation.

For more complex task, I _feel_ that I'm working faster in awk (it's a full
blown high level programming language, after all). I'm not sure it it's
actually faster or if it's only my opinion though.

I'm happy with this setup.

~~~
rufibarbatus
Financial consultant here. I use Haskell for this kind of thing.

In the event that I need a visual prototype to work with, together with a
client or business partner, I don't think it's all that horrible to prototype
something in Excel, and _later_ port it to Haskell if necessary. But that's of
course because I already, at some point, reinvented the wheel to make this
possible. So now I'm mostly just reusing code which I already have available.

~~~
4ad
Awk makes it trivially easy to parse text. How does Haskell handle this
parsing task? I am curious because I've always wanted to learn Haskell, mainly
because of its lazy evaluation, but hadn't had the time yet. Hope to do it
soon.

~~~
rufibarbatus
Out of the box, it might not be the most intuitive text parsing tool indeed.
It's trivial, but not immediately intuitive.

That said: strings are lists of chars, and Haskell is strong at pattern
matching (esp within lists) in a bunch of different ways, so trivial text
parsing tasks are trivial and intuitive in Haskell. For anything slightly more
complex, there are regular expression and enumerating libraries which can do
the job alright (and efficiently if I may say so).

EDIT: I'm sorry, can you give me an example of a problem so I can give you an
example of a solution? :-)

------
m0hit
Tangentially related to post. Don Norman's essay on how command lines are
better suited in a graphical world for various reasons. (of course a lot of us
here feel this here already).

[http://www.jnd.org/dn.mss/ui_breakthrough-
command_line_inter...](http://www.jnd.org/dn.mss/ui_breakthrough-
command_line_interfaces.html)

------
enneff
Most of the programs he describes aren't CLI programs but programs with a
Terminal-based GUI.

A real CLI warrior uses sh, ed, and mail. :-)

~~~
sgerrand
Obligatory 'real programmers' links:

* <http://www.pbm.com/~lindahl/mel.html>

* <http://xkcd.com/378/>

------
rch
Every now and then I have similar complaints, but I don't think it boils down
to cli vs. gui - the situation is actually far worse.

Building high quality productivity tools that are able to exceed the
expectations of expert users is both difficult and time consuming... and there
is almost zero market incentive to accomplish the task properly for consumer-
class applications.

[edit] this is not to imply that consumer apps are trivial -- I think I once
saw Minsky discuss an early attempt at AI that started by interpreting
children's books, thinking that would be easier than understanding journal
publications, etc. -- it quickly became clear that the task of parsing a
children's story requires an immense store of implicit context and as such,
was completely intractable at the time. The challenge of writing 'simple'
things like email, text editing, and spreadsheet apps seems related to that.

------
richardk
gui vs cli, interesting topic.

i used to use the command line for everything but recently switched to using
guis.

switched mainly because gui applications seem nicer to me for completing
common desktop tasks, for example listening to music, i can just click the
rhythmbox applet and select a song as opposed to something like "mplayer
~/Music/some\ artist/some\ album/*" or manipulating files, it seems a lot
nicer to me to be able to pull a file onto my desktop than type out (even with
tab-complete) "mv foo ~/Desktop". ofcourse, there are exceptions when using a
shell is much easier, for instance if i want to copy a large number of files
whose filenames have some similar pattern.

it's also very nice to be able to install some new program and just use it,
why should i have to read long poorly written man pages?

at the same time i still use a shell everyday, but as a
programming/administration tool.

~~~
icebraining
For music, you should try a proper music player, like MPD and ncmpcpp. It has
a music database, playlists and all that stuff.

~~~
richardk
out of curiousity, does MPD/ncmpcpp make use of the shell? if it doesn't then
i can't see how it'd be advantageous over a gui music player like rhythmbox

~~~
icebraining
The nice thing about MPD is that it can be controlled by all the clients you
want, and MPC (the default client) is excellent for scripting.

OF course, for manual control ncmpcpp - which is ncurses - is easier to use.

------
smharris65
Can any of these command line programs connect to Microsoft Outlook email
servers? That's the number one problem: at many work places Outlook is
entrenched and the Outlook UI is terribly outdated.

~~~
djeikyb
As long as Exchange is set up with the imap button checked, mutt works great.
I don't know of an open source MAPI connector.

~~~
dredmorbius
I wouldn't say "great" as far as IMAP goes, as Exchange gets horribly confused
when there are multiple connections made to it.

That said, I find offlineimap is a better tool than mutt's built-in IMAP
support.

------
Luuucas
nice example for living the command line idea: <https://addons.mozilla.org/en-
US/firefox/addon/instantfox/>

~~~
danohuiginn
I prefer <http://yubnub.org/>. Yubnub also calls itself 'a command line for
the web', but manages that without requiring an add-on

------
jamesrcole
As i commented over on that site, I wish we could have the best of both
worlds. I'd like a UI that did a really good job of integrating command line
and GUI features. Not something that just tacks them together. To do this
you'd really have to think through the UI from scratch (and yes, I am
interesting in trying this myself, but am currently working on other things).

When you think about it, the fact that command-lines are text-only is really
just a historical artifact and it's nothing inherent to the notion of command-
lines.

------
chimeracoder
I completely agree with this, and I'm glad that somebody's writing a series on
how to be productive on the command line.

I find Neal Stephenson's 'In The Beginning Was the Command Line' to be a nice
overview of why GUIs became the dominant paradigm over the CLI. I understand
the desire to be 'user-friendly' to less tech-savvy people, but it's a real
shame that we've equated 'functional' with 'has a good-looking graphical
front-end'.

Even a few weeks after I began using the CLI (almost) exclusively, I couldn't
imagine going back.

------
killerswan
Most of the interesting GUIs today are web sites, which he uses...

Anyways, I think icons are overrated, and the text hyperlink rules the
universe.

------
discreteevent
Its a pity that he is so absolutely wrong about the bike for one of its main
use cases: Traveling a reasonably long distance over terrain that is not
perfectly flat. A bad analogy weakens what follows unnecessarily.

------
jeez
a bit off-topic, but IS there a command line music player that works the way
he illustrates in the article?

~~~
alexkay
<http://cmus.sourceforge.net/>

~~~
officemonkey
I also just found out that "pianobar" is a cli for Pandora.com.

------
Kwpolska
I resigned from a terminal IM client, because it made me less productive than
a GUI client. Additionally, some features were annoying.

> Type pine or mutt (for example), and your mail is before your eyes in the
> time it takes a graphical user to move their mouse to the envelope icon.
> Type q, and it’s gone.

Not quite. I need to wait for "fetching message headers". It takes a while.
mutt and IMAP.

~~~
icebraining
>I resigned from a terminal IM client, because it made me less productive than
a GUI client. Additionally, some features were annoying.

Using mibbit or bitlbee with an IRC client works for me.

EDIT: Not mibbit, I meant minbif (<http://minbif.im/>)

~~~
vae77
\+ 1 on bitlbee. I use it with weechat-curses.

