sonia hamilton – linux, brazilian jiu jitsu

6 November 2011

ssh – DISPLAY is not set – Failed to allocate internet-domain X11 display socket

Filed under: Uncategorized — Sonia Hamilton @ 20:14

A little ssh error I came across while trying to work remotely on an Ubuntu machine. ssh X Display Forwarding wasn’t working, and I was getting an error:

DISPLAY is not set

Digging through /var/log/auth.log, I also noticed this error:

Failed to allocate internet-domain X11 display socket

After much Googling, it seems that IPv6 was causing the problem. It was solved by adding:

AddressFamily inet

to /etc/ssh/sshd_config, and restarting the ssh server.

20 October 2011

reload mutt configuration

Filed under: Uncategorized — Sonia Hamilton @ 15:14

To reload your mutt configuration (for example after editing muttrc):

:source /path/to/muttrc

For example:

:source /home/sonia/.muttrc

4 October 2011

RFC 1178 and server naming

Filed under: Uncategorized — Sonia Hamilton @ 15:20

Whenever I come across servers with names like chpvuat01, I’m reminded of RFC 1178 “Choosing a name for your computer”. Especially when ch stands for crack house, pv stands for paid verbiage, but uat doesn’t stand for user acceptance testing: the box used to be in UAT, was moved to SIT (System Integration Testing), but kept it’s old name because renaming it would be too hard…

From the RFC:
Using a word that has strong semantic implications in the current context will cause confusion.
Don’t choose a name after a project unique to that machine.

Name machines after D&D characters, LOTR characters, planets, flowers, animals, whatever, but not their function!

(Hostname has been obfuscated to protect the not-so-innocent, though the project may as well be called crack house).

27 September 2011

Midnight Commandar mc notes

Filed under: Uncategorized — Sonia Hamilton @ 10:28

Midnight Commander (mc) is mostly obvious, but there’s a few things a regularly forget and have to look up.

  • to select (or “tag”) multiple items, use the Insert key, or ctrl-t (eg when on a Macbook)
  • any sort of compressed or package file (.deb, .tgz, .iso, .rpm, etc):
    • F3 (view) to get an overview of the package
    • Enter to browse the package contents, then eg F3 to view the file or F5 to copy the file out
  • to jump back and forth to the command line (“subshell support”), use ctrl-o to hide mc, then ctrl-o to return from the subshell to mc

Taken from Jane Tembath’s MC Tutorial. See also the mc faq.

13 September 2011

git patch add

Filed under: Uncategorized — Sonia Hamilton @ 11:04

My new favourite git option:

    git add -p

It’s like doing an interactive add, then choosing ‘p’ for patching. From the manual:

       -p, –patch
           Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to
           the index. This effectively runs add –interactive, but bypasses the initial command menu and directly jumps to the patch subcommand. See “Interactive mode” for details.

30 August 2011

Ruby, blocks and procs

Filed under: Uncategorized — Sonia Hamilton @ 13:15

Some notes on ruby, blocks, and procs.

Manually creating blocks

Ruby has three ways of manually creating blocks:, lambda, and proc. They have slightly different behaviour, and the behaviour also varies between Ruby 1.8 and 1.9!

  • lambda checks that the number of arguments passed matches the number of block parameters
  • whereas doesn’t check (however the block may raise an error, depending on it’s code)
  • and proc behaves like lambda in Ruby 1.8, and like in Ruby 1.9. So, avoid using proc!

A bit of code to demonstrate this:

multiplier_l = lambda   { |a, b| puts "a * b is: #{a*b}" }
multiplier_p = { |a, b| puts "a * b is: #{a*b}" } 3,4,5 )
ArgumentError: wrong number of arguments (3 for 2) 3,4,5 )
a * b is: 12
> 1 )
TypeError: nil can't be coerced into Fixnum            # in this case, Proc handled one param, but block errored

And now using rvm to switch between Ruby versions:

=> "1.8.7"
multiplier_p = proc { |a, b| puts "a * b is: #{a*b}" } 3,4,5 )
ArgumentError: wrong number of arguments (3 for 2)

=> "1.9.2"
multiplier_p = proc { |a, b| puts "a * b is: #{a*b}" } 3,4,5 )
a * b is: 12


