The Unix way... or why you actually want to use Vim

David Wickes on November 09, 2018

I like all the Vim tutorials on Dev.to. They're great! They're good starting points. Please go and read them all! But... I'd like to tell you all... [Read Full]
Editor guide
cat /usr/share/dict/words | grep bob | shuf | head -1 | \
  parallel open https://en.wiktionary.org/w/index.php?title={}

The (notionally) more portable β€” and less abusive of felines β€” method would be something like:

grep bob /usr/share/dict/words | shuf -n 1 | \
  xargs -I {} curl https://en.wiktionary.org/w/index.php?title={}

Thankfully, shuf lets you limit the amount of lines output ...meaning you can save yourself the scads of resources of calling head! =)

Or, if you want to avoid helpers like xargs or parallel altogether:

curl "https://en.wiktionary.org/w/index.php?title=$( grep bob /usr/share/dict/words | shuf -n 1 )" 

If you're going to abuse a cat, do so by trying out multiple skinning-methods. =)


All very true, and very good!

If you're going to abuse a cat, do so by trying out multiple skinning-methods.



What I tend to use more often than :%! is to actually highlight a number of lines using V (visual line) and then apply an operation by simply typing : and then ! (vim automatically inserts the range specifier '<,'> for you), followed by your command. I typically do this with sort to arrange import sections in particular.


Yup - me too. And a quick look at :h ! will show you how to pass through motions and line ranges to an external program.

The possibilities are ... well, not endless. But there are a lot of them.

If you enjoy doing this sort of thing, you should really take Acme out for a spin.


Saying "the possibilities are finite!" is more accurate but less fun.


Another thought: although find implementations can be bloated with extra functionality, they always play nicely with pipes. That's the one rule that nobody wants to break, because it's so damn useful!


I think you might be looking for the second part of the Unix philosophy:

Write programs to work together

Composition is important... but reading

I always google before using find. But it is a powerful tool. For simpler tasks, I just use ls -1 GLOB or ls -1 | grep PAT.

One task where find really helped was finding and removing broken symlinks in a directory with over 10 million files.

I start to wonder whether the whole 'do one thing' idea is good because it's easier to remember the 'one thing' program's simple and focused interface, and so compose it with other 'one thing' programs, than it is to remember the large and complicated interface of things like find.

Because I also have to look up how to use find every time I have to use it - but the piping of ls to grep is intuitive.

In other words, in order to get all the benefits of composition, don't you need the simplicity of 'do one thing'?


I always google before using find. But it is a powerful tool. For simpler tasks, I just use ls -1 GLOB or ls -1 | grep PAT.

One task where find really helped was finding and removing broken symlinks in a directory with over 10 million files.


Great article, showing an entire extra dimension for capabilities of a good editor.

RE the Emacs example, let me explain for posterity. This may look scary:

C-x h C-u M-| js2json

But it's actually built out of commands Emacs regulars would know well.

  • C-x h means "select all" (more accurately, the mark-whole-buffer command).
  • C-u is a "prefix argument", applying to the next command you issue; it's something used frequently.
  • M-| is shell-command-on-region; it'll take what you selected and pipe it into a shell command. Without a prefix argument, the output would end up in another Emacs buffer; with a prefix argument, it replaces the selection.

(And, of course, C-x is "control + x", M-| is "alt + |" in Emacs-speak.)



Many Unix programs have deviated from the 'Unix philosophy', the best example being cat which is rarely if ever used to concatenate files any more.

Take a look at cat -v considered harmful where Rob Pike writes very well about this.


What do you mean by this?

Unix Philosophy is very similar to Functional Programming philosophy. They overlap in many ways e.g. small programs vs small functions, do one thing vs pure (no side-effect) functions etc. However sometimes overall productivity both short and long term as well as efficiency is better if we not primitively and blindingly follow the utopic idea (Unix-way or FP). Example: vim follows Unix-philosophy and VSCode (or WebStorm etc.) breaks it. The former while it is a cool concept, generally is inefficient because it has a very, very steep learning curve. Regarding FP: Haskell and friends are generally less efficient than JS because you have to become a f***ing (sorry, I lack vocabulary to express myself) mathematician to start gain something from it.

