Add 'whenjobs --whisper' which lets you set variables "quietly".
[whenjobs.git] / tools / whenjobs.pod
1 =encoding utf8
2
3 =head1 NAME
4
5 whenjobs - A powerful but simple cron replacement
6
7 =head1 SYNOPSIS
8
9 Editing the jobs script:
10
11  whenjobs -e | --edit
12  whenjobs -l | --list
13
14 Get and set variables:
15
16  whenjobs --get variable
17  whenjobs --set variable=value [variable=value ...]
18  whenjobs --variables
19
20 Start and stop the per-user daemon:
21
22  whenjobs --daemon-start
23  whenjobs --daemon-stop
24  whenjobs --daemon-status
25  whenjobs --daemon-restart
26
27 Examine running jobs:
28
29  whenjobs --jobs
30  whenjobs --cancel serial
31  whenjobs --start "name"
32  whenjobs --tail serial
33
34 =head1 DESCRIPTION
35
36 Whenjobs is a powerful but simple replacement for cron.  It lets you
37 run jobs periodically like cron, but it also lets you trigger jobs to
38 run when user-defined variables are set or change value.
39
40 Periodic jobs are written like this:
41
42  every 10 minutes :
43  <<
44    # Get the current load average.
45    load=`awk '{print $1}' /proc/loadavg`
46    whenjobs --set --type float load=$load
47  >>
48
49 When-statements let you create jobs that run based on variables set
50 elsewhere:
51
52  when load >= 6 :
53  <<
54    mail -s "ALERT: high load average: $load" $LOGNAME < /dev/null
55  >>
56
57 (When statements are "edge-triggered", meaning that this job will only
58 run when the load goes from under 6 to E<ge> 6).
59
60 Like L<crontab(5)>, whenjobs are controlled by a jobs file which can
61 be edited from the command line:
62
63  $ whenjobs -e
64
65 Whenjobs uses a daemon called L<whenjobsd(8)>.  Unlike crond, this
66 daemon runs as the same user.  Each user who wants to use whenjobs
67 starts their own daemon:
68
69  $ whenjobs --daemon-start
70
71 You can also have the daemon start as you when the machine boots by
72 adding the following line to a boot file such as C</etc/rc.local>.
73 Replace C<username> with your username:
74
75  su username -c /usr/sbin/whenjobsd
76
77 Variables are the key to expressing dependencies between whenjobs.
78 Variables are stored (per-user) in the daemon.  You can use the
79 command line tool to examine and set variables:
80
81  $ whenjobs --variables
82  JOBSERIAL=297
83  libguestfs_build_local=1.17.16
84  libguestfs_commit=7e32d892d76a31f55e2a4151902623b9949e3efa
85  libguestfs_dist=1.17.16
86  libguestfs_release=1.17.16
87  libguestfs_stable_build_local=1.16.10
88  libguestfs_stable_commit=27433a0a335301441b1eb6244ba425c2c44b2d99
89  libguestfs_stable_dist=1.16.10
90  libguestfs_stable_release=1.16.10
91  libguestfs_stable_version=1.16.10
92  libguestfs_version=1.17.16
93  $ whenjobs --set cat=sushi
94  $ whenjobs --get cat
95  sushi
96
97 Note: The act of setting a variable (using I<--set>) can trigger jobs
98 to run.
99
100 You can also list out what jobs are running:
101
102  $ whenjobs --jobs
103  287 libguestfs-stable: fedora 16
104     running in: /tmp/whenjobsa2afc44fd757465f95438309f1a51609
105     started at: 2012-03-13 10:59:37
106
107 and you can 'tail' the output of running jobs which is useful for
108 debugging:
109
110  $ whenjobs --tail 287
111  Uploading: 147496271972717053d46b82a07435ca  libguestfs-1.16.10.tar.gz
112
113 You can start and cancel jobs manually:
114
115  $ whenjobs --start 'libguestfs: poll'
116  $ whenjobs --cancel 287
117
118 =head1 OPTIONS
119
120 =over 4
121
122 =item B<--cancel> serial
123
124 Cancel the job with the given serial number.
125
126 Use I<--jobs> to list running jobs along with their serial numbers.
127 The serial number is also available in the job script (as
128 C<$JOBSERIAL>) and in the log file.
129
130 =item B<--daemon-start>
131
132 =item B<--daemon-stop>
133
134 Start and stop the per-user daemon.
135
136 =item B<--daemon-status>
137
138 Prints the status of the daemon: C<up> or C<down>.
139
140 =item B<--daemon-restart>
141
142 Restart the daemon.  (If it is not running, then this command
143 starts it).
144
145 =item B<-e>
146
147 =item B<--edit>
148
149 Edit the jobs script.  If you make changes to the jobs script, then it
150 is automatically uploaded to the daemon.
151
152 The C<$EDITOR> environment variable is used for editing.  If not set,
153 C<vi> is used.
154
155 =item B<--get> variable
156
157 Print the value of a variable.
158
159 =item B<-help>
160
161 =item B<--help>
162
163 Display brief usage and exit.
164
165 =item B<--job-names>
166
167 List the names of all loaded jobs (whether they are running or not).
168 Use I<--jobs> to list running jobs.
169
170 =item B<--jobs>
171
172 List all running jobs.
173
174 Note that it is possible for the same job to be running more than once
175 (for example, a periodic job that takes longer than the period to run).
176
177 =item B<-l>
178
179 =item B<--list>
180
181 List the jobs script.
182
183 =item B<--lib> directory
184
185 Set the library directory which needs to contain the auxiliary files
186 C<pa_when.cmo> and C<whenlib.cma>.  Normally you do not need to
187 specify this.  However if you are running whenjobs without installing
188 it, then you need to point this to the C<lib/> directory from the
189 source, eg:
190
191  whenjobs --lib $builddir/lib -e
192
193 =item B<--set> variable=value [variable=value ...]
194
195 =item B<--type> bool|int|float|string|unit
196
197 I<--set> sets the variable named C<variable> to the new C<value>.  The
198 variable is created if it does not already exist.  Note that setting a
199 variable can cause jobs to run immediately.
200
201 To unset a variable, set it to the empty string like this:
202
203  whenjobs --set var=
204
205 By default variables are strings.  You can also set the type of a
206 variable when setting it by adding the optional I<--type> parameter.
207 The I<--type> parameter should come I<before> the variable
208 declaration, like this:
209
210  whenjobs --set --type int free_space=10000
211
212 See the discussion of variable types in the L</REFERENCE> section
213 below.
214
215 You can set multiple variables.  When setting multiple variables in a
216 single command, the values are all changed in a single atomic
217 operation.
218
219  whenjobs --set cat=sushi food=fish
220
221 When using I<--type> and multiple variables, the type changes the
222 remaining command line parameters until the next I<--type>, eg:
223
224  whenjobs --set cat=sushi \
225      --type float weight=3.5 \
226      --type string food=fish
227
228 (C<cat> and C<food> are strings, and C<weight> is a float).
229
230 =item B<--start> "job name"
231
232 Start the job immediately and unconditionally.
233
234 This runs the job even if its normal preconditions are not met.  This
235 may cause unexpected results, so use with caution.
236
237 =item B<--tail> serial
238
239 Tail the output of the running job identified by its serial number.
240 Use the I<--jobs> flag to get a list of running jobs.
241
242 =item B<--test> variable=value [variable=value ...]
243
244 This works the same way as the I<--set> option, but the difference is
245 that the variables are not set.  Instead, it lists out the jobs that
246 I<would> run, I<if> the variables were updated to these new values.
247
248 The variables are not actually updated, and the jobs are not actually
249 run.
250
251 The output is a list of job names that would run.
252
253 =item B<--upload>
254
255 Compile the jobs script and upload it to the daemon, without editing.
256 Note that the I<--edit> option does this automatically.  Furthermore,
257 when the daemon is started it checks for a jobs script and loads it if
258 found.
259
260 =item B<--variables>
261
262 Display all the variables and their values, in the format C<name=value>.
263
264 =item B<-V>
265
266 =item B<--version>
267
268 Display the name and version of the program and exit.
269
270 =item B<--whisper> variable=value [variable=value ...]
271
272 This works the same way as the I<--set> option, but with the
273 difference that jobs' when clauses are not reevaluated.  In other
274 words, the variables are set, but "quietly" so as not to trigger any
275 jobs to run.
276
277 Note that this can lead to some unexpected results: one case is a
278 when job such as:
279
280  when changed a || changed b : << ... >>
281
282 If C<a> is changed using I<--whisper>, then the job will not run.
283
284 But later on, if C<b> is set but to the same value that it already has
285 (ie. not changed), the job will run because the whole when-clause is
286 reevaluated and C<a> is found to have changed since the last run of
287 the job.
288
289 =back
290
291 =head1 REFERENCE
292
293 A whenjobs file consists of a series of one or more "every" or "when"
294 statements.
295
296 Comments in the file can be written using C<(* ... *)>.  Comments
297 may be nested.
298
299 Shell script fragments are written using C<E<lt>E<lt> ... E<gt>E<gt>>.
300 Within shell script fragments, use C<#> for comments (as in ordinary
301 shell scripts).  Because C<E<gt>E<gt>> has a special meaning, it
302 cannot be used in the shell script (ie. for redirection).  You have to
303 write C<E<gt>\E<gt>> instead which is replaced with C<E<gt>E<gt>> when
304 the shell script is parsed.
305
306 =head2 EVERY STATEMENTS (PERIODIC JOBS)
307
308 An every statement has the form:
309
310  every <period> :
311  <<
312    # shell script
313  >>
314
315 where C<E<lt>periodE<gt>> is a I<period expression>, which may take
316 one of the forms below.  Don't forget the colon character between the
317 period expression and the shell script.
318
319 An every statement is a job which runs periodically.
320
321 =head3 PERIOD EXPRESSIONS
322
323 =over 4
324
325 =item B<every second>
326
327 The job runs every second.
328
329 =item B<every minute>
330
331 The job runs every minute.
332
333 =item B<every hour>
334
335 The job runs every hour.
336
337 =item B<every day>
338
339 The job runs every day, at midnight UTC.
340
341 =item B<every week>
342
343 The job runs every week, on a Thursday at midnight UTC.
344
345 =item B<every month>
346
347 The job runs every month, on the first of the month at midnight UTC.
348
349 =item B<every year>
350
351 The job runs every year, on the first day of the year at midnight UTC.
352
353 =item B<every decade>
354
355 =item B<every century>
356
357 =item B<every millenium>
358
359 The job runs every 10, 100 or 1000 years.
360
361 =item B<every I<N> seconds>
362
363 The job runs every I<N> seconds (I<N> is any number E<ge> 1).
364
365 =item B<every I<N> minutes>
366
367 The job runs every I<N> minutes.
368
369 =item B<every I<N> hours>
370
371 The job runs every I<N> hours.
372
373 =item B<every I<N> days>
374
375 The job runs every I<N> days.
376
377 =item B<every I<N> weeks>
378
379 The job runs every I<N> weeks.
380
381 =item B<every I<N> months>
382
383 The job runs every I<N> months.
384
385 =item B<every I<N> years>
386
387 =item B<every I<N> decades>
388
389 =item B<every I<N> centuries>
390
391 =item B<every I<N> millenia>
392
393 The job runs every I<N>, I<10*N>, I<100*N> or I<1000*N> years.
394
395 =back
396
397 =head2 WHEN STATEMENTS (DEPENDENT JOBS)
398
399 A when statement has the form:
400
401  when <expr> :
402  <<
403    # shell script
404  >>
405
406 where C<E<lt>exprE<gt>> is a I<when expression>, described below.
407 Don't forget the colon character between the period expression and the
408 shell script.
409
410 A when statement is a job which runs when the conditions described in
411 its when-expression become true.
412
413 When jobs are I<edge triggered>.  This means that they run when the
414 condition changes from false to true (or in the case where the
415 expression has not been evaluated before, when it evaluates initially
416 to true).
417
418 =head3 WHEN EXPRESSIONS
419
420 When expressions are fully recursive expressions constructed from the
421 following elements:
422
423 =over 4
424
425 =item I<expr> B<&&> I<expr>
426
427 =item I<expr> B<||> I<expr>
428
429 The boolean "and" or "or" of the two sub-expressions.
430
431 =item I<expr> B<E<lt>> I<expr>
432
433 =item I<expr> B<E<lt>=> I<expr>
434
435 =item I<expr> B<==> I<expr>
436
437 =item I<expr> B<E<gt>=> I<expr>
438
439 =item I<expr> B<E<gt>> I<expr>
440
441 The two sub-expressions are evaluated and the usual comparison
442 operator is performed.
443
444 If the sub-expressions are numeric, then numeric comparison is done.
445 If either sub-expression is non-numeric, then both expressions are
446 converted (if necessary) to strings and string comparison is done.
447
448 =item B<!> I<expr>
449
450 Boolean negative of I<expr>.
451
452 =item I<expr> B<+> I<expr>
453
454 For numeric sub-expressions, this performs addition.
455
456 If both sub-expressions are strings, this performs string
457 concatenation.
458
459 Other types give an error.
460
461 =item I<expr> B<-> I<expr>
462
463 =item I<expr> B<*> I<expr>
464
465 =item I<expr> B</> I<expr>
466
467 =item I<expr> B<mod> I<expr>
468
469 Both sub-expressions are evaluated, and if both are numeric, then the
470 result is subtraction, multiplication, division or modulo.
471
472 Other types give an error.  Note that I<mod> really is an infix
473 operator.
474
475 =item B<len> I<expr>
476
477 If I<expr> is a string, this returns the length of the string.
478
479 =item I<variable>
480
481 The value of the named variable.
482
483 Previously undefined variables are automatically initialized to the
484 empty string.
485
486 =item B<prev> I<variable>
487
488 The I<previous> value of the named variable.  This means, the value
489 that it had last time this when-job ran.
490
491 If the when-job has not run yet, then this returns C<"">.
492
493 Job state is preserved across file reloads, but I<only> for jobs that
494 are explicitly named.  If you find that jobs using C<prev>, C<changes>
495 etc are running unnecessarily when the jobs file is edited or
496 uploaded, try giving the jobs an explicit name.
497
498 =item B<changes> I<variable>
499
500 If the named variable has changed since this job last ran, then this
501 evaluates to true, else false.
502
503 This is the same as writing C<prev variable == variable>.
504
505 =item B<increases> I<variable>
506
507 If the named variable has changed and increased since this job last
508 ran, then this evaluates to true, else false.
509
510 This is the same as writing C<prev variable E<lt> variable>.
511
512 =item B<decreases> I<variable>
513
514 If the named variable has changed and decreased since this job last
515 ran, then this evaluates to true, else false.
516
517 This is the same as writing C<prev variable E<gt> variable>.
518
519 B<Note:> There is a subtle gotcha with the I<decreases> operator: The
520 first time the expression is evaluated, the job has (by definition)
521 not yet run.  Therefore C<prev variable> evaluates to C<""> (see
522 definition of I<prev> above).  Since it is always true that
523
524  "" < anything
525
526 the I<decreases> operator evaluates to false, and since this usually
527 means the job does not run, the operator always evaluates to false.
528
529 To fix this, ensure that the variable is initialized (see
530 L</SETTING THE INITIAL VALUE OF VARIABLES> below).
531
532 =item B<reloaded ()>
533
534 This evaluates to true the first time the expression is evaluated
535 after the jobs file has been reloaded or the daemon restarted.
536 Thereafter it evaluates to false.
537
538 Don't use this to initialize variables: it won't do what you mean.
539
540 =item B<false>
541
542 =item B<true>
543
544 Constants that evaluate to boolean false or true respectively.
545
546 =item I<"any string">
547
548 Any string.
549
550 In a boolean context, the empty string evaluates to false, and
551 non-empty strings evaluate to true.
552
553 =item I<N>
554
555 Any integer.  (Arbitrarily large integers are supported.)
556
557 In a boolean context, 0 evaluates to false, and non-zero evaluates to
558 true.
559
560 =item I<N.>
561
562 =item I<.N>
563
564 =item I<N.N>
565
566 =item I<N.NeN>
567
568 Any floating point number.
569
570 In a boolean context, 0 evaluates to false, and non-zero evaluates to
571 true.
572
573 =back
574
575 =head2 SHELL SCRIPTS
576
577 The code between C<E<lt>E<lt> ... E<gt>E<gt>> is a shell script.  It
578 is executed using C<$SHELL>, or if that environment variable is not
579 set then C</bin/sh>.
580
581 =head3 SHELL SCRIPT VARIABLES
582
583 Every variable that has been set (using the whenjobs I<--set> option)
584 is exported to the script, so you can simply get the value of any
585 variable by writing C<$name>.
586
587 In addition, there are some special variables available:
588
589 =over 4
590
591 =item C<$JOBNAME>
592
593 The name of the job.  If the job has been named explicitly, then that
594 name is available through this variable, else it will be some implicit
595 name like C<job$1>.
596
597 =item C<$JOBSERIAL>
598
599 The serial number of the job.  This is simply a variable that
600 increments each time a job is run, and is unique to that run of the
601 job.
602
603 =back
604
605 Other environment variables such as C<$HOME>, C<$LOGNAME> etc are
606 available as normal.
607
608 =head3 SHELL SCRIPT TEMPORARY CURRENT DIRECTORY
609
610 The shell script runs with its current directory set to a temporary
611 directory.  The temporary directory is removed when the shell script
612 exits.  Therefore you can write temporary files here without worrying
613 about cleaning them up.
614
615 If you want to store permanent state, then you have to save it to a
616 well-known directory, eg. C<$HOME>, C</var> etc.
617
618 =head3 SHELL SCRIPT USER
619
620 The shell script runs as the ordinary user.  It has no special
621 privileges.
622
623 =head2 JOB NAMES
624
625 Jobs are given implicit names (C<job$1>, C<job$2> etc.).  You can also
626 name jobs explicitly by preceeding the "every" or "when" statement
627 with C<job "name">:
628
629  job "poll source"
630  every 10 seconds :
631  <<
632    # ...
633  >>
634
635 The job name is passed to the shell script in the C<$JOBNAME>
636 environment variable.
637
638 =head2 OCAML EXPRESSIONS
639
640 As well as simple "every" and "when" expressions, advanced users may
641 want to use arbitrary OCaml expressions, functions, etc in the jobs
642 script.  These are useful for factoring common code or strings, for
643 setting the initial values of variables, or for defining pre and post
644 functions.
645
646 A simple example of an OCaml expression is:
647
648  let prefix = "daily_"
649  
650  job (prefix ^ "virus_scan")
651  every day :
652  <<
653    # ...
654  >>
655  
656  job (prefix ^ "disk_check")
657  every day :
658  <<
659    # ...
660  >>
661
662 which creates two jobs called C<"daily_virus_scan"> and
663 C<"daily_disk_check"> (C<^> is the OCaml string concatenation
664 operator).
665
666 OCaml expressions have access to a library of functions called
667 B<Whentools> which is described below.  It lets you set variables,
668 create jobs algorithmically, etc.
669
670 The OCaml expressions run once, when the jobs file is being loaded or
671 reloaded.
672
673 =head3 SETTING THE INITIAL VALUE OF VARIABLES
674
675 Variables are created when they are referenced, and until set they
676 have the value empty string (just like the shell).  Across file
677 reloads, the previous values of variables are preserved.
678
679 To initialize a variable to a known value when the jobs file is
680 loaded, call one of the C<Whentools.set_variable*> functions as in
681 this example:
682
683  let () =
684    Whentools.set_variable "name" "Richard";
685    Whentools.set_variable_int "counter" 0
686
687 =head3 PRE FUNCTIONS
688
689 Before a job runs, you can arrange that a C<pre> function is called.
690 This function may decide not to run the job (by returning C<false>).
691
692 One use for this is to prevent a particular job from running if there
693 is already an instance of the same job running:
694
695  job "only one"
696  pre (Whentools.one ())
697  every 10 seconds :
698  <<
699    # Takes longer than 10 seconds to run, but 'Whentools.one ()'
700    # will ensure only one is ever running.
701    sleep 11
702  >>
703
704 When using pre functions, jobs must be given an explicit name, ie.
705 you must use the C<job> statement.
706
707 A number of pre functions are available in the library; see below.
708
709 You can also write your own post functions (in OCaml).  The function
710 is passed one argument which is a C<Whentools.preinfo> struct, defined
711 below.  It should return a boolean: C<true> if the job should run, and
712 C<false> if the job should not run.
713
714 Note that a fresh serial number (see L</JOBSERIAL>) is assigned to
715 each run, whether or not the job actually runs because of
716 preconditions.
717
718 =head3 POST FUNCTIONS
719
720 After a job runs, you can control what happens to its output by
721 writing a C<post> function.  To write a post function you have to
722 name the job (ie. have an explicit C<job> statement).  Put C<post ...>
723 after the job name like this:
724
725  job "poll source"
726  post (Whentools.mailto "you@example.com")
727  every 10 seconds :
728  <<
729    # ...
730  >>
731
732 A number of post functions are available in the library; see below.
733
734 You can also write your own post functions (in OCaml).  The
735 function is passed one argument which is a C<Whentools.result> struct,
736 defined below.
737
738 =head3 WHENTOOLS LIBRARY
739
740 =head4 Functions
741
742 =over 4
743
744 =item B<Whentools.mailto> [I<~only_on_failure:true>]
745 [I<~from:from_address>] I<email_address> I<result>
746
747 This built-in post function sends the result of the script by email to
748 the given email address.
749
750 If the optional C<~only_on_failure:true> flag is set, then it is only
751 sent out if the script failed.
752
753 If the optional C<~from> flag is set, then the from address is set
754 accordingly.  This is sometimes needed when sending mail.
755
756 Note the C<result> parameter is passed implicitly by the daemon.  You
757 do not need to add it.
758
759 Here are some examples of using the mailto function:
760
761  job "ex.1"
762  post (Whentools.mailto "you@example.com")
763  every 10 seconds :
764  <<
765    # do something
766  >>
767
768  job "ex.2"
769  post (Whentools.mailto ~only_on_failure:true
770                         "you@example.com")
771  every 10 seconds :
772  <<
773    # do something
774  >>
775
776  let from = "me@example.com"
777  let to_addr = "you@example.com"
778  
779  job "ex.3"
780  post (Whentools.mailto ~from to_addr)
781  every 10 seconds :
782  <<
783    # do something
784  >>
785
786 =item B<Whentools.max> I<n>
787
788 This built-in pre function ensures that a maximum of I<n> instances of
789 the job are running.
790
791 It checks the list of running jobs, and if I<n> or more instances are
792 already running, then it returns C<false>, which ensures that the new
793 job is not started.
794
795 =item B<Whentools.one> I<()>
796
797 This built-in pre function ensures that only one instance of the job
798 is running.  It is the same as calling:
799
800  Whentools.max 1
801
802 =item B<Whentools.set_variable> I<name> I<string>
803
804 Set variable I<name> to the string.
805
806 =item B<Whentools.set_variable_bool> I<name> I<b>
807
808 Set variable I<name> to the boolean value I<b>.
809
810 =item B<Whentools.set_variable_int> I<name> I<i>
811
812 Set variable I<name> to the integer value I<i>.
813
814 =item B<Whentools.set_variable_string> I<name> I<s>
815
816 Set variable I<name> to the string value <s>.  This is
817 the same as I<Whentools.set_variable>.
818
819 =item B<Whentools.set_variable_float> I<name> I<f>
820
821 Set variable I<name> to the floating point value I<f>.
822
823 =back
824
825 =head4 Structures
826
827 =over 4
828
829 =item B<Whentools.preinfo>
830
831 This structure is passed to pre functions.  It has the following
832 fields:
833
834  type preinfo = {
835    pi_job_name : string;           # Job name.
836    pi_serial : Big_int.big_int;    # Job serial number.
837    pi_variables : (string * variable) list; # Variables set in job.
838    pi_running : preinfo_running_job list;   # List of running jobs.
839  }
840  and preinfo_running_job = {
841    pirun_job_name : string;        # Running job name.
842    pirun_serial : Big_int.big_int; # Running job serial number.
843    pirun_start_time : float;       # Running job start time.
844    pirun_pid : int;                # Running job process ID.
845  }
846
847 =item B<Whentools.result>
848
849 This structure is passed to post functions.  It has the following
850 fields:
851
852  type result = {
853    res_job_name : string;  # job name
854    res_serial : big_int;   # job serial (same as $JOBSERIAL)
855    res_code : int;         # return code from the shell script
856    res_tmpdir : string;    # temporary directory script ran in
857    res_output : string;    # filename of stdout/stderr output
858    res_start_time : float; # when the job started
859  }
860
861 =back
862
863 =head1 FILES
864
865
866
867 =head1 ENVIRONMENT VARIABLES
868
869
870
871 =head1 SEE ALSO
872
873 L<whenjobsd(8)>
874
875 =head1 AUTHOR
876
877 Richard W.M. Jones L<http://people.redhat.com/~rjones/>
878
879 =head1 COPYRIGHT
880
881 Copyright (C) 2012 Red Hat Inc.
882
883 This program is free software; you can redistribute it and/or modify
884 it under the terms of the GNU General Public License as published by
885 the Free Software Foundation; either version 2 of the License, or
886 (at your option) any later version.
887
888 This program is distributed in the hope that it will be useful,
889 but WITHOUT ANY WARRANTY; without even the implied warranty of
890 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
891 GNU General Public License for more details.
892
893 You should have received a copy of the GNU General Public License
894 along with this program; if not, write to the Free Software
895 Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.