More safe scripting
set -u will make a sh script abort on an undefined variable. I'm setting this in most, if not all of my scripts. Does anyone else have any useful defensive shell tips?
More safe scripting
set -u will make a sh script abort on an undefined variable. I'm setting this in most, if not all of my scripts. Does anyone else have any useful defensive shell tips?
So, we all know that when writing a shell script, you start:
#! /bin/sh
#
# description/author/copyright/blah-blah-blah
set -e
....
What I didn't ever see mentioned is that if you're assuming set -e, command substitution — `cmd` or $(cmd) — with a non-zero exit status will not cause the script to abort.
There's a simple solution, fortunately:
tmp=`cmd`
do_stuff_with $tmp
Whilst I'm onto it, if you're reading a stream of words into the positional ($1 etc) values with set --, you really should check the number of parameters. Either:
tmp=`date +"%Y %m %d"`
set -- $tmp
[ $# = 3 ]
or
tmp=`date +"%Y %m %d"`
set -- $tmp
year=$1; month=$2; day=${3:?date went wrong}
Autofs: Looks like Jeremy Fitzhardinge got bored of Autofs 4 so Ian Kent has taken it over. Sadly, since Jeremy never released a version incorporating my code, I'm going to have to port it to Autofs 4.1. Anyway, I also found a bug in my code that caused it to forget variable definitions in some cases; the fixed code for lookup_sun.c for Autofs 4.0 is here.
File, dbm and sql lookup: I had a little programming to write and was struck by the fact that I have to write my own code to do a linear search through a flat-file. (It was actually way easier to just use Berkeley DBM instead and do db->find.) I'm wondering if it would be useful to have a library which did lookups for a variety of data sources in a unified manner, so if the source outgrows flat-file it can migrate to somethiing else without having to re-write any code. Anyone else think this would be good?
autofs4: Jeremy has in principle accepted my autofs4 code but it's been a year since he last released anything. Must ping him.
PAM: I wrote a module, pam_twist that maps a username into another, so the Durham Computing Society can authenticate using either their Society password or with their University password. This way they can log in to change their Society password without having to hassle me.
Been looking through my prospective Debian maintainer's packages. (We call such people NMs). They're excellent considering his experience, if a little rough round the edges.
I've been getting much better at finding problems in packages in recent days. Stephen Quinney and I occasionally pull apart a package that a NM wants sponsored -- competing to find the most problems in the same package, then comparing notes later. Hopefully this will in turn improve our packaging skills.
PAM
The implementation of these access controls is going nicely but it's not easy to get the users (machine owners) to pin down who they want to give access to. <sigh>
PAM-tastic is the word of the moment.
I'm implementing some login controls using the basic Linux-PAM system and it's great. Just a shame I have to be so repetitive in /etc/pam.d. Once that's done, I'll be porting the useful modules to Solaris. Despite the fact that it's the home of PAM, they have a distinct dearth of handy modules compared with Linux.
Sick things to do with PAM number 1: Put a 'sufficient' authentication line of pam_listfile into xscreensaver, so my 3-year-old son David doesn't need a password to unlock it.
Update to nnrpd: That code was accepted with good grace. Splendid.
I've been amused to find that nnrpd, the client-facing news server from inn, was completely missing a documented feature. It took about two minutes and one line of code to implement.
For the interested, the feature in question was the ability to disable Perl filtering for posted articles on the basis of who someone was authenticated as. That's not the point, however.
My point is simply this: Don't manpage writers actually try out what they document?
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!