+
AMDG

bibsearch Documentation

bibsearch is a simple program, designed for a simple task, so this documentation is pretty much exhaustive. The FAQ also offers much valuable information on the use of the program. However, in terms of overall tutorials, this document is the most useful.

Briefly, bibsearch is a command-line utility for reading and searching the Bible. It supports multiple languages; searching with the full power of regular expressions; and a powerful buffer interface. Read on for more.

Contents

Installation

To install bibsearch, you first must decide how you plan to use it. If you will be the only one using the program, it's probably easiest just to install it yourself in your home directory somewhere. Select an appropriate directory (or create it), and unzip and extract the tarball. If, on the other hand, there are multiple users on the computer and all may use bibsearch, it's better to install it in a more public place. You'll need to be root to do this. I'd suggest /usr/share somewhere, but anywhere public will do.

Next, unzip and extract the tarball. You can do this in one or two steps; spare your computer the extra process and do it all at once. You'll also type less and reduce your risk of carpel tunnel. Try something along these lines: tar -xzvvf bibsearch-v0.9.x.tar.gz. This will unzip (the z) and extract (the x) the tarball, and you should end up with a directory called "bibsearch" containing all the extractd files.

Make sure that your new bibsearch directory contains all the necessary files. You should find the following:

If you don't have all these, please notify me at dgoodmaniii at gmail dot com, as this means that the tarball I've uploaded is corrupted in some way and I need to put up a new one. Otherwise, move on.

Now comes the alteration of the program file, bibsearch.pl. This will be minor and easy, if it's even necessary. You need to make sure that bibsearch is pointed at your Perl executable in order to work. Perl is pretty well guaranteed to be installed on your system, if you're running Linux or BSD; if it isn't, install it immediately using whatever package management system your distribution uses, or from source if it doesn't, as it's among the most useful programs that Linux can boast about having standard.

Your Perl executable is probably just where bibsearch.pl assumes that it is: /usr/bin/perl. However, it may be elsewhere, such as /bin/perl, /usr/local/bin/perl, or anywhere else. Run locate perl and you ought to find it. If it's not there, change the first line of your bibsearch.pl to refer to your Perl executable. For example, if your executable is /usr/local/bin/perl, change the first line of bibsearch.pl to read: #!/usr/local/bin/perl. That's all you need to do. Most likely, though, your Perl is in the same place as mine, and this will be unnecessary. Once you've determined whether this is needed and done it if so, proceed.

Now you need to figure out your bash script, named simply bibsearch. First, edit bibsearch and make sure that its first line points to your shell, the same way you made sure the first line of bibsearch.pl pointed to your Perl executable. If you're not sure where your shell is, type locate bash (it's a bash script, after all) and make that first line point to it. Most likely, this will be the same, as well.

Next, you'll find a line in bibsearch which has the cryptic-looking mark "BIBPATH" in it. BIBPATH, the script says, equals nothing; it's just an equals sign and a bunch of space. As the name implies, you're supposed to put a path there. Make sure that the path which equals BIBPATH is the path of the directory holding your bibsearch.pl. That's all you need to do. Replace what's there with the directory holding your bibsearch.pl. Then move on. Something like this should be about right: BIBPATH=/usr/local/bibsearch/. (Without the period.)

If you don't do this, when you try to run bibsearch through the script (rather than through bibsearch.pl directly), you'll get an error message suggesting what the problem is. Thanks to Bill Powell for suggesting this; before it just complained that the path was wrong.

Now, copy your bibsearch into your directory path somewhere. Probably /bin or /usr/bin will do nicely. Just make sure that it's someplace that your shell searches when you issue a command. If you're not sure what those places are, you can type env | grep PATH into your shell and use one of the directories that come up, but /bin and /usr/bin are pretty well guaranteed to be in there.