While I generally love the Unix (and FP) Philosophy, it should be taken with a grain of salt (i.e. applied to appropriate problems e.g. low-level programs), just like any idea.

You are talking about a purely functional language. The paradigm itself is way easier to get into, is just a matter of wanting to learn something. Simple as that. Functional programming doesn't need to be understood just by mathematical references.
And then you go and say "I love" ? Really?


Thanks for the tutorial! Made me seek whether there's an extension (atom.io/packages/pipe) for Atom which could enable the same way of thinking, and I think I found one which I plan to try soon.


Vim is great because it's everywhere - if you know Vim/vi then you've got an editor on most Unix systems you can use.

Yes, this is like saying that Javascript is the best programming language that runs in the browser. While it's true, it tells us nothing about the quality of Javascript's design (or lack thereof in many aspects).

I would argue against using Vim to preach the Unix philosophy for non-believers. It could backfire, and rightly so.

Vim gets a special pass because it's a fascinating part of computer history. But if it was invented today, nobody would be insane enough to use it.

Really, users should not have to try hard to understand a piece of software. We understand today that it's the software that has to try hard to understand its users.

The Unix philosophy is great though! But it is about having simple core concepts that you can combine ad nauseam. Your paragraphs on pipes is a much better illustration of it!


Not a bad point, but I think you're a little mean to call the most popular editor for sysadmins/devops a 'part of computer history'. It's still pretty popular for web developers.

So... I lay down a challenge to you: can you name another editor which has a similar command to call out to the shell and replace the current buffer/file with the contents? i.e. I can extend the editor using external programs.


I have various ways to do that in Jetbrains IntelliJ, like this one

Reading again my comment, it's true that my tone was a bit mean. I used vim a lot and found it fascinating. I think we have better tools now, but that's not vim's fault, that's progress.


If you are interested about Vim's history, this link is your friend.

Good writing BTW


That's a nice piece - thanks. Just read his piece on Lisp which I thought was very well put together.


[...] which I thought was very well put together.

Why ?

Since you ask...

  • good entry point; starts with xkcd jokes and moves from there.
  • three good and relevant headings - McCarthy's origination, the AI boom (and winter), and Scheme and SICP. They felt natural, and ran on from each other well.
  • well referenced and researched - above and beyond most articles

I see, I thought you refer to put together with the Vim's link, my bad english background ! That was I asked you, but thanks for your response, I'm going to read the Lisp's link... and of course, I'm agree with "well referenced and researched"


It sounds like what you really want is acme, not vi.


Yup, acme is the ... well, it's the acme of this idea. My only personal issue with it is the mouse, but that's probably practice.


cat cake

Hmmm... never realized that cat takes more time!

That said, where he goes:

$ time grep bob /usr/share/dict/words > /dev/null

real    0m0.005s
user    0m0.002s
sys     0m0.002s

I prefer:

time grep bob < /usr/share/dict/words > /dev/null

real    0m0.005s
user    0m0.002s
sys     0m0.002s

But I'm not sure why. It's either because I don't have to remember where to put the file argument to grep. Or because it's my go-to 'save a cat' today technique. Or because I'm pretentious.


</usr/share/dict/words> is the most frightening closing tag I think I've ever seen.


I think the most important part of living up to the Unix philosophy is abiding by the core tenet: text is the universal interface.


Looks nice in my blogsite. Or in short, simply show off.


aaaaaand this is why people who know shell and powershell ALWAYS win at code golf. This is also why shell and powershell should ALWAYS be barred from use in games of code golf. The end. :D :P


This was a great read for my morning commute! I didn’t get a chance to try the %! Shuf command (on mobile), what does it do?


Change the order of your lines in a random way

Code of Conduct Report abuse