Developer Blog: Ray - sendbug(1) & more

Darrin Chandler:
Hi Ray!

Looks like nice work on sendbug!

Ray Lai:
Thanks!

DC:
I've noticed lately that a few GNU things here and there have been rewritten. Not just big things like OpenCVS, but other things like your sendbug. Is this little trend planned, encouraged, or acknowledged openly?

RL:
One day we were talking about OpenCVS progress and Theo noted that the next easiest GNU replacement would be sendbug. And yes, it is a very simple program, which was why I wanted to let others handle it at first, to get experience or whatever. After a few weeks it was obvious no one was going to step up, and this was a simple project I wanted to finish in about a night, so I wrote most of it that night; the next night I polished it, and the night after I sent it to Theo. He seemed pleased with it and also got pretty involved with finishing the missing functionality, which was pretty cool. Working with Theo I learned a lot about the limitations of GNU sendbug, which are mostly because it is a shell script.

The trend isn't really to remove GNU software, but to remove _bad_ software. Because the GNU software is not under our control and, often times is not even under development, we cannot fix it ourselves. Well, maybe we could, but it's difficult to work with code that starts out bad, plus it's got a GNU license on top of it.

DC:
So now sendbug is in the tree and actively maintained again. Are there any new features or new information being added?

RL:
It is always helpful to include more details about the system having issues, and one thing that had a lot of detail is the kern.version sysctl, which looks like this:

OpenBSD 4.1-current (GENERIC) #1463: Wed Apr  4 19:34:35 MDT 2007
    deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC

Knowing this information helps determine what kind of kernel is having this issue and whether it is already solved or if it is new. We added this line to the new sendbug and crossed our fingers, hoping OpenBSD's gnats database would be able to handle this extra information.

It was exciting waiting for the first person to actually submit a bug report using it, since I never tested it out on OpenBSD's gnats database. (I tested by sending myself lots of e-mail.) For a while I was worried it didn't work, but soon after I saw an e-mail with the extra details we added to sendbug. I think this prompted Theo to delete the old sendbug from the tree.

DC:
That's more info that before, and helpful right away. Is there anything else you have included?

RL:
We also wanted to include the dmesg, but this could including this could mean publishing sensitive information about a user's to mailing list archives. We went back and forth between adding a flag that included the dmesg or including the dmesg by default and adding a flag that disabled this feature. Eventually we settled on the latter, reasoning that the user is given two chances to remove the dmesg: once with the flag (which can be automated by aliasing sendbug) and a second time in the editor.

DC:
So sending the dmesg is completely obvious and optional, but defaults to send. IMHO, this is another example of sane defaults.

Watching the commits, I noticed a flurry of activity by you and then Theo, and then a pause. After that some interesting signal handling commits were made. Can you talk more about that?

RL:
One of the things I discovered while working on sendbug was that the fork-exec editor combo is reimplemented quite often in the tree. Ctrl-C is commonly used in certain editors, which sends the signal to both the child and the parent (the editor and sendbug in this case). Nearly every implementation could not deal with signals sent to the parent. Some would exit, causing the editor to exit as well. Others tried to handle signals but only suspended them, so the moment the editor quit the parent received the suspended signal and exited.

Eventually I worked with Theo to polish up a generalized function that can be copied to different parts of the tree, editit(). It ignores certain signals while the editor is running, and restores signal handling after the editor is done. Behavior should be as users expect it to be. We tried to do funky things with it, including handling flags in the EDITOR environment variable, suspending and resuming, et cetera. Once this implementation has been well tested I'll start copying it to other programs to unify our editor handling.