Now, wherever you are in your directory structure, simply typing bibsearch will invoke the program. Why all the indirection? Well, if you're geeky enough to care (like me), there are two main reasons:

  1. It makes it easier on me. This way, I don't need to write an installation script that finds your Perl executable for you and alters bibsearch.pl accordingly. Since this is one of many projects for me, it's much easier for me to maintain bibsearch without having to deal with that. And it's not really that hard, after all.
  2. It makes upgrading easier. When you upgrade, there's no need for you to do all this again. The bibsearch you've put in your command path is still there; all you need to do is replace your bibsearch.pl when you unpack the tarball containing the new version, and typing bibsearch will invoke the new program (once you've fixed the first line of bibsearch.pl, of course). So upgrading is a cinch, whereas without the bash script you'd have to either copy the new bibsearch.pl into your path again (unless you added the directory to your path; but expanding your path unduly can be risky), and then you'd have to alter the source in bibsearch.pl so that bibsearch would know where to find the texts (it's a relative path right now, so as to avoid, once again, an installation script which would detect where you'd put the executable and where you'd put the texts and altering the source to include a full path to them). If you know a better way, please relieve my ignorance. Until then, this seems like the best solution.
So that's why. Now, you should be ready to go. If it still doesn't work, please feel free to email me (dgoodmaniii at gmail dot com). I do reserve the right not to be able to figure it out if I don't have physical access to your system; but I'll do my best to help.

Running bibsearch

bibsearch can be run interactively, by entering the bibsearch program itself and issuing commands directly, or in batch mode, by running it from the command line and sending it a single command from the shell.

When running bibsearch interactively, one can enter the program in two ways. By using the bash script (see Installation), or by calling the Perl program directly. To enter it using the bash script (which is normally recommended), you simply type "bibsearch", hit enter, and you're there. A brief message will be printed and you will be presented with bibsearch's query prompt (-->), at which point you can begin to type queries. Alternatively, you can use the Perl program directly by going to the directory where it's located and typing "bibsearch.pl". The same thing will then happen.

When running bibsearch in batch mode, you run it from the command line and send it commands from there. Normally, you'll want to use the bash script. In this case, you invoke the program in the normal way, but followed by your query in quotation marks (type bibsearch "query"). If you invoke the Perl program directly, use the "-e" flag by typing bibsearch.pl -e "query".

And that's the basics of running bibsearch. Now, we can move on to the specific commands which the program accepts.

Basic Command Structure

Don't worry; this is extremely basic. Basically, bibsearch commands consist of two parts: the type of query, and the options associated with that query. Every command will have at least the first; the vast majority will have the second, as well.

The type of query could be a get (see Reading the Bible), a search (see Searching the Bible), a write of a buffer (see Buffers), and so on. It can consist of a single letter or of the whole word (e.g., get and g are equivalent as far as bibsearch is concerned). The type of query must come first in any statement given to bibsearch. Internally, this is because bibsearch looks at the first thing in a query to figure out what it ought to run next. If it's not first, bibsearch will choke on it; if the first letter isn't a valid command, it will complain about this, and if it is a command, it will probably misinterpret what you want because you're not feeding it what it expects. So remember to put the type of query first.

The options associated with a query are explained in the respective sections for each type of query. They include the language desired; the database to be searched; the book, chapter, and verse to be got; and so on.

Terminology for these things is simple: query types, which must go first in a command, are called commands, while the rest are called options.

It's also important to note that bibsearch outputs in two ways: either to the screen, or to a buffer (actually, when outputting to a buffer, or file, bibsearch outputs to the screen, as well). It does not do so in precisely the same form, however. Internally, bibsearch's Bible texts are listed one verse per line; this is true no matter how long the verses are. So when outputting to the screen, bibsearch kindly breaks the lines up at the first space after sixty characters to make it easier to read. However, while that's nice for a human reader, it makes it much more difficult to process your output with another program, including bibsearch itself (e.g., when searching one of your own buffers with bibsearch). Therefore, bibsearch maintains this one-verse-per-line rule when outputting to a buffer. This will probably have exactly zero effect on the end user in most cases, so feel free to immediately forget about this behavior when you finish this paragraph.

Now that that's out of the way, we can get on to actually using the program. St. Jerome, pray for us.

Reading the Bible

Have you ever been reading some book or other and found an interesting proposition supported by a Scriptural citation, without any quotation or explanation? Have you ever thought that this citation was interesting, or dubious? Have you ever been presented with a Scriptural quotation without any context and wondered what the rest of that section of Holy Writ might say? This function of bibsearch is for just this sort of situation.

The function bibsearch uses for this is the "get," by which citations are grabbed from the Bible and printed to the screen. They may also be redirected to a file, for later reading, though if you're on the command line running in batch mode (that is, you're executing a command in the shell, not entering bibsearch itself and running commands within that), you'll want to use your shell's redirection function instead. The form of either is the same, as we'll shortly see.

