The two best things you can do are:

1. Give him time to read, and
2. Give him a sandbox for toy projects.

Most companies that deal with software treat "training" roughly the same way they treat "voiding one's bowels". They acknowledge that both are necessary, but would prefer not to see either one happen right there in the office. But where federal health and labor laws force companies to provide bathrooms and allow employees to use them, there's no corresponding mandate to support training.

In other words, most companies talk a good game of training, but don't actually do anything to support it.

If you want to break the pattern, start with the one resource most vital to any educational program: time. Set aside some amount of time every week -- 2-1/2 hours (half an hour a day) is usually good -- and tell your student that he's to spend that time researching some Perl-programming-related subject. Have him keep a research log every day, where he writes down what he wants to get out of each day's reading before he opens the book, then makes notes about what he finds while he's reading. At the end of each week, have him go through that week's log and show you the progress he's made, then tell you where he wants to go in the next week.

That cycle will teach him a lot of valuable skills above and beyond what he learns about Perl per se: setting goals, tracking progress, and making that progress visible to someone else. He'll also get valuable experience with the mechanics of business communication.

Personal aside -- one of the most valuable things I ever learned about living in a corporate environment was how to sit still in meetings. I was in a semi-formal meeting with the departmental VP, and was absently cracking my knuckles while we waited for things to get going. Greg, my VP, looked over at me and said, "You're fidgeting, Mike. Stop. It costs you points in this setting." Since then, I've sat through any number of meetings, taking note of the giggling, tapping, coughing, and babbling of other people around the table, and quietly noting just how right he was.

Toy projects are the other half of the training agenda, because they provide that all-critical resource: freedom to fail.

You can't teach people anything valuable in a production environment, because in a production environment you can't afford to screw up and throw the whole thing away. That means you can't stretch, or make a serious commitment to anything that doesn't have a good cost/benefit/buck-passing/deniability ratio.

The production environment rewards hidebound conservatism, failure that distributes the blame across a large number of people, and failures that are too complex to be summed up in a half-dozen bullet points. It mostly ignores ordinary success, and punishes heroic efforts by assuming they can be done again on demand. None of those are useful for someone who wants to learn.

A toy project is something you can afford to fly straight into the ground, just to see what happens. You can learn a lot doing the post-mortem for such projects, just as the auto industry learns a lot from crash tests. You have to be able to send the car into the wall at 60mph, though, and you won't get anywhere with some beancounter clucking over your shoulder, insisting that you get N+1 tests out of every car.

So give your student time to do research, and make him pay for that time by showing you what he's learned. Then when he's learned enough to need some practical experimentation, give him the freedom to try things and fail, and make him pay for that by telling you what he tried, and what happened. You can hardly keep people from learning under those conditions, even if you have no idea what they're going to learn when you set out.