If there’s one thing you can do right, it’s setting up your local console environment. Casual users typically don’t have to replace their computers every few years; but developers tend to upgrade every year and half or so (if budget permits). There’s other reasons for placing your shell environment under version shell; in my case, for using it in virtual machines, remote serves or if you nuke your system.
I use quite a lot of junk, to be honest. For example, whenever I go somewhere new and connect to their network, I rename the network to someone more friendly in my SSID list in KDE.
That makes it a bit more friendly when the notification alerts whenever I connect to a network. In the console, however, my shell is strictly Bash (for now). All of my Bash configuration scripts and goodies can be found at my dotfiles repository, but here’s a quick run down.
Frameworks are awesome, no? Well, some are. Some we can live without. In this case, the bash-it makes it way too easy to get an awesome Bash setup with minimal effort. I use it to add a lot of functionality like automatic rbenv and nvm integration as well as git extensibility and a bit more. Whenever I open my terminal, I’m greeted with this:
Using frameworks allow you to get a working system as soon as possible, but
it’s recommended probably by every living developer on the platform that you
absolutely go ‘vanilla’ when you’re using a framework. Tweak the shit out
of it. Make it your own.
bash-it comes with a lot of plugins, completions
git in your console then a space then tab. that’s completion
magic!), and aliases for Bash.
I recommend taking a look at Nettuts’s tutorial on Bash and how to configure it to your will.
Let’s take a closer look at what’s going on here.
From that extra zoomed shot of my Konsole session, you can tell the following:
I’m running as user “jacky” on machine “neuromancer” (my laptop). This is useful when I switch local users on my machine from
I’m using ruby 2.0.0 thanks to the globally set version of
rbenv(as noted by ❖ 2.0.0-rc).
I’m in my
$HOMEdirectory (as noted by
The last process run exited successfully (as noted by ` ☷ `).
This Bash-it theme is available in my fork of bash-it, it’d require another tool for version control,
vcpromptto be available in your $PATH. Now, let’s say I wanted to start hacking on Wintermute. This is what I’d do:
Some of the actions may not be visible there, but I was able to quickly ‘jump’
~ to the location of my copy of the sources of Wintermute (about three
folders deep) with less than 10 ten keystrokes thanks to fasd. Also,
with a bit of editing to my ~/.inputrc, past commands I’ve executed for
opening Vim were available just by pressing up; time saving.
Pick your Rodeo
The tool I’d recommend for such an endeavor is
homeshick. It’s a
Bash implementation of the Ruby gem homesick. It does take a bit more
time to set up than its Ruby counterpart, but consider this: if you have to
install Ruby on a new system, install
homesick and then use a local tool for
handling Ruby versions like rbenv or rvm, then why bother installing
system Ruby? It looks like a chicken and egg (or rather rooster and hen)
situation. Install this tool to your local system by executing the following (or
by following the official instructions):
Slicing Up Configuration
At this point, you can begin dicing up your configuration in your local system into smaller parts. For example, I keep my Vim configuration separate from my central configuration out of habit. As prescribed by the docu
but doing this can make some files you use inaccessible by your user account.
Very bad practice. I only do this to use certain aliases and what not, ↩