Life on the Command Line

http://lenz.unl.edu/2011/04/09/life-on-the-command-line.html

by telemachos • 15 years ago

177 120 15 years ago

lenz.unl.edu

danohuiginn3• 15 years ago

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.

4ad2• 15 years ago

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.

rufibarbatus3• 15 years ago

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.

keeperofdakeys• 15 years ago

From what I have used of lotus123, it was quite a decent program. I'm sure you could find a lotus-inspired program somewhere.

danohuiginn3• 15 years ago

Thanks for the tip. MacroCalc seems to fit the bill - http://www.freakout.de/#mc

[haven't tried it yet]

chimeracoder2• 15 years ago

Personally, I use R. Importing and exporting CSV files in R is trivially easy (it's what it's made for, after all). Doing transformations on an entire column or row at a time is also very simple.

Import a csv, then take the logarithm of one column and plot that against some transformation of another column? No problem - two lines in R, and still highly readable.

icebraining4• 15 years ago

Possibly Oleo[1] or Teapot[2]?

[1] http://www.gnu.org/software/oleo/ [2]: http://www.syntax-k.de/projekte/teapot/

RexRollman5• 15 years ago

There is always SC. And of course, Google Docs exists.

lloeki2• 15 years ago

I end up using Python. In the end it's much more powerful and less error-prone (the oops factor of spreadsheet apps is ginormous). Quality plot, graph and stat modules abound.

Plus it has the advantage of being able to trivially scale in any direction, like refactoring or working on a real database (sqlite) when the dataset grows instead of shoehorning a database into a sheet, or making a module out of it, or integrating it with other random tools.

Kwpolska• 15 years ago

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.

sp332• 15 years ago

I thought you would use (e.g.) sendmail to get the mail from the server to your local inbox, and then use pine or mutt to manage them?

anonymous• 15 years ago

set header_cache="~/.mutt/hcache"

I have more than 10k emails sitting in my inbox and with this option mutt loads the headers in around one second (over the Internet).

And of course I could fetch all the emails in the background and use mutt locally, but I didn't bother yet.

icebraining4• 15 years ago

>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• 15 years ago

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

sramsay2• 15 years ago

IM was one of the last graphical applications to go for me (I'm the author of the article). I had the same problem until I discovered bsflite (http://bsflite.sourceforge.net/).

exDM69• 15 years ago

mutt is traditionally used together with a mail transfer agent (MTA) and other software to fetch the e-mail. mutt is only used for reading e-mail, not sending, receiveing or writing, there's other software for that.

There's POP, IMAP and SMTP support in mutt for convinience, but that has to be enabled explicitly at compile time. However, this means that mutt will fetch all the mails when it starts and this is slower than having it already locally fetched.

Auguste2• 15 years ago

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• 15 years ago

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.

mise2• 15 years ago

And I wonder if KeePassX has a CLI. Its GUI current form is clunky.

Auguste2• 15 years ago

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.

RexRollman5• 15 years ago

That's me right here. I love Ratpoison, although I think Evilwm is really good as well.

I never liked e-mail in Unix, as I feel the whole MUA/MTA thing is too complicated, so I stick with Gmail (which I backup with Fetchmail to a mbox file).

adimitrov• 15 years ago

There's a problem with that, though: fetchmail won't notice state changes in your mailbox — like, whether an email is read or not, whether you've replied, forwarded it already, etc.

That's why I came to despise the MUA/MTA schism of Unix so much: If I reply to an email on my laptop, I won't know it on my desktop. The only solution is to have a central server you can ssh into. Clunky solution at best.

Solution: use Mutt's semi-new IMAP interface. Nothing is stored locally, and I can see whether I've replied to emails, and I can delete/move emails regardless of the computer I'm currently on.

mise2• 15 years ago

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

ordinary2• 15 years ago

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

telemachos2• 15 years ago

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"

j-kidd3• 15 years ago

Better yet, from gentoo's /etc/inputrc:

    # map "page up" and "page down" to search history based on current cmdline
    "\e[5~": history-search-backward
    "\e[6~": history-search-forward

This way, you have up/down for history traversal, and page up/page down for history searching.

More importantly, and what most people missed out is that, this history searching works on ALL command line interfaces, including bash shell, ipython, and psql.

Seriously, a command line advocate who doesn't know about this can't be serious.

Symmetry• 15 years ago

Yeah, one of the many nice things about fish(the Friendly Interactive SHell) is that it does that automatically.

planckscnst3• 15 years ago

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.

chimeracoder2• 15 years ago

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.

craftsman• 15 years ago

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.

zobzu3• 15 years ago

supress emacs and itll feel right

Sent from my VIM.

rimmjob• 15 years ago

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

omaranto2• 15 years ago

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).

Luuucas• 15 years ago

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

danohuiginn3• 15 years ago

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

burgerbrain• 15 years ago

You can do that yourself what whatever site you wish by right-clicking on the search bar on any site an selecting "add keyword for this item".

zdw• 15 years ago

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.

palish2• 15 years ago

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.

astine• 15 years ago

Had you used mutt instead of Gmail, you would have simply used: SHIFT-zSHIFT-z. When you want to compose mail in one of these programs, it opens your specified text editor and uses the whatever text you enter as the contents of your message. It works a lot like the 'Intents' feature which has been Android has received so much praise for, only it's decades old.

Actually, there's no reason for this to depend on the cli. In Firefox, there are plugins which give you a button to click under every text box which open your favorite text editor with a buffer already open containing the contents of the text box. Edit the buffer and save, and your changed appear in the text box. (This is, in fact, how I am editing this comment.) On Unix systems, a graphical mail program could easily use a shell call to get text from an external program. The only problem is, this just doesn't really happen. Vendors prefer proprietary interop with their own products rather than more universal interop methods.

gmac• 15 years ago

I'm not sure if you're saying that this shows the problem to be solved, or that it shows just how unsolved the problem is...

GeneralMaximus• 15 years ago

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.

mechnik• 15 years ago

I like. It appears Google released a command line tool that integrates with its services: http://code.google.com/p/googlecl/

zobzu3• 15 years ago

you've just shown the fail that is GUI. alt tab and copy paste seriously?

command line mail clients dont need any of that. you edit it in vim and send it from vim. or you edit it from your email client THROUGH wim and send it also directly.

No utterly long key combo. No app switching. No delay. No complexity. No cut-and-paste.

That is the actual point.

siddhant• 15 years ago

Maybe you should give VMail a shot (http://danielchoi.com/software/vmail.html). I haven't tried it yet, but it looks really interesting for someone used to the Vim keyboard bindings.

rufibarbatus3• 15 years ago

I suppose this is what Apple had in mind with their object-oriented, drag-and-drop philosophy for the Mac: a GUI which would allow people to pipe things visually with as much ease as possible, reaching a compromise between the UNIX philosophy and their notion of software design as making things "magic."

Right now, the most impressive achievements (IMO, and YMMV) in that arena come from the Plan 9 community, which is still a far cry from lay person's usage (partly because the Plan 9 community seems to pride itself—as a rule—for being a research OS community rather than the next blockbuster OS).

rch3• 15 years ago

I like that plan 9 has stayed out of the chase for users, but I do think the multi-button mouse interaction model needs to be updated to leverage touch-sensitive surfaces and gesture commands.

gue5t• 15 years ago

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?

slug• 15 years ago

Besides using yank/paste keyboard shortcuts, you can always use screen or tmux copy mode. If you need the output of a command sent to the clipboard, there's several ways, xclip is one of them.

j-kidd3• 15 years ago

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.

dredmorbius2• 15 years ago

aptitude install xclip

I map 'xc' to 'xclip' and 'xp' to 'xclip -o' (paste) with shell scripts.

Copy to/from clipboard via pipes.

Though X11 copy/paste works pretty well also. There are the odd occasions where a mouse is the right tool for the job.

emanuer• 15 years ago

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.

jodrellblank2• 15 years ago

It's not quite right to imply that because a command line isn't graphical it isn't using human visual recognition - we still see CLIs.

We still use colour and non-word markup to convey information in CLI programs, such as hashes at the start of lines to indicate headings, or line borders to indicate a 'button', or : to indicate a command, e.g. in VIM.

Many of us use it as if it was a hybrid system - a GUI display controlled by keyboard where possible.

planckscnst3• 15 years ago

Then why do I spend many seconds trying to find certain buttons that are right in front of me ("Where the hell did that ordered list button go?") and even longer trying to find buttons that aren't even there?

Terminal-based programs also do make use of color as well as white space and grouping. They do convey information visually. A primary example of this is `ls -l` (the color option is different on different systems, but is almost always aliased on by default).

KirinDave• 15 years ago

No one is arguing that guis turn you into some kind of unerring productivity robot instantly navigating through huge sums of interface magically.

The point is that well-designed GUIs can make better use of a large subset of the human brain. Poorly designed ones will not.

And, some tasks are so inherently visual that they're not even up for debate. For example, there simply is no opportunity for a command line tool to enable what Lightroom or Aperture enable. It's simply too visual a task.

j-kidd3• 15 years ago

> A primary example of this is `ls -l` (the color option is different on different systems, but is almost always aliased on by default).

A primary non-example is Ubuntu, where $PS1 is colorless, and `grep --color=auto` is not aliased to `grep`. It is the least user friendly distro if you use the command line.

loup-vaillant3• 15 years ago

> […] 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.

richardk4• 15 years ago

"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."

imo, we should be thinking about the task we are working on, not the interface we are using to accomplish our task, so the best interface is the one we don't even notice.

pestaa2• 15 years ago

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.

omaranto2• 15 years ago

I recommend installing Strawberry Perl on Windows machines. It's a great substitute for sed, awk, etc. and is even as powerful as Perl. :)

jodrellblank2• 15 years ago

Given your first paragraphs about forced learning, your last one about how you don't know how to fix your problem in Windows so you just leave it broken is a strange contrast.

If the subtitles are plain text with annotations on their own lines, a one line command will strip them out:

  for /f "delims=" %x in subtitles.txt do @echo %x | @find /V "[" >> subtitles2.txt

And if you do need sed and regexes, get sed for windows: http://unxutils.sourceforge.net/

tygorius• 15 years ago

it is a task done so fast and effortlessly by the human brain, that we don't even think about it.

It would be more precise to say those are the capabilities of one of the systems that comprise the brain. I think it's a mistake to lump the speed of perception in with the speed of cognition. To put it another way, pointing to the superiority of a gigabit ethernet connection is probably misplaced if it's connected to a microcontroller board running with a 5 MHz clock.

teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition

This is where I fear GUI enthusiasts often go astray: conflating everyday usage of software with the experience of people learning to use it. It is very useful to examine a light switch when you first encounter it, for example, but people quickly adapt to the common use case of flipping the lights on when entering a room without having to look at the light switch. Or in terms of the original article, most of the usage of a mail program is reading and writing messages -- an area where the advantages of icons, buttons, and menus are debatible.

BTW, CLI user are using their visual systems as much as GUI users are. CLI users are merely using a more structured format for their visual input.

cturner• 15 years ago

Use of a computer shouldn't be a visual experience for most tasks. You have a mental model of what's going on, and then poke stuff to verify the model and to affect state.

    > However, teaching the average person to use a new
    > piece of software is near impossible without
    > utilizing their incredible brain power for visual
    > recognition.

This is a good point. Visual recognition helps with the first hurdle of learning.

But when users encounter complexity they'll look for their GUI tool to reach the right standard. GUI approaches don't scale well to complexity. You end up with industries surrounding successful GUI software to help people deal with what is now a constricting user interaction model.

There are other models to consider than GUI or CLI. The Bloomberg model offers discoverable, keyboard-driven interaction but nicely-formatted feedback. It's easy to teach too.

7952• 15 years ago

GUI tools can scale well for complexity. Just look at how an experienced user can drive CAD or finalcut. It is just a matter of learning the interface, and understanding the domain it targets.

I would argue that the real hurdle to learning is accessing and understanding the documentation. In this respect CLI has the advantage with man pages. With UI the easiest way of understanding is to ask another human, which has obvious limitations.

Goladus• 15 years ago

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

Your example isn't really why GUIs are good. Yes, humans are great at navigating a GUI, however all four of those problems are introduced by the GUI to begin with. On a command line, you don't have to scan 1.3 million pixels. You learned where to look the first time you ever used it. You don't have to ignore anything, except maybe your scrollback buffer. You don't have to find any buttons. You don't have to identify a symbolic representation of the task at hand. You do have to know what you're doing, which I'll address later.

And those tasks are NOT done effortlessly. We may pretend it is, but frankly I have a huge problem with the clutter of my GUI. My brain gets tired, often without my realizing it, filtering out all the extraneous crap on my screen. I'm so much more productive with all that out of the way. I've taken to using compiz zoom to clear out all my tabs and taskbars and menus and of course ads and stuff so I can actually focus on the articles I'm reading.

But yes, you do have to know ahead of time how to do what you want to do. There is no representation to guide you, symbolic or otherwise, unless you know how to look for it. What the GUI actually does is the last sentence of your post: GUIs convey information. GUIs let people learn to use something as they go. Without a GUI, there is usually more of an up-front investment into learning how to use a tool. That people are good at navigating GUIs is incidental. People are good at using mechanical devices and language, too.

And as someone who has spent a significant amount of time helping people use windows applications, often the GUI doesn't even matter. They still have to get help to accomplish simple things, and often wind up completely misunderstanding what the GUI is trying to tell them.

> However, teaching the average person to use a new piece of software is near impossible without utilizing their incredible brain power for visual recognition.

It's not impossible. 20 years ago, before "UX designer" was even a word, plenty of average, non-technical employees used text-based and command-line systems to get work done. Students at my university had no problem using PINE on OpenVMS to read their email. People have the ability to learn command language and program motor memory. It's not even close to impossible.

But learning a formal language rather than a graphical interface is just sufficiently harder that having an easier-to-use GUI gives software vendors a competitive advantage. So in the last 20 years have GUIs have evolved a great deal, and are used even when they don't fully expose the power of the software they're providing, or fail to provide the user all the knowledge necessary to use the software effectively.

richardk4• 15 years ago

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.

timmy-turner• 15 years ago

Same for me. For example, I like using git gui or tortoisehg when doing complex commits as those tools enable me to find, inspect and select all necessary files faster than typing a command for each file/task. For examining recent log entries or switching branches, pushing etc., I prefer the cli. For complex file tasks I use mc, which is a nice hybrid solution between a gui and a bare cli.

freedrull• 15 years ago

For git, have you tried tig? It has a nice ncurses interface for inspecting commits and doing all sorts of git related things.

icebraining4• 15 years ago

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

richardk4• 15 years ago

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

smharris65• 15 years ago

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• 15 years ago

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.

dredmorbius2• 15 years ago

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.

RexRollman5• 15 years ago

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• 15 years ago

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

RexRollman5• 15 years ago

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

killerswan• 15 years ago

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.

njharman• 15 years ago

"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?

kellishaver• 15 years ago

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.

rch3• 15 years ago

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.

joeyh• 15 years ago

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.

kqr2• 15 years ago

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...

ysangkok• 15 years ago

> 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.

commandar• 15 years ago

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• 15 years ago

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.

rch3• 15 years ago

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.

justinhj2• 15 years ago

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?

richardk4• 15 years ago

"... 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• 15 years ago

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.

justinhj2• 15 years ago

But they are limited permanently and may spend hours doing things by hand that could take a moment. A common one is renaming photographs.

william42• 15 years ago

Because 90% of the population uses Microsoft Windows?

jiri• 15 years ago

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.

enneff• 15 years ago

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• 15 years ago

Obligatory 'real programmers' links:

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

* http://xkcd.com/378/

m0hit• 15 years ago

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...

shuwu83• 15 years ago

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.

jeez• 15 years ago

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

alexkay• 15 years ago

http://cmus.sourceforge.net/

officemonkey• 15 years ago

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

jesboat• 15 years ago

mpd

discreteevent• 15 years ago

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.

jamesrcole• 15 years ago

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.

Life on the Command Line

Related Stories