I wrote a few months ago about envbox, and I can say that it has proved useful to me many times over. One thing that felt unfinished was the way that envbox stores the key that it uses to encrypt all of the environment variables. It did move the problem from the shell/history to one of system security, which was acceptable. But there are better ways of storing credentials on most systems.

When I’m in front of a computer, I spend much of my time at the command line, logged into various systems, running commands. Now, there are two basic categories of commands: Commands that change - install a package, add a firewall rule, restart a service Commands that report - list installed packages, list firewall rules, list running services This post is about making the second category of commands more useful. Quite often, those commands have copious amounts of output.

In my day to day work and evening and weekend side work, I do most almost all of my development working on remote systems. This has a number of advantages that are for another post, but this post is about one of the limitations. Most developers have a tool belt that they’re continually improving, and as I work on mine I come across commands - like hub that require1 putting a secret value into an environment variable, usually for authentication.