Once the invocation parameters have been processed, it is time to call delete_older:
delete_older(path, age_in_seconds) rescue puts "Error: #$!"
Errors may occur during execution. If the script is invoked with the path to a nonexistent directory, for instance, an error will occur the first time Ruby invokes a method on the Dir class. The code above not only invokes delete_older, it also handles possible errors that occur during execution. The key here is the rescue expression. When an error occurs, the Ruby interpreter packages the error in an exception object. This object propagates back up the call stack until it reaches some code that explicitly declares it knows how to handle this particular type of exception. Exceptions that are never caught propagate through the call stack, ending up with an abnormal program termination; the stack trace is printed to stderr. This is opposed to returning error codes like shell scripts and C do, leading to less-nested statements, less spaghetti logic and simply better error handling.
Including an ensure statement in connection with the rescue expression ensures that a code block is run no matter what else happens. Combine this with the possibility of writing your own exceptions, making your own code throw exceptions (with the raise expression as shown in the program listing in Containers), and the ability to actually recover from an exception by running some code and retrying the code that caused the failure, and you have one of the neatest error-handling mechanisms I've ever used.
Let's return to delete_older to look at some of Ruby's more advanced features (see Listing 2 [available at ftp.linuxjournal.com/pub/lj/listings/issue95/4834.tgz]). Line two sees “foreach” being invoked on the Dir class; foreach is an implementation of the iterator design pattern. If you are doing object-oriented programming, but have not read the Gang of Four's groundbreaking book Design Patterns, you'd better run out and buy a copy. Iterator is not the only pattern implemented in core Ruby. Singleton, publisher/subscriber, visitor and delegation patterns also are implemented. Other patterns also can be implemented simply if required, but the listed patterns are shipped with Ruby.
foreach iterates over the files in a directory. Following the call to Dir's foreach is a block of code with a start and end very much resembling that of a regular Java or C++ code block. The code contained within the curly braces is called a block, which is like a method within a method. A block is never executed at the time it is encountered. Whenever the foreach method has read a single file from the directory, it yields control to the block. The code within the block is executed, and control returns to foreach, which reads a new file from the directory repeating the procedure over again until no more files are left to iterate over.
Instead of having to write helper classes to make iterators work, as you have to in Java or C++, Ruby includes the yield expression that makes it possible to implement iterators as methods. This is a prime example of the language's expressiveness and flexibility. Instead of writing the scaffolding to make it happen, Ruby lets you concentrate on doing the job.
As mentioned earlier, a method is invoked by sending a message to the target object on the target.message form. Only methods local to the class may be called without specifying a target. My script calls “puts”, which is a method belonging to the kernel, without specifying any target. How does the interpreter know which method I'm calling when puts is not local to the object and no target is specified?
It is the magic of mix-ins. Mix-ins basically allow you to mix methods implemented elsewhere into a class without the use of inheritance (for more on mix-ins, please refer to the article “Using Mix-ins with Python”, Linux Journal, April 2001). Mix-ins aren't a new idea, nor is Ruby the only language to support it. But it is most definitely one of the features that gives Ruby that nice and clean syntax.
I could never hope to deal with all of Ruby's features in this article. Instead I'll refer you to David Thomas and Andrew Hunt's book Programming Ruby for more details on issues like modules, aliasing, namespaces, reflection, dynamical method calls, system hooks, program distribution and networking. It is worth mentioning that Ruby also supports regular expressions that are just as good as Perl's and supports CGI, in addition to having its own Apache module, mod_ruby.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide