briancarper.net (λ) (Tag: Dotfiles)

Vim joy, Lisp woes

Thu, 15 May 2008 00:17:11 -0700

I symlinked my .vimrc to my local mirror of my website so that every time I rsync it (which is pretty often) it'll automatically update my the vimrc on this server. So that should be fun. I experiment with things in there all the time so at any given moment there are likely to be things horribly broken, but maybe someone can use some of it.

This mirror of Ciaran McCreesh's vimrc which I found linked from here (edit: updated version here) has lots of good stuff in it. In particular using :set listchars to display tabs and trailing whitespace as some funky Unicode characters is a really good idea. When I first tried that good idea I realized my favorite font ProggySquare didn't properly display most Unicode characters, which was part of my motivation to switch to Terminus. (That, and those tiny Proggy fonts aren't so great on a 1920x1200 monitor.)

After a long time putting it off, I finally hunkered down one day and figured out how the heck Vim script works. The difference between statements and expressions in Vim script language confused me for a while, which goes to show that I'm far too used to Ruby and Lisp where almost everything or everything returns a value as an expression. Vim expects expressions in certain places and colon-prefixed commands in others. But then there's normal and eval and execute and "= some of which let you do things from one mode in another mode if you mix and match them. But I think I've gotten a handle on it now.

Today I came across Limp which is a recent attempt to get Lisp to work well with Vim. It seems quite new and buggy and had dependencies on things I had to guess until I was able to install it (like rlwrap), but I still was excited about it. Until I realized that it's just a wrapper around GNU screen. SBCL runs separately, and some keystrokes send stuff from Vim to screen, but that's about it. Nice, but not nearly as nice as SLIME in Emacs. So that disappointed me. In the back of my mind I always think about how Vim could possibly be integrated with Lisp like SLIME does but I don't see any good way. Vim doesn't have the ability to embed shells like Emacs and it doesn't look like it will gain that ability any time soon. Ah well.

Keeping bash history in sync on disk and between multiple terminals

Fri, 14 Sep 2007 14:55:13 -0700

I rely on my ~/.bash_history extensively to avoid retyping things, both short-term and long term (when I want to look up something I typed yesterday or last week).

First, an obvious necessity is

shopt -s histappend

in ~/.bashrc, so that bash just keeps on adding to the end of the ~/.bash_history file rather than obliterate the file at regular intervals.

By default, bash reads from your ~/.bash_history once when you log in to a terminal, and it updates ~/.bash_history once when you log out. I dislike both of these default behaviors.

Writing out to ~/.bash_history only when you log out is no good, because what if your terminal dies unexpectedly? You'll lose the history of any commands you typed there. This can happen if you kill a bash process, or if the machine powers off unexpectedly, or who knows what. So, to manually update your ~/.bash_history immediatety, at any time you can use this:

history -a

which tells bash to append to ~/.bash_history any commands in the current terminal that aren't already in there.

The second behavior of bash I dislike is that it reads from the history file only at login, mostly because I always have many terminals open at once. I run a command from one terminal, then run a different command from another, switch back and forth etc. These terminals may be appending all kinds of nice new lines to the end of my ~/.bash_history, but because bash never reads the history file except at login, they're never accessible except in the terminal where the command was originally run. Luckily you can force bash to re-read your history file via:

history -n

which tells bash to read any new lines that have appeared in ~/.bash_history since the last time it looked.

Now, say I type a really long command, e.g. a huge long Perl one-liner, in one terminal, and I want to then access and run that command in another terminal via bash history. With bash's default behavior, I can't do it; each terminal has its own history. What I could do is type history -a in the first terminal, and history -n in the second terminal; then it'd work wonderfully.

I find the thought of having to do that all the time tedious, though. Better would be for bash to do it for me every time I run a command. You can accomplish this by putting something like this in ~/.bashrc:

export PROMPT_COMMAND="history -n; history -a"

PROMPT_COMMAND lets you specify a command that bash will run every time it shows you a fresh command prompt, i.e. every time you run a command and the command finishes. So the above tells bash to read any new lines that have appeared in ~/.bash_history since the last time it read it, and then append the last-run command from this terminal to ~/.bash_history, every time you run a command.

So now, if you type a command in one terminal, and want to access it via the history of another terminal, run a command in the other terminal (or just hit Enter) to trigger PROMPT_COMMAND, and then your history will be nicely up-to-date and synchronized with any other terminals you have open. Almost certainly, you'll never notice the tiny bit of overhead caused by bash constantly reading and writing to ~/.bash_history.

See man bash for more info on the history builtin.

HISTIGNORE

Sun, 01 Jul 2007 12:05:56 -0700

HISTIGNORE is a handy bash option. You can specify certain strings that you want bash to ignore when storing command line history in ~/.bash_history. For those using sudo, you could automatically prevent bash from saving any of your run-as-root commands in your history. Or you can prevent it from storing exit or fg or sundry ls any other such commands that aren't worth remembering.

Darn you, failglob

Sat, 05 May 2007 20:14:34 -0700

I turned on bash_completition today. Couldn't quite remember why I had it turned off. I quickly realized though. bash would fail on any filename with a square-bracket in it. It looks something like this:

~ $ touch 'test [1]'
~ $ ls<I HIT TAB HERE> bash: no match: test [1]
~ $

In other words, hitting TAB to tab-complete filenames would dump me back to a command prompt giving me that unhelpful error message, and I'd have to start the whole command over.

The problem was that I had this in my ~/.bashrc:

shopt -s failglob

I can't for the life of me remember why that was in my .bashrc. Clearly it wasn't doing anything I never had any use for, because this is the first time I got this "bash: no match" error. Removing that line makes bash_completion work again though, so all is well.

This was a nightmare to debug too. Google was totally useless. I tracked it down to the _filedir function in /etc/bash_completition, and then it was trial-and-error. Next time I'm going to start off loading a clean login environment before I bother checking the system scripts for things. I did also learn that set -v in a bash script makes it dump every line it executes to STDIN as it's executing them.

~/.inputrc

Mon, 20 Nov 2006 19:02:12 -0800

I have posted my old Gentoo inputrc largely so I don't lose it. The one that comes with Ubuntu sucks. This one fixes PageUp / PageDown to scroll through bash history. And it fixes the Delete key to delete rather than belch out a ~. I don't understand why these things aren't fixed by default on all distros. Is it backwards compatibility? Are there really enough people using keyboards without a Delete key that the rest of us should suffer? Or maybe I'm missing something, which is very possible.

.vimrc

Wed, 19 Apr 2006 20:58:20 -0700

I've uploaded my .vimrc file, mostly so I can have access to it next time I'm stuck on some strange unknown box somewhere. I always find myself needing it and then trying to re-type the whole thing from memory.

GDM and .xsession

Thu, 23 Mar 2006 17:47:20 -0800

I finally figured out how to get GDM to recognize my ~/.xsession. I had to go read /etc/X11/gdm/Xsession and see what it was doing. It's testing -x for ~/.xsession, which is what I was missing. So

Make a `~/.xsession` and `chmod u+x` it.
When you start GDM, select "Custom Session".

Then it will work. This is necessary because openbox doesn't provide any kind of startup feature. (PS I'm trying openbox now. Screenshots coming soon.)