A Weird Imagination

Encrypted files in Vim

Posted in

The problem#

There's a handy Vim plugin openssl.vim that allows you to easily edit encrypted files with Vim simply by giving the file an extension like .aes. Then Vim will ask for a password upon loading and saving the file in order to decrypt and encrypt it with openssl.

Unfortunately, the plugin was last updated in 2008 and makes some assumptions about openssl's defaults which are no longer valid. The most pressing issue is that the plugin now outputs a warning message when encrypting. By itself, that's worrisome, but, worse, that warning message gets output into the file along with the ciphertext. Needless to say, the resulting file cannot be decrypted without manually removing the warning text.

The solution#

Simply fixing the options the script passes to openssl is a good start, but I also wanted to make sure any files encrypted with the old settings could be decrypted. My updated openssl.vim1 does both in addition to fixing some other annoyances.

The details#

Read more…

Useful vim plugins

Posted in

Vim plugins#

The real power of Vim and the other text editor comes not from their complicated key combinations, but their programmability. Vim uses its own language Vim script while Emacs uses a dialect of Lisp called Emacs Lisp. Both have large communities who have authors many plugins.

A great source for Vim plugins is [Vim.org][vim-scipts], which also has a wiki about Vim with additional information on some of the plugins and lots of tips on how to better use Vim.

Plugin managers#

While, Vim does have basic support for plugins via .vba files, also known as vimball archives, it's easier to use a plugin manager. I recommend Vundle, which is easy to install and use.

Read more…

Making :w work everywhere

Posted in

The problem#

After using Vim as my primary editor for a while, I find myself trying to use vi-style keyboard shortcuts in other contexts. Usually resulting in :w in middle of whatever I was writing as saving is a natural thing to do when pausing.

There's a few ways to fix this:

  1. Get used to the fact that not everything supports vi-style keyboard shortcuts.
  2. Change the keyboard shortcuts of the programs I do use.
  3. Use Vim for everything.

The first option is suboptimal because vi-style keyboard shortcuts are very useful. Luckily, in many cases there's ways to get them.

Read more…

256 color terminals

The problem#

By default, terminals on Linux only use 8 colors (or 16 if setup to use bright variants instead of bold text). Everything else on a modern computer uses 24-bit color, allowing for millions of colors. More colors in the terminal would allow for better syntax highlighting and color output of various commands to be more readable.

In practice, while a few terminals support full 24-bit RGB color (at least Konsole does), it is not widespread enough to be used much. On the other hand, most terminals support 256 colors, which is significantly better than just 8.

Read more…

Checking for unsafe shell constructs

Posted in

Filenames are troublesome#

While shell programing lets you write very concise programs, it turns out that the primary use case of working with files is unfortunately much harder than it seems. That detailed article by David A. Wheeler does a good job of explaining all of the various problems that a naive shell script can run into due to various characters which are allowed in filenames which the shell treats specially in some way.

One surprising one is that filenames beginning with a dash (-) can be interpreted as options due to the way globbing works in the shell. Suppose we set up a directory as follows:

$ cat > -n
Some secret text.
$ cat > test
This is a test.
It has multiple lines.

Quick, what will cat * do here?

$ cat *
     1  This is a test.
     2  It has multiple lines.

Probably not what you wanted. The reason that happens is that the * is expanded by the shell before being fed to cat, so the command executed is cat -n test and -n gets interpreted not as a filename but as an option telling cat to number the lines of the output.

The workaround is to use ./* instead of *, so the - will not actually be the first character and therefore will not get misinterpreted as an option. But there are many other things that can go wrong with unexpected filenames and remembering to handle all of them everywhere is error-prone.

Warnings for unsafe shell code#

The solution is shellcheck. shellcheck will warn you about mistakes like the cat * problem and many other issues you may not be aware of.

As I have many shellscripts around that I wrote before learning about shellcheck, I wanted to run it on all of the shell scripts (but not binaries or other language scripts) in my ~/bin directory, so naturally I wrote a script to do so:


find -exec file {} \; \
    | grep -F 'shell script' \
    | sed s/:[^:]*$// \
    | xargs shellcheck

This uses the file command to identify shell scripts and then selects out their file names to run shellcheck on all of them using xargs.

Warnings in Vim#

shellcheck is written to support integration into IDEs. I use Vim to edit shell scripts, so I installed the syntastic (using Vundle which makes installing Vim plugins off GitHub very easy). Note to follow the instructions on the Syntastic page, specifically the recommended settings: without any settings it won't do anything at all. Once set up, it automatically runs shellcheck on every save, identifies lines with warnings and shows a list of warnings that can be double-clicked to jump to the location of the warning.

If you use the other text editor, then the shellcheck website recommends the flycheck plugin.