In Ruby 1.8, block parameters can overwrite parameters of the same name in the current scope; in Ruby 1.9 they’re protected.

> hello = "hello"
> def frenchy
>   x = "bonjour"
>   yield x
> end
> puts hello
> frenchy { |hello| puts hello }
bonjour                             # as expected
> puts hello
bonjour                             # ouch! In 1.9 you'd get "hello"


Some of the Rails and Ruby library code define methods with &block as the last parameter to capture an anonymous block.

  • anonymous blocks are ignored if they’re not used, and &block is an optional parameter that must appear as the last parameter
  • it’s effectively a type-checked parameter – it will only accept an anonymous block or a proc (if proceeded with &)
  • the block can be called with call or yield
  • you can check if a block was passed using block_given?
  • &block is sort of an “invisible parameter” at the end of all methods. But by explicitly using &block, callers get more flexibility when using your method ie they can pass in a proc (perhaps defined elsewhere and used multiple times)

Anonymous blocks are ignored if they’re not used:

> def foo(a)
>   puts "a is #{a}"
> end
> foo(1)
a is 1
> foo(1) { puts "2" }
a is 1

Conversely if &block is declared as a parameter, using it is optional:

> def foo(a, &block)
>   puts "a is #{a}"
> end
> foo(1)
a is 1

Procs can be called with call; anonymous blocks can be called or yielded to.

> hello = lambda { puts "good bye" }      # define a proc for later use
> def foo(a, b, &block)
>   puts "a is #{a}"
>                                # proc with call
>                            # block with call
>   yield                                 # block with yield
> end
> foo(1, hello) { puts "fred" }           # with an anonymous block
a is 1
good bye
> foo(1, hello, &hello)                   # with a proc; notice & syntax
a is 1
good bye
good bye
good bye

You can check if an anonymous block was supplied using block_given?

> def foo(a, &block)
>    puts "a is #{a}"
> if block_given?
>    yield      if block_given?
> end
> foo(1) { puts "mary" }
a is 1
> def foo(a)                              # or, without defining the block parameter
>    puts "a is #{a}"
>    yield      if block_given?           # therefore can only yield not call
> end

&block is sort of an “invisible parameter” at the end of all methods. But by explicitly using &block, callers get more flexibility when using your method:

> def foo(a)                                         # no &block defined in parameters
>   puts "a is #{a}"
>   yield if block_given?
> end
> foo(1) { puts "john" }                             # works as expected
a is 1
> foo(1, hello)
ArgumentError: wrong number of arguments (2 for 1)   # dang! I can't use my super-duper hello proc


do .. end has weaker precedence than { }. For example, if foo and bar are both methods:

These are both the same ie the method foo receives two parameters, bar and a block.

foo bar  do |s| puts(s) end
foo(bar) do |s| puts(s) end

And these are both the same ie foo and bar both receive one parameter; foo the call to bar, and bar a block:

foo  bar { |s| puts(s) }
foo( bar { |s| puts(s) } )

Of course the moral of story is not to rely on obscure precedence rules, rather use parentheses whenever something is unclear – as always, in any language.


Blocks are closures ie they store or carry the value local variables from the the original scope into a different scope. They’re another way of reusing the same logic with slightly different values. For example:

> def build_header( level )
>   return lambda { |text| "<#{level}>#{text}</#{level}>" }
> end
> h1 = build_header("h1")
> h2 = build_header("h2")

9 August 2011

git – make an existing git branch track a remote branch

Filed under: Uncategorized — Sonia Hamilton @ 09:54

A script to make an existing git branch track a remote branch. For example when you’ve cloned from somewhere else and now want to track your normal remote.

% cat ~/bin/gittrack
# vim: ai ts=4 sts=4 et sw=4 ft=sh

current_branch=$(git symbolic-ref -q HEAD)

if [ $current_branch = 'HEAD' ] ; then
    echo "On a detached head. Exiting..."
    exit 1


git branch --set-upstream $current_branch $remote/$current_branch

Of course your global gitconfig should also have autosetupmerge (below), but this script handles situations where you want to setup/change the tracking branch.

        autosetupmerge = true

