Warning
This book is new. If you'd like to go through it, then join the Learn Code Forum to get help while you attempt it. I'm also looking for feedback on the difficulty of the projects. If you don't like public forums, then email help@learncodethehardway.org to talk privately.
Exercise 25: xargs
We are returning to challenge mode exercises and to warm you up you'll be implementing xargs. This should be a straightforward implementation for you, but xargs can be complex as you'll need to launch other programs to make it work. The Python module you'll want to investigate is subprocess, which can run other programs from Python and collect their output. You'll need to understand that module to complete xargs and many of the other projects later in the book, so study it well.
Exercise Challenge
Implement xargs for just 45 minutes so you can get something working that you can audit. Remember this first hack is about getting the project going, not making something perfect. You'll use subsequent steps in this project to refine it and make it better. Remember that you can type
man xargs
to get the manual page for xargs and research how it works. It's a handy Unix tool, but you can also use find to do nearly the same thing. As you implement xargs try to find out what advantage it has over find --exec.
After your 45 minute hack you should take a break and then conduct an objective audit of the code using the Part III checklist for auditing code. Don't fix the code, just write comments indicating what needs to change and what defects there are. It's difficult to remain objective while also trying to fix things, so just note problems in the audit and then fix them in the next round.
You will then conduct a squence of code/audit timed sessions to get used to the idea of doing audits. Take as long as you need to implement as much of xargs as you can, and then move on to the next project.
Note
Remember to track your defects in your journal so you can do run charts of them and look for trends.
Study Drills
- During this process of code/audit did you find anything you continually get wrong? Write these down as potential things to work on.
- Is there a particular point in your code/audit process that has more or fewer defects? Are there more in the beginning than after three or four? Why might this be?
- Try writing automated tests for your implementation of xargs and see if that drops your defect rate. In the next exercise you will do a more controlled testing study like this, but give it a shot now to see what you find.