Power of the command line
Disclaimer: I am not advocating any specific tools or methodologies, but sharing a workflow I find to be efficient and pleasant.
I am a huge fan of working with CLI applications. I use Vim for editing code,
composing emails, and various kinds of writing. When I have to manipulate huge
amounts of email, I use Mutt: itâs intuitive tagging and regular expression
engine are extremely useful for the task. I employ ack
, awk
, grep
, and
sed
- Linux utilities which allow for precise and fast text manipulation.
However, I would not use CLI browsers like elinks
or w3m
, and the idea of
reading every email in Mutt gives me the creeps. I love the visualization web
browser offers, something text-based prompt is not able to provide. And it
doesnât have to.
There are two components to most of the tasks performed on a computer: analyzing output and entering input. Certain tasks employ one component more than the other. In most modern applications itâs rare to have both solid control from the user perspective and a pleasant informative UI. With increased visual component, itâs more time consuming to make the application do what you need, especially if your needs are esoteric. With more editing power, visual display becomes less complex in order to make editing tasks easier.
Where visual tools fall short
What is the alternative? Using multiple programs with different levels of control to accomplish one task: to edit text. Each of the programs excels in itâs own field: word processing software allows for beautiful fonts and document presentation, IDE lets you access aggregated meta information about your application. But most of the IDEs and word processors lack the powerful tools needed to manipulate the foundation of what user is working with - plain text.
Ode to plain text
I spend a lot of time writing and editing plain text. Be it source code, emails, documentation, or even blog posts. These tasks take up significant amount of my day, and it is only logical to substitute some of the visual presentation capabilities for effectiveness.
It is hard to mentally process data which is not explicitly and unambiguously visible: different levels of headings, hidden meta information. Unlike more obscuring formats, plain text is all there is - it has nothing to hide. If you donât see it - itâs not there. If you do see it - you know exactly what it is.
One of my favorite tips from âPragmatic Programmerâ goes:
Use a single editor well
So I learned one editor well, and now I use it for all my writing and editing needs. I donât have to jump between IDE, browser, and office software. Most of the text I edit is manipulated with one editor. There is only one set of key bindings to know, one skill to master and hone. Fast, without any additional thought, using single text editor and all of itâs powerful features is imprinted in muscle memory. One less task to worry about.
I write my documents in Markdown format, and later convert them to the desired
output using pandoc
: be it an HTML page, PDF, or a Microsoft Word document. I
use Vim, so I can rearrange paragraphs or manipulate lines within a couple of
keystrokes. Since I spend so much time editing text, I also touch type, which
makes me even more effective at the given task.
Harness the power of the command line
When it comes to bulk manipulating files or working with version control - there is no better candidate then command line applications. Thereâs no need to go through a number of obscure menus, ticking and unticking checkboxes, and hoping that your desired result can be achieved with a programâs GUI.
Letâs look at a few scenarios some users face in their daily workflow.
Creating a backup
With GUI, youâd have to take multiple steps:
- Right click
file
. - Left click on âCopyâ.
- Right click on some empty space.
- Left click on âPasteâ.
- Right click on a newly created copy.
- Left click on âRenameâ.
- Switch to a keyboard.
- Type
file.bak
.
The above steps can be sped up using shortcuts like C-c
or C-v
, but not by
much. Hereâs an alternative in bash:
cp file{,.bak}
While first variant would do great for a novice or a casual user - the second method would be much more preferred by an experienced user whose concern is speed.
Recursively bulk replacing text in a directory
Letâs assume we want to do a bulk replace text in a directory and all itâs subdirectories. We have our trusted IDE, letâs assume this IDE is already configured to work with a desired directory.
- Open your IDE.
- Select âEditâ menu.
- Select âFind and Replaceâ submenu.
- Click on a âFindâ input field.
- Switch to a keyboard.
- Type
function_to_replace
. - Switch to a mouse.
- Click on âReplaceâ input field.
- Switch to a keyboard.
- Type
new_function_name
. - Switch to a mouse.
- Enable âSearch in subdirectoriesâ checkbox.
- Click âOKâ.
Again, this can be shortened a bit with some keyboard shortcuts, but not by much. You still have to switch between keyboard and a mouse a total of 4 times, and you still have to click through all the menus. This does get time consuming if you do this often. Now letâs try to perform the same task in command line:
find . -type f | xargs sed -i 's/function_to_replace/new_function_name/g'
Much faster, if youâre able to memorize the structure. And remembering what the
commands do is much easier than it looks. Especially with the help of man
or,
even better, bro
(see http://bropages.org for latter).
The above example demonstrates one of the biggest advantages of command line
interfaces: an ability to redirect an output of one program into another,
chaining the tools together. In this example, we first get a list of all files
use find
tool, and then run sed
tool on each of those files in order to
replace the text.
An output from any CLI tool can be fed into any other CLI tool. This allows for countless possibilities and high adaptability to unscripted scenarios.
Is it worth learning CLI tools over their GUI counterparts?
This depends on what your intentions are. If youâre a power user who writes and edits a lot of text or manipulates bulk amounts of text on a daily basis - than itâs definitely worth it. Time spent learning these tools will pay off. But if youâre a casual user whose needs end with writing an occasional email or two - then you probably donât need to worry about this.
Hell, if youâve read this far - this means youâre the former case. I can practically guarantee that you will benefit from employing command line tools and modal editors over their GUI counterparts.
Iâve put together a table for comparison between two. Indeed, there are different times when either GUI or CLI tools excel:
Factor | CLI | GUI |
---|---|---|
Ability to combine/chain tools | Yes | No |
Easy to learn | No | Yes |
Efficient for a novice user | No | Yes |
Efficient for an experienced user | Yes | No |
Good for occasional use | No | Yes |
Good for repetitive tasks | Yes | No |
Presents visual information well | No | Yes |
As you can see - both CLI and GUI programs have their pluses and minuses. CLI tools seem to appeal to experienced users, while GUI tools are great for novice users and do excel in representing visual information. No matter what kind of interface you prefer, itâs crucially important to use the right tool for the job.
5 read-only comments
These are the read-only comments I've exported from Disqus (which I no longer use). If you'd like to share your thoughts about this article, you can âď¸ Reply by email.
I laughed out loud at "gives me crĂŞpes". But seriously, a nice, balanced article. Thanks for showing me http://bropages.org ! Something I didn't know of, but desperately need.
To rename a method I hit Ctrl-R and thype the new name. Much leas to type than your command line and much safer, too.
I can also be sure that I do not end up renaming other unrelated methods (e.g with the same name in another class or that contains the string you are searching. The command line is way more dangerous and much slower.
Using an IDE also makes you produce more readable code, simply because renaming is safe and simple. You rename a lot more in an IDE than you do with pattern based replacements, simply because you are less likely to break something.
I would recommend learning *proper* tools for each task at hand. That does include the command line, it includes vim, but it alsGUI tools and definitely a proper IDE.
Thanks for the feedback! What an embarrassing typo! :) Fixed.
That's true, there are times when you need to use GUIs and there are time to use IDEs. I myself turn my Vim into an IDE with a load of proper plugins when I need to work on an enterprise code base.
This article does indeed sell GUIs short - but GUIs are already "sold". I was hoping to show people who solely use GUI applications what are they missing out on.
Great article, thanks.
Find xargs will fail for files with spaces in it.