2 August 2011

Setting up Gitweb on your Ubuntu workstation

Filed under: Uncategorized — Sonia Hamilton @ 17:26

If you work in an IT environment, it’s nice to be able to quickly share some of your git repositories from your workstation, without setting up accounts and ssh keys ie using http. Unfortunately, a lot of the posts out there on “how to setup Gitweb on Ubuntu” seem to make a meal of the whole process. I got it going after heading down a few dead-ends; here’s how I did it on Ubuntu 11.04 (Natty).

Basic Setup

Let’s start with a simple git repository:

sudo aptitude install git-all apache2
cd ; git init foo ; cd foo
echo "hello world" > file1.txt
git add . ; git commit -m "initial commit"

You probably only want to share out some of your repositories, not all of ${HOME}! So, do a bare clone of foo repository to /var/www:

cd /var/www
sudo git clone --bare ~/foo foo.git

Next, a little gotcha. You need to enable the post-update hook, so that the required info is generated for the http server. The “gotcha” is that you need to enable the hook then do a push to your server repository, otherwise the server info isn’t updated:

cd ~/foo/.git/hooks
mv post-update.sample post-update
git remote add web /var/www/foo.git
## do a test push
cd ~/foo
echo "test update" >> file1.txt
git add . ; git commit -m "test update"
sudo git push web

Now, if you browse to http://localhost you should see foo.git listed, and your workmates can now easily clone your work:

otherpc$ git clone http://yourpc/foo.git


The next step is to setup gitweb, so your workmates can easily browse your code, search for commits, etc. Gitweb is already installed as part of git-all, or you can do:

sudo aptitude install gitweb

The only change to make is to edit /etc/gitweb.conf to point to /var/www:

sudo vi /etc/gitweb.conf
## $projectroot = "/var/cache/git";
$projectroot = "/var/www";

And that’s it! Part of the gitweb install on Ubuntu adds in /etc/apache2/conf.d/gitweb, so there’s no other files to edit (unlike what blog1, blog2, or blog3 say).

Browse to http://localhost/gitweb/, and there’s your browse-able, search-able, git repository 😀

But wait, there’s more – automatically push your changes…

As you work, /var/www/foo.git is going to get out-of-date. You could remember to regularly push but that’s boring – automate it:

% cd ~/foo ; cat git.web.push
cd ${HOME}/foo
git remote add web /var/www/foo.git >& /dev/null
sudo git push -f web

…and automate it:

crontab -l
* * * * * ${HOME}/foo/git.web.push

And finally…

Make the layout pretty. Edit ~/foo/.git/description, add an index.html, a custom theme, some javascript, …

28 July 2011

rsyncp – provide ssh password to rsync using expect

Filed under: Uncategorized — Sonia Hamilton @ 17:45
Tags: , ,

A script I wrote – rsyncp. It allows you to provide a password to rsync over ssh, when you’re unable to use ssh key-based authentication:

% cat ~/bin/rsyncp
eval spawn rsync $argv
expect  "*?assword:" { send "secretstuff\r"}
expect eof

You can then use rsyncp in another script, like this:

for h in foo bar ; do
  rsyncp -av --progress srcdir/ $h:dstdir/

And before you add a comment saying use ssh keys or keychain, this is totally insecure, I agree with you! Key based authentication is disabled on the target server, and I’m still trying to resolve the politics around this at my current company, and sshpass seems broken <sigh>

19 July 2011

shell – all parameters – $* vs $@

Filed under: Uncategorized — Sonia Hamilton @ 16:08

Both $* and $@ expand to “all positional parameters”; in a nutshell – “$@” is often desired as it handles spaces correctly; see man bash “Special Parameters”.

% ls my*     
myfoo  my foo  myqux


% ./star_test my*
my     :-(
foo    :-(

my     :-(
foo    :-(

myfoo my foo myqux    <-- probably not desired :-|

my foo  :-)


% cat star_test
echo '$*'
./pargs $*

echo '$@'
./pargs $@

echo '"$*"'
./pargs "$*"

echo '"$@"'
./pargs "$@"


% cat pargs
for i ; do
    echo $i
Next Page »

Blog at