/bin/zsh configurations

# vim bindings on the command line
bindkey -v

# color-coded ls output
alias ls=’ls -G’

# interactive rm
alias rm=’rm -i’

# http://www.zsh.org/mla/users/2005/msg00298.html: If a file reference cannot
# be expanded locally, this setting suppresses the no match error message and
# passes the ambiguous file reference as an arguement to the application.
setopt NONOMATCH

# -g option indicates an inline alias that can be used anywhere in the command
alias -g ocf=’ekashida@ocf.berkeley.edu’ # e.g. ’ssh ocf’

/bin/bash configuration

# IBM has a good mini-tutorial on how to customize the bash prompt

# setting up a custom prompt
blue=’e[0;34m'
green='e[0;32m'
white='e[0m'

export PS1="[${blue}]t [${green}]h[${white}]:[${blue}]W[${white}]$ “

alias rm=’rm -i’
alias cp=’cp -i’
alias mv=’mv -i’
alias ls=’ls -G’

# & supresses duplicate entries
# [ t] doesn’t record any commands with a preceding space
export HISTIGNORE=”&:[ t]*:ls:[bf]g:exit”
export HISTSIZE=1000
export EDITOR=/usr/bin/vim

Subversion and CVS

Some facts I dug up while looking up differences between SVN and CVS:

• Subversion enforces atomic transactions while CVS doesn’t. For example, if you were checking in multiple files and one of them had conflicts, CVS would allow you to commit everything except for that one file. You would then need to resolve that file’s conflicts before it can be committed. In this way, a single, logical commit may be broken down into two.
• CVS was originally intended for versioning of text files and so versioning of other files types (Unicode, binary) is non-trivial.
• Subversion works faster than CVS overall (at the expense of a full backup).
• Subversion was architecturally designed with future growth and expandability in mind, whereas CVS grew in an experimental manner. Unsurprisingly, this makes CVS difficult to grow in terms of functionality.

The pros and cons of SVN and CVS can be argued all day, but for me, the last point tips the scale in favor of SVN.

Screen Multi-user Mode

Suppose Bob wants to show Alice what he’s doing in his console remotely. Bob would do the following:

1. Bob would make sure that the screen binary is suid root (sudo chmod +s /usr/bin/screen on my system).

2. Bob starts screen:
screen -S <session_name>

3. Bob allows multiuser access:
^A :multiuser on

4. Bob adds Alice to the access control list:
^A :acladd alice

5. Bob then changes Alice’s permissions to read-only:
^A :aclchg alice -w "#"

6. Alice will then ssh into the machine and:
screen -x bob/<session_name>

That’s awesome.

Notes:

• People can join your session even if you skip acladd and just do aclchg, but they won’t be able to detatch. Weird.
• ^A * lists all participating users (as does ^A :displays)
• Anybody in the session can broadcast a message by typing ^A :wall <message_text>

Good Times

nmap -T 5 -M 1000 -sT 192.168.0.x

Setting up Vim bindings for Pine

Edit the .pinerc file:

editor=vim

Start up pine.

Hit ’s’ for setup

Hit ‘c’ for config

Select the following two preferences under “composer preferences”:

enable-alternate-editor-command

enable-alternate-editor-implicitly

When you start up pine, you’ll need to ^n ^p to move around the upper portion of the email, but once you enter the body, you can now use vim!

Buggy Screen

So I was using screen on my newly installed Dapper when I find that backspace is having an identity crisis.

When I hit backspace on the command line, it says “wuff wuff” and I need to ^h to delete.

Fine. I can live with that. However, neither backspace nor ^h works while editing files in Vim.

I can’t live with that.

The solution I found was to alias the screen command to set the TERM variable to screen before running screen:

alias screen=’TERM=screen screen’

I don’t know why that works, but it works beautifully.

Ignorance IS bliss!