Unix is my IDE

An integrated development environment (IDE) such as PHPStorm, Eclipse or Netbeans provides a set of tools and integrations available together to make development easier.

Common features are:

  • Text Editor

  • Project search and replace

  • Automatic building, testing, linting

  • Source control integration

The command-line meets all of these features.


First, my text editor is vim. I don't use vim as an IDE, which some do, I use it as a text editor. Vim opens so quickly, it's no hassle to open and close it frequently.  Just like the editor text pane in an IDE, if I'm editing a file its open, if not its closed.

There are plenty of vim tutorials and articles, I wrote a working with vim article which has a few tips on how I use vim. I'll include one new tip here on plugin management, check out vim-plug.

Here is the section in my .vimrc to setup plugins, which to install I just run :PlugInstall or to update :PlugUpdate plus more commands for managing plugins.

call plug#begin('~/.vim/plugged')
Plug 'fatih/vim-go'
Plug 'junegunn/fzf',  { 'dir': '~/.fzf' }
Plug 'junegunn/fzf.vim'
Plug 'scrooloose/nerdcommenter'
Plug 'SirVer/ultisnips'
Plug 'tpope/vim-surround'
call plug#end()

I'm recently discovered ripgrep, which is a fast search tool, tops compared to grep, ack, silver searcher (ag), and the previous champ platinum searcher (pt).

Ripgrep is fast, but the real power comes when you pair it with fzf which is a fuzzy search tool. This combination is so powerful, and can be used both inside vim and on the command-line.

The fzf and ripgrep packages are available in many updated package repositories, including Ubuntu 19.04 and Homebrew.

If not available in your package manager, you can install by downloading the binaries. Download fzf binary or you can also clone the repo and run the install strip with --all flag to configure bash and extras.

For ripgrep donwload binary and manually copy binary and completion files to their proper place depending on your OS.

Use fzf and ripgrep in vim

You can see above in the editor section, how I add the fzf plugins in vim using vim-plug. There are two plugins, one applies basic support (fzf) while the other (fzf.vim) adds some nice functions for using deeper in vim, for example to search buffers or tabs.

Add the following environment variable to your ~/.bashrc, or ~/.fzf,bash to configure fzf to use ripgrep by default.

export FZF_DEFAULT_COMMAND='rg --files --hidden --follow'

My fzf file search will then use ripgrep to find the files by filename. I map <Leader> p to open using fzf: map <Leader>p :Files<CR> See the benefit of fzf illustrated below, it helps even misspellings.

You can also use fzf to search open buffers, hat tip to Ian. I map ; to search buffers using fzf: nmap ; :Buffers<CR>

To use ripgrep to search inside of files in vim, I map <Leader>f to call the fzf vim provided function :Rg to perform the search.

Configure fzf in Command-line

All this searching and opening files in vim is pretty nice, let's do the same in the command line. By adding the following to your ~/.fzf.bash you can use fzf when using ctrl-r to search bash history.

bind -x '"\C-p": vim $(fzf);'

The above also maps ctrl-p to search for files and open in vim, ctrl-p on the command-line, WUT?

Search & Replace

Another common task of an IDE is multiple file search and replace. Unix has so many utilities working with text, there is no shortage of options. I tend to use the trusty sed command. It works across one or multiple files as you would expect.

sed -i 's/old/new/' file

Build, Test, Lint

There is not much to comment on building, testing, or linting. These are all command-line tools which the IDE abstracts and integrates in. If you work on the command-line, no abstraction required.

My tip is to create scripts to make it consistent and easy on yourself when switching between projects, Makefiles work well here, or whatever tool you like. So you can just run make build or make test in each of your projects.

Source Control Integration

Source control integration is the same as above, command-line tools. I simply use them as is. Removing the layer of abstraction helps prevent errors, and insures you do what you intend. This may require learning the tools a bit more; but source control is critical to software development, you should know how it works.

When working in Git, I like seeing the current branch I'm working in. I configure it to display in my prompt. I use the __git_ps1 function, which echos the current branch or nothing if you are not currently in a git repository.

An example of a basic bash prompt displaying the current git branch:

PS1='$(__git_ps1) $ '

My prompt is a bit more complex, which you can see in my dotfiles here. If the __git_ps function is not found, you may need to source it. See this reference documentation for more.


An IDE usually has panels that are configured into a workspace. It might have a file browser on the left, editor in the middle, maybe a panel on bottom or right. I use tmux as my way to setup and extend my workspace. You can even start tmux with a given configuration and commands.

Tmux gives you an almost unlimited workspace that you can configure however you wish. Create more tabs to keep a build-watch process running, open up more terminals to search or edit, create split windows to monitor performance. Whatever you need you can set it up.

Another valuable tool that I use to navigate through my workspace is autojump, a utility that allows you to quickly jump to any directory by simply typing j <str> where the str is any partial directory name. It navigates by recency so is almost always just what you want. Autojump is available in most package repositories.

Last tip, if you are working on a certain set of files over and over again, write a little script to open them all up. A quick way to get going, for example:

vim blocks/library/gallery/* blocks/library/index.js


As you can see, the command-line provides a rich set of powerful tools, which for me replaces the need for an all-in-one IDE. It really is the Unix way, simple powerful tools for each job.

Check out my dotfiles to see my config files, or my command-line basics and tips for more CLI goodness.