This sentence in a package description is always great...

You probably don't need it if you don't understand what this is all about.

Brought to you today by nut-snmp but can be found in many other packages.

Let's start with the solution instead of the problem:

Assuming myfunc is a function defined elsewhere in your shell script this will execute that function and assign it's output to myvar. However when myfunc fails, the entire assignment statement fails with the exit status of myfunc, so you exit with the same exit status by using || exit $?.

It is really important to have this exit statment in there, even if myfunc already has it. You could look at the $(...) construct as a subshell, so the exit of myfunc only exits that subshell. This took me quite a while to figure out!

On a related note, you may know you can execute things in a subshell by using (list). If you do that any variables etc won't affect your current shell. However variables and hence also functions from the parent shell are usable in the subshell. Handy (and maybe obvious).

If you want/need to compile a program on ARM but are not lucky enough to have the hardware available QEMU can still help you. Aurélien Jarno has an excellent description of how to do this. It is still valid today, even if you want to install sid instead of etch, first install etch then upgrade.

The only thing he omits is the need to start a getty on /dev/ttyAMA0 when you use -nographics with a console on ttyAMA0. Other then that everything goes terribly smooth.

Apparently emulating ARM on a recent machine is supposed to be even faster then a real ARM. I have no idea if this is true, but I still find it slow... Makes me think twice about considering a Thecus N2100 or so as my home server.

In my last post I had a little rant about how python docstrings visually separate the function/method/class definition from the body. Mikko Ohtamaa raised a very good point though: the editor should fold it away.

Since my editor of choice is Emacs, said to be more an operating system then an editor, this must be possible. But surely someone more intelligent then me must have implemented this already (for I still don't know lisp, shame on me)! So I read the python-mode description which mentioned something about support for outline-minor-mode. This lead me to play around a little with outline-mode. I'ts rather nice and seems to do useful folding, once I get used to it.

But I'm not sure I can figure out how to fold away just the docstring in outline-mode! There seems to be a "Hide Entry" function that most of the time does just hide the docstring when the cursor is located over it. But sometimes it will hide a few more lines too... Surely I must be missing something, anyone some hints?

There are several simple guidelines for writing functions or methods (guidelines that I like that is).

• Keep them clean, don't intersperse them with comments. If they require more then one or two inline comments it's too complicated and you should restructure.
• Keep them short, it should fit on one screen. I'm flexible, a screen is an emacs buffer, not a vi in a terminal as Linus requires.
• Write a clear description at the top, explaining parameters, return values, exceptions etc whenever these things might not be blatingly obvious in a month's time. As soon as you explain one parameter you you should describe the whole lot though.

In C this is quite nice, it looks like this:

/** Print an integer number
 *
 * The number is printed to stdout.  Really that's
 * all there is to it.
 *
 * param - The integer to print.
 */
void my_func(int param)
{
    printf("This is an integer: %d", param);
}

While in Python this would look like this:

def my_func(param)
    """Print a number
    
    The number is printed to stdout.  Really that's
    all there is to it.

    param - The number to print.
    """
    print "This is a number: %d" % param

While python code is generally very lovely readable this is something that annoys me about it. Suddenly my function definition is separated from the code by the docstring, often causing the definition and the code not to fit on one screen anymore (it is foolish IMHO to require the documentation and code to fit on one screen, given my documentation conventions).

While I understand every reason for the way things are and acknowledge that it probably won't ever change it still annoys me from time to time so I felt like moaning about it.