To execute a "get," start by typing "get". Go ahead, type "get" and hit enter. You'll get a helpful (maybe) error message that you told bibsearch to get something but not want you wanted it to get. bibsearch is naturally confused by this. So we might as well move on to telling bibsearch what to get as well as telling it to get it.

By the way, you can also type "g" instead of "get." In fact, any of the query commands ("get", "?", "write", "help", "list", "print", "buffers", "quit") can be replaced with their first letter. This is generally a good idea, as it saves keystrokes and enables quicker work. Future examples will always use these abbreviations, except for their first referral.

What you need to do is give bibsearch what file (book) you want to get the citation from, along with the citation you want bibsearch to get for you. So type your command in a little more detail; tell bibsearch that you want to read. For example, say you saw a reference to Joshua 24:15. To read it yourself, type: g Jos24:15. bibsearch will obligingly print that verse out to the screen for you, complete with the chapter and verse number (not with the book name; since gets only work on one book at a time, there's no need for that; but when you write it to a file, the book name will be written out, as well, so that you'll be able to make sense of search results from that file as well as when you read the file later, if you choose to save it).

But what is all that? bibsearch's default language is Latin, specifically the Latin Vulgate, since that translation alone is guaranteed by the Church to be without error. If you want to read in English, you have to let bibsearch know that you want English. So type in your get again, this time telling bibsearch that English is your preferred language at this moment: g -le Jos24:15. bibsearch will just as obligingly print out the English translation (Douay-Rheims) of Joshua 24:15 for your spiritual edification.

By the way, try throwing some spaces in there. For example, try g -l e Jos 24:15. For that matter, try g -le Jos 24,15. bibsearch won't have a problem with any of those. Either a colon or a comma can separate chapter and verse, and you can take or leave the space after any option (like -l) or book name. bibsearch tries to be flexible about these things.

bibsearch will allow getting ranges of verses also. For example, say you want the first ten verses of the first chapter of Genesis. Simply include the verse range in your get query like so: g -le Gn1:1-10. bibsearch will obligingly print to the screen the first ten verses of Genesis 1. It's that simple. If you want all the verse from your start point to the end of the chapter, just give a second verse number that's suitably impossible; 999 will probably be good, as in g -le Gn1:1-999. bibsearch will not complain, but will simply stop printing on the last verse of the chapter; in this case, Gn1:31.

bibsearch can also retrieve ranges of verses that span chapters. The syntax is generally intuitive. Simply enter your get query as normal, but supply bibsearch with what can only be a range of verse spanning chapter boundaries; e.g., g 3Rg 14:19-17:12. bibsearch understands the query put in this form and will print it to the screen most obligingly.

bibsearch does, however, expect to have chapter and verse for every part of a citation. So if you want to read whole chapters, you can't just say g 3Rg14-19; bibsearch won't know what you mean, and will obligingly complain and tell you why it's confused and suggest a better way to do what it thinks you're trying to do. It may be wrong, but if it's right and you're trying to get entire chapters, it's offering you the easiest way to get it done. If you want the entirety of these chapters, you must supply a beginning and end verse on both sides of the hyphen. So instead, do g 3Rg14:1-19:999, which guarantees you'll get all the verses in chapter 19, plus all the chapters and verses from 14 until then. In other words, bibsearch will then understand you.

Of course, you can also save these results to buffers. For more on this sort of thing, see Buffers.

Searching

Searching is, as I mentioned before, what I consider to be bibsearch's greatest strength. Many programs exist which allow reading the Bible, and many which allow searching it; but bibsearch has a few unique characteristics which set it over and above the rest (at least, over and above those I've seen):

I think that these and other characteristics of bibsearch give it an advantage over similar tools; and while bibsearch might not have a fancy graphical interface, this makes it all the more powerful when preparing texts, even if one must learn a bit more about how it's used.

So, without further ado, how do we search using bibsearch? The basic command here is ?, sensibly enough; we're essentially asking a question about the Bible, and bibsearch is answering it for us. I'll admit to having been somewhat influenced by Debian's kjv-bible package on this command name, but I also maintain that it's independently suitable.

There is, of course, the standard language option that is present in both gets and searches, -l. The default (when no language option is present) is once again Latin, that being the only infallibly error-free translation ever made; one can also specify Latin with -ll (or, of course, -l l), if one wishes to make choice of language explicit, perhaps for query readability reasons. To search in English, use -le (or -l e) instead.

