Dave Neary

Funny story. My first contribution to a prominent open source project was towards the end of the 1.1.x development series of the GIMP in 2000. I did not know how to submit a patch down official channels, and joining a mailing list to send in a patch was a very intimidating first step. The patch was a one-line fix to a GIMP plug-in to correct a small issue with tile management in the plug-in. I don't recall how I found it - I think there may have been a bug created for it on the old bugs.gimp.org website (pre-Bugzilla). In any case, I hit the bug, and fancied myself to fix it.

After coming up with this one-line patch, I looked in the project ChangeLog to find a name and email address to send the patch for review - I happened to see Daniel Egger (still an open source kernel developer) as a frequent contributor at the time, and he was very kind and encouraging with this first contact. Daniel committed the patch on my behalf to the GIMP CVS: https://gitlab.gnome.org/GNOME/gimp/commit/fcc29b05dcbf8b14916bba195d77…

Here's where the story gets funny. My very first contribution was wrong! My second patch to the GIMP, sent approximately an hour later, fixed the first patch. https://gitlab.gnome.org/GNOME/gimp/commit/d8dfc2128aa1f768152d86f12005…

So, I learned early that it's OK to make mistakes as long as you fix them :-)

Thanks for the feedback John! I agree, some shell constructs are very confusing and need explanation - this one in particular is of the form:
[ test ] && action

[ ... ] tests whether an action returns true or false.

a && b executes a, and if it is true, executes b (and evaluated to true or false, depending on whether both commands return true (or success) or not.

So "[ test ] && action" will execute the action only if the test returns true. It is equivalent to:

if [ test ]; then
action;
fi

Maybe shell built-ins should be the next article I do?

Thanks again!
Dave.