About this blog

It's been just a year since I started this blog. My first post was "Top Ten Rules for Using Ports system". So, it seems like as good a time as any to write this post -- which probably should have been the first post. :)

FreeBSD is not only a secure, reliable, high performance operating system, it is one of the best documented open source projects I've ever encountered. From the handbook to the man pages, as long as you know the question you can usually find the answer, and that answer will be clear and thorough. There's also a great community to ask questions, from BSDForums to the Projects's own mailing lists. So, why should I write this blog, when my main subject is tips and advice for FreeBSD users?

I think there's a gap, mainly around the caveat "as long as you know the question." When you're new to unix and FreeBSD you often don't know the question. I've contributed to community based Q&A type help, but sometimes you find something interesting beyond the usual questions that you'd like to share. And, there's just so much stuff out there, so many possibilities, so many different ways to do things. Even experienced users are always learning and finding new things.

I'm not a FreeBSD developer. I consider myself to be an advanced user, though. Still I'm far from the most knowledgeable user around. I think (I hope!) that I'm able to write about these subjects clearly and thoroughly, giving the beginner just enough information to know where else to look and complete the task, while being brief and focused enough to remain interesting and informative to an advanced user.

FreeBSD has given me alot and it's fun to help other people find solutions and discover some of the many things that are possible. That's the heart of this blog: tips, advice, and how-to's for the FreeBSD user. While I'm at it, I will mix in the occasional opinion post and posts on other technical subjects.

Make "Home" and "End" keys work

There was an article linked in the press section of the FreeBSD site that mentioned something pretty cool. It in turn linked to another article with lots of details. More details than suit me frankly. :p But, darned useful nonetheless.

If you have to switch back and forth between W1ndows and Unix often, as do I, you may sometimes reach for a key that doesn't work as you expect it to (or at all). Sometimes when I'm in a hurry I start typing vi commands while writing an email in Outlo0k. It doesn't work. (Too bad, because when you're editing in a hurry, vi commands are what you want!) Well, getting vi or vim to plug in as the editor for Outlo0k will have to wait for another day. :) But, there are some keys that have been non-functional for me on the Unix command line. Now, I've got them back.

Like I said, the above-linked article by Anne Baretta has a ton of details. She talks about settings to enable some of these keys in X, tcsh, KDE, and more. I just scanned down to the part on bash and found what I needed. Namely, you can get the "Home", "End", and "Delete" keys working as expected on the command line in bash by creating a file named ".inputrc" in your home directory that contains the following:

"\e[1~": beginning-of-line
"\e[4~": end-of-line
"\e[3~": delete-char

As far as I can tell, you'll have to log in again to make it effective.

Wait, there's more! The article mentioned the "Ctrl-v" trick: You hit Ctrl-v and then another key or key combination and then it will show you the escape sequence that gets sent to the shell. Using that trick I discovered that the escapes for "Ctrl-LeftArrow" and "Ctrl-RightArrow" (yeah, more W1ndows lapses) and then mapped those to the appropriate bash readline commands. Just add these two lines more to "~/.inputrc" and you'll be in business with the word hopping arrows:

"\eOD": backward-word
"\eOC": forward-word

I'm in switch-hitters heaven. Furthermore, none of these bindings override the ones that were already there. That is, "Ctrl-A" still goes to the beginning of the line too, and "Alt-F" still hops the cursor forward a word, etc.

Update: Commenter Eddie led me to an interesting article at 'nixCraft' on the same subject. Playing around, I found some interesting things. First, the codes above don't work correctly in all situations!! I was doing that through ssh/PuTty. On a regular terminal, these are the codes that worked right for me:

"\e[7~": beginning-of-line #home
"\e[8~": end-of-line #end
"\e[3~": delete-char #delete
"\eOd": backward-word #ctl-leftarrow
"\eOc": forward-word #ctl-rightarrow

Secondly, if you're on a machine with multiple (command-line) users, then it makes little sense for everyone to have to create the same "~/.inputrc" file. You need only create one file with those readline settings in it, I suggest "/usr/local/etc/inputrc", and then point everyone to it by putting this line into "/etc/profile":

export INPUTRC='/usr/local/etc/inputrc'

Dumb Partition Scheme

I've written before about what I think is a good way to layout your partitions. Now I want to show a bad way! This is from an actual, FreeBSD, dedicated server that someone I know rented. (The provider shall go unnamed ... to protect the guilty.) Let's look:

$ df -h -t ufs
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a    6.6G     79M    6.0G     1%    /
/dev/ad0s1e    965M     20K    888M     0%    /tmp
/dev/ad0s1f    9.5G    2.1G    6.6G    24%    /usr
/dev/ad0s1d    6.6G     63M    6.0G     1%    /var
/dev/ad0s2     9.0G    6.1G    2.2G    73%    /usr/home

The big problems here are wasting all that space in the root partition and then dividing the /usr partition. (I won't complain about the size of /var, since it was meant to be a server; or having a separate /tmp since that is still a common practice.) But, the icing on this cr4p cake is the home partition. It wasn't bad enough to just put it on another disklabel partition, let's put it on it's very own slice! (a.k.a. DOS partition)

I'm still awfully glad when any place offers FreeBSD as an option on the dedicated servers. I don't know if this place does any better laying out the disks for the other OS's. But, it's often useful (and sometimes amusing) to have a bad example. :)