The next element, which is vitally important, is -d, which specifies the database which one desires to search. I've chosen to use the word "database" here, even though it's not strictly accurate, because it seems the best word which covers all the possibilites. In short, one can search three different types of database:

  1. Individual books of Sacred Scripture. One specifies these with the same abbreviations as one does for a get; consult booklist.txt for a list of the abbreviations until you're familiar with them. Examples might be -dGn (or -d Gn, or -dApc or -d1Cor.
  2. Groups of books from the Sacred Scripture. This is a way to search logical units of the Bible without having to select and search each book individually. Examples include -dmoses (to search the five books of Moses), -dnew (to search the New Testament), or -dpaul (to search the Epistles of St. Paul). Once again, consult booklist.txt for a list of possible groups until you become familiar with what's available.
  3. User-defined buffers. If you save the output of a search or a get to a buffer, you can then use that buffer as the database for a search query. An example might be -d_buffername (buffer names are almost always preceded by an underscore, to let bibsearch know it's dealing with a user-defined buffer; see Buffers for more details).
So naturally your -d option will be pivotal in determining the results that your search will return. So choose carefully which you'd like to use to ensure that your output won't be too broad or too narrow for your purposes.

Another possible (and often useful) option for search queries is -f. This option determines what type of output will be printed to the screen. Without this option, bibsearch only returns book name, chapter, and verse as search results. However, when one specifies the -f option, bibsearch returns book name, chapter, verse, the text of the verse in which the hit was returned. So this can often be extremely useful for going through your results (bibsearch always gives results as if -f were specified to a buffer; again, see Buffers for more information).

Finally, the most important part of your search: what exactly it is you want to find. Following standard regular expression syntax (from, e.g., the ex and vi editors, and the Perl programming language in which bibsearch is written), the search terms are supplied to bibsearch enclosed in forward slashes (/searchterm/). If for some reason you want to include a forward slash in your search (you won't find one), you need to escape it by preceding it with a backslash (\/). Regular expressions, up to and including other special characters (like .), can be used as normal within the forward slashes of the search term. Be sure that you include a closing slash after your search term; failing to do so will confuse bibsearch considerably; it will think that you're searching for nothing and therefore find it, in every single verse that you've searched (? -le -dpaul /veil produces 2335 matches, while ? -le -dpaul /veil/ produces only 7).

In addition to the results of your search, bibsearch will kindly inform you the number of matches it found, what terms it was searching for, and what database it was looking in at the end of the listing of its results. E.g., for the correct query above (? -le -dpaul /veil/, bibsearch prints, in addition to the book name, chapter, and verse of each match, ***7 matches found for /veil/ in "paul"***. This is useful, especially when you've left your computer for a time and returned trying to remember what exactly you were doing.

That's really about all there is to searching the Scriptures with bibsearch. But don't be fooled by the simplicity; the power is considerable. Say, for example, you wanted to search for all verses containing the word "Moses" in the New Testament. The search is easy: ? -dnew -le /Moses/. bibsearch returns 79 matches. But does St. Paul talk about Moses more than do the Gospels? ? -dpaul -le /Moses/ compared to ? -dgosp -le /Moses/ reveal that he does not, at least in quantitative terms (the Gospels mention his name 37 times, while St. Paul does so only 21 times). With buffers (see Buffers), this becomes even more powerful; one can save the New Testament query to a buffer, then search it to find out how many verses mention both Moses and Jesus (10 mention both names, eight of which are in the Gospels and 2 in Acts; none are in St. Paul). This helps one narrow down the most important verses on a given topic, which makes it powerful indeed.

So play around with searching for a while. Study and use regular expressions; they will make your searches even more powerful. Try things. Then, when you're fairly familiar with the capabilities of bibsearch in this regard, you can move on to buffers, among bibsearch's most interesting and powerful features.

Buffers

bibsearch provides a very powerful utility: the ability to direct the output of any get or search query to a "buffer." What is a buffer? A buffer is simply a temporary file which stores some information. bibsearch writes buffers to the /tmp/ directory; if you decide to save one of your buffers permanently (see Saving Your Buffers, you can put them elsewhere). This part of the documentation explains what precisely bibsearch can do with buffers and how to do it. So enjoy; this can be one of the most powerful aspects of bibsearch.

Outputting to Buffers

So you've been discussing a topic with someone---say, women wearing a head covering in church---and you want to email them the relevant texts of the Scriptures for their edification. You know, either through searching bibsearch or through other means, that the relevant portions of St. Paul on the topic is I Corinthians (1Cor) 11:1-16. You know what to do: execute a get. The get query necessary is simple: g -le 1Cor11:1-16. Now you have the relevant text on your screen, but this may or may not be useful for you. You want to get this text to your friend.

There are actually two steps necessary for doing so:

  1. Make the get query and save it to a buffer.
  2. Save that buffer permanently in a location of your choice.
This section of our documentation covers step one. Step two will be covered later (see Saving Your Buffers).

As a user of free software, you're probably familiar, at least a little, with the bash shell. If not, here's a brief primer on what's called redirection of your output. When you execute a command in the shell (that's when you've got a prompt and you have to type things to make the computer do something), you usually get some kind of output. For example, go to your shell (open a terminal window) and type "echo hello". Your shell will dutifully echo "hello" back at you. That "hello" (the one the shell produced, not the one you typed) is your output.

Now, try another command. Type "echo hello > newfile". Make sure this is a directory where you have write permission. Notice that you have no more output, at least visibly; you just get another prompt. But type "ls" and examine your directory. You should see a file named "newfile" there. You guess it; you've just sent the output of your command into that file. The shell, not finding a file by that name, created it and sent the output to it afterwards. All output in a Unix-like system can be redirected in this way. Neat, huh?

Warning: the shell doesn't babysit its users. If you try to redirect your output to a file that already exists, it can and will erase the content of that file and put your output into it. bibsearch mimics this behavior, though you're unlikely to erase a file with bibsearch buffers because of the unique extensions. Nevertheless, make sure you only output to files that don't yet exist or you aren't afraid to erase.

bibsearch imitates this behavior exactly. Your output will be redirected to a buffer of (almost) arbitrary name by appending that greater-than sign and your filename to the end of your query. bibsearch will ignore the space following the ">" just as the shell does, but it's a good idea to include it for readability's sake. So your query should now be: g -le 1Cor11:1-16 > veiltext. This will save the output of your query to a file, veiltext.eng, in the /tmp/ directory of your system. The ".eng" comes from the language declaration, in this case -le. In the absence of such a declaration, it assigns ".lat" for Latin, the default language. This ensures that your buffers will always be marked as being in the language that they were filled from.

Don't use buffers of the same names but different languages. Most things will work, but it may cause unexpected results.

The shell also has another redirection function: appending. Run another command at your shell: "echo world >> newfile". Now open up newfile, or print it to your screen (run "cat newfile" at your shell). You'll see your "hello" still there, but another line, "world", underneath it. Appending simply places the output at the end of the file. You guessed it: bibsearch can do this, too, in exactly the same way. This way, you can direct your output to a buffer without wiping the contents of the buffer first. Your buffer will then contain its original contents with the new contents attached to the end.

Search queries can also be written or appended to buffers in this way. Try things and knock yourself out.

One problem I've not been able to work out: you cannot write or append to a buffer in the same query as you read from it. Actually, I've worked it out; it'll just be a bear to fix, so it hasn't gotten done yet. Fortunately, disk space is cheap, so feel free to multiply buffers to your heart's content. Just make sure they have meaningful names so you remember what's in them. (Or print its contents out if you forget; see Working with Buffers).

Another difficulty: for some reason I've not been able to determine, bibsearch sometimes won't work with a buffer two queries in a row (that is, it won't overwrite a buffer two queries in a row). Instead, it simply wipes it and doesn't write to it. I haven't been able to reproduce this bug reliably; if you are, please let me know the conditions under which it occurs and I will fix it. But most of the time (for example, when writing to a buffer and then appending something to it), this is not a problem, and bibsearch happily does the writing and appending with neither error nor complaint.

Otherwise, however, the buffer utilities are rock-solid and ready to roll. Use them to full advantage. Note that bibsearch deletes all your buffers upon exit, in an attempt to keep your disks clean; if you want a buffer not to disappear, you must inform bibsearch of this desire.

Working with Buffers

Writing and appending to buffers is, however, only the beginning. You can also print the contents of a buffer and list the available buffers on the screen. While this doesn't sound very exciting, when you've been engaged in a long research project on some topic in the Scriptures, it'll be a big help to be able to check on the contents of a buffer and to list which buffers you've saved.

To list the buffers you've already saved to (that is, to list currently available and existing buffers), simply enter the command buffers (or, of course, simply b. This will list all the buffers that are currently open, including those that have been written permanently to disk.

To print any buffer to the screen, just type print (or the abbreviation p, plus the language declaration (if the buffer is not in Latin), plus the name of the buffer preceded by the buffer marker, in bibsearch the underscore character (_). An example query is p _mybuffer. Again, simple and unexciting, but extremely useful when sorting through your buffers determining which ones you want to save.

That underscore is necessary whenever you're dealing with a buffer, except when you are writing or appending to it. In those cases, the > or >> sufficiently identifies the buffer for bibsearch. The underscore in other situations lets bibsearch know that you want it to work with a buffer, rather than one of its normal files. The underscore is not part of the buffer's name; it's just an identifying marker for the program. When you save a buffer, the file name will not include the underscore.

Note that the language declaration (-le or -ll, for example) is not required when dealing with buffers in this way. This is because bibsearch stores the buffers without a language declaration. I mention this because earlier versions of bibsearch (prior to 0.9.8) behaved rather strangely by storing buffers with a language declaration. This was unnecessarily limiting and has been completely done away with.

Note that, because of the elimination of the language element on buffers, you can append texts of different languages to a buffer. Try, e.g., running the following queries one after the other: ? -dpaul /velam.n/ > mybuffer, then ? -le -dpaul /veil/ >> testbuf. Now run p _mybuffer. bibsearch will dutifully print the buffer mybuffer in all its multilingual glory. This makes comparing translations, for example, extremely easy. It will be every more powerful when additional languages are added (which is, again, a trivial matter, if text files are available).

Finally, please also note that bibsearch is not printing the contents of the buffer exactly as it appears in the file. It's only printing it mostly as it appears in the file. bibsearch formats screen output so that verses are broken up across several lines at a reasonable length (the first space after sixty characters). bibsearch does this with buffer printings, too. So you're getting the same text as is in the buffer, but it's made suitable for screen viewing by men, rather than for line-reading machines like bibsearch. This is a minor point that most users will probably rarely notice.

Saving Your Buffers

So. Now you've got your results saved in buffers, and your buffers contain exactly the texts that you want to keep and refer to later, or import into your file, or whatever. But when you quit bibsearch, you lose your buffers, bibsearch being a real stickler for freeing up unneeded disk space. What do you do? Are you forced to run bibsearch only in batch mode?

Of course not; I wouldn't have asked the question were that the case. No, bibsearch allows you to save your buffers permanently to disk, so that it won't destroy the buffer when you quit (though it will still destroy the temporary buffer in /tmp, as when you quit bibsearch the program assumes that you're done with it). This is another very useful feature of bibsearch.

The command is simply write (or its obvious abbreviation, w. You follow your w with the name of your buffer preceded by an underscore. So a complete example command of this type is w _mybuffer. And that's really all there is to it. In this case, bibsearch will, by default, save the buffer permanently, with a filename identical to that of the buffer's name, in the user's home directory, as identified by the shell's $HOME variable. (If you don't know what the shell's $HOME variable might be, don't worry; it'll save it wherever you're put when you log in.)

Want the buffer saved somewhere else? bibsearch also makes this easy. Simply identify the directory you want bibsearch to save the buffer to with the -d option (not to be confused with the -d option employed when executing a search query). The -d is supposed to stand for "directory". Now, the directory you specify must be a full, absolute path, beginning with a leading slash. A trailing slash at the end is optional. Make sure that you have write permissions on the directory, or it won't be saved at all.

Note that, once you've written a buffer with w, the buffer is still available to you, but any changes you make to it after writing will not be reflected in your saved copy. You'll have to write it again if you make changes to it that you want to keep; if you save it to the same directory, it will simply and quietly overwrite the original saved copy there.

Conclusion

So that's the bibsearch utility. I pray that it assists you and many men in their studies of the Sacred Scriptures, and I beseech the Almighty God that by the prayers of St. Jerome, St. Augustine, St. Thomas Aquinas, St. Thomas More, and all the great lovers of the Word of God throughout history, and especially by those of the Blessed Virgin Mary, Mother of God, all those who write and use this program may by it be brought closer to Jesus Christ, the Word of God Itself, Who livest and reignest with God the Father in the unity of the Holy Spirit, one God, through all the ages of ages. Amen.

SourceForge.net Logo