1.1. INTRODUCTION

LifeLines is a genealogy program that runs on UNIX systems. It maintains genealogical records (persons, families, sources, events and others) in a database, and generates reports from those records. There are no practical limits on the number of records that can be stored in a LifeLines database, nor on the amounts or kinds of data that can be kept in the records. LifeLines does not contain built-in reports. Instead it provides a programming subsystem that you use to program your own reports and charts. The programming subsystem also lets you query your databases and process your data in any way. LifeLines uses the terminal independent features of UNIX to provide a screen and menu based user interface.

LifeLines is a non-commercial, experimental system that is use at your own risk software. I developed LifeLines for personal use and shared it with friends. Enough of a demand arose through word of mouth and internet, that I have made the LifeLines source code and other information freely available under an MIT-style license reproduced below:

" Copyright (c) 1991-1999 Thomas T. Wetmore IV Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. "

The source code, documentation and a collection of report scripts are located at http://lifelines.sourceforge.net/. You can also find binary kits for some platforms. If you are a developer and wish to contribute enhancements, please sign up on sourceforge and contact Marc Nozell who is currently managing the project.

Prior to 1999, Lifelines was available on the ftp sites, ftp.cac.psu.edu and hoth.stsci.edu. Please use sourceforge instead.

1.2. INSTALLATION

You may be installing LifeLines from a source distribution package or as an executable program already prepared for your UNIX (or MS-Windows) system. The source distribution comes with the readme, build script and make files necessary to build LifeLines. Follow the instructions in the readme file. A number of executables are built which can be put it in a directory in your execution path. If you get the program in executable form, follow whatever instructions came with it.

The source distribution package also contains documentation and some LifeLines programs. Included with these in the reports directory is a brief overview of the reports in the file index.html.

1.3. STARTING LIFELINES AND CREATING DATABASES

You normally start LifeLines with the command: lines database where database is the name of a LifeLines database. If LifeLines finds the database, LifeLines opens the database and takes you to the program's main menu. If the database doesn't exist, LifeLines asks whether it should create it, and if you answer yes, does so. You may create any number of databases, but only one can be accessed by LifeLines at a time. If you built the LifeLines executable from the source package, the executable may be named llines rather than lines. You may either change its name or invoke LifeLines by using the command llines instead.

The full command line interface to LifeLines is:

        lines [-acdfiklnortuwxzCFI][database]
     

The following options are supported:

the -o option specifies the initial filename to use for output when running reports. It only applies to reports run with the -x option. This option has no effect on interactively run programs.

The -r option opens the database with read-only access. When in this mode LifeLines will not let you modify the database; no other operations are affected. The -w option opens the database with writeable access. If the database cannot be opened with the requested mode LifeLines quits immediately. When you open a database with neither the -r or -w options, LifeLines first tries to open the database with writeable access; if not possible LifeLines then tries to open the database with read-only access; and if this is not possible LifeLines quits. A LifeLines database may be open simultaneously by any number of programs with read-only access; however, if a database is open by a program with writeable access, then it cannot be opened by any other other program.

In rare situations the read/write mode mechanism can fail; when this happens a database may appear unopenable. If this happens use the -f option to force open the database; this will open the database and reset the mode mechanism. This is a dangerous feature; you can use it to open the same database with writeable access more than once; the results are unpredictable and generally disastrous.

The multiuser protection supplied by this reader/writer access mechanism is provided via a flag setting in the database, so both read-only and writeable access actually alter the database (read-only access only alters the value of this flag). For truly read-only access, e.g., for use with read-only media, the best solution is to lock (-ly) the database before copying it to the read-only media. This annotates the database itself as being for immutable access. Alternatively, to use a database already on read-only media and not so annotated, use the immutable (-i) flag.

By default lifelines supports a traditional family concept, that is, each family has at most one father and one mother. The -n flag relaxes this restriction. However, not all the code in lifelines supports these relaxations. For example, the default family browse screen will only display two parents, however by switching to one of the gedcom modes of displaying the family you can see all the data.

If you don't give the name of a database on the command line, LifeLines will prompt you for it. If the name you supply is an absolute pathname or a relative pathname it is used as the path to the database. If you provided a simple filename and you use the LLDATABASES variable or user options (described later), LifeLines will search for the database in the directories named in the variable; this can be very convenient. If LLDATABASES is not set the filename you enter is looked for in the current working directory.

If you would like to choose a database from a list of existing ones, enter a single question mark and press return when LifeLines prompts you for the database name. LifeLines will then display a list of all databases that it can find, and you may select one from the list.

1.4. INTRODUCTION TO GEDCOM

LifeLines records are stored in GEDCOM format; you organize, edit and maintain your data in this format. GEDCOM is a standard that defines a file format for moving genealogical data between computer systems. LifeLines has adopted this format for structuring the records in its databases. This approach provides a structured yet flexible method for storing all the data you wish to record. There are few restrictions on the format, amount or type of information you may store in a LifeLines database.

GEDCOM is defined at two levels. At the syntactic level GEDCOM is a simple set of rules for organizing and structuring data into records, with no concern about the types of records, types or formats of information in the records, or the relationships between records. At the semantic level GEDCOM adds an additional set of rules that specify what record types are allowed, how records must be structured, how data within the records must be identified and formatted, and what specific relationships between the record types are allowed. In principle there can be multiple semantic versions of GEDCOM, though in practice there is only one, lineage-linked GEDCOM. Unfortunately this semantic version of GEDCOM is poorly defined, and every genealogical system has interpreted it in different ways.

LifeLines uses GEDCOM primarily at the syntactic level, though it does impose a few of the generally accepted lineage-linked semantic restrictions. This means some important things. It means that you can store all your genealogical data in your LifeLines database, and that you have wide freedom in how you choose your own conventions for structuring and formatting your data. But it also means that the way you store data in your databases can be different from the way that someone else stores their data. This can be a problem if you share data with others or share report programs with other LifeLines users. My recommendation is to use GEDCOM lineage-linking conventions wherever possible.

LifeLines does not use forms or screens to guide you through entering or changing data. Instead you use a screen editor and directly edit the data records. This requires you to understand the GEDCOM format, and be able to edit data in GEDCOM format, before you can use LifeLines. The GEDCOM format is quite simple; this introduction will provide all you need to know about GEDCOM in order to use LifeLines.

Here is an example GEDCOM person record:

  0 @I25@ INDI
  1 NAME Thomas Trask /Wetmore/ Sr
  1 SEX M
  1 BIRT
    2 DATE 13 March 1866
    2 PLAC St. Mary's Bay, Digby, Nova Scotia
    2 SOUR Social Security application
  1 NATU
    2 NAME Thomas T. Wetmore
    2 DATE 26 October 1888
    2 PLAC Norwich, New London, Connecticut
    2 AGE 22 years
    2 COUR New London County Court of Common Pleas
    2 SOUR court record from National Archives
  1 OCCU Antiques Dealer
  1 DEAT
    2 NAME Thomas Trask Wetmore
    2 DATE 17 February 1947
    2 PLAC New London, New London, Connecticut
    2 AGE 80 years, 11 months, 4 days
    2 CAUS Heart Attack
    2 SOUR New London Death Records
  1 FAMC @F11@
  1 FAMS @F6@
  1 FAMS @F12@

A GEDCOM record is made up of lines. Each line has a level number and a tag, and most lines have a value following the tag. The first line in every record has a cross-reference index between the level number and the tag.

Level numbers allow data to be structured to any degree of detail; lines with higher level numbers expand on lines with lower numbers. Each record begins at level 0, and each deeper level increments the level by one. LifeLines does not restrict the structuring depth. Tags are uppercase (by convention) code words that specify the kind of information on the line or on the higher numbered lines that follow. The information after the tag, if any, is the value of the line.

The first line in a record indicates its type. There are four fixed record types in LifeLines databases: person, family, source and event. The first, 0 level line in these records have tags INDI, FAM, SOUR and EVEN, respectively. Besides these record types, you may create your own record types by using any other tag on the 0 level line of a record. The lines that begin records are the only level 0 lines used in LifeLines. Each level 0 line has a cross-reference index between the level number and the tag. This index is the record's internal reference key; other records may refer to this record by using this index. Cross-reference indexes are bracketed by @ characters.

The first line in the example record has the INDI tag, identifying it as a person. The cross-reference index value, I25, can be used by other records to refer to this record.

The second line in the example has the person's name. Each person record in a LifeLines database must have at least one 1 NAME line, and its value must be in GEDCOM name format. This format allows names to be as long as needed, but the surname, which may be placed anywhere in the name, must be separated from the rest of the name by one or two slashes. For example:

1 NAME John/Smith
1 NAME John /Smith/
1 NAME John/Smith/Jr.

The second slash is required only if name elements follow the surname. White space is optional before the first slash and after the second. If you don't know a person's surname, or the person doesn't have a surname, you may use / or // or no slashes at all. For example:

1 NAME Mary//
1 NAME Mary/
1 NAME Mary

The next line in the example gives the person's sex. LifeLines doesn't require a 1 SEX line, but you should include it. The value of the line should be M or F if the sex is known; it can be left blank or set to U or ?, say, if not known. A person must have a 1 SEX line with a value of either M or F before he or she can be made a spouse or parent in a family.

The example record also contains three events: birth, naturalization, and death. An event begins with a level 1 line whose tag indicates the event type. For example, BIRT is the tag for a birth event.

Events usually have at least a 2 DATE and a 2 PLAC line and often a 2 SOUR line. The DATE and PLAC lines give the date and place of the event. The value of a LifeLines DATE line is free format, though LifeLines will try to parse it for specific day, month and year information. The value of a PLAC line is usually a comma-separated list of geopolitical units, starting with the most specific, ending with the most general. The SOUR line indicates the source of information about the event. The SOUR line can be the root of a full description of the source, or the value of the SOUR line can be a cross-reference key that refers to the source record that describes the source.

The naturalization event (with tag NATU) shows a few other lines. The 2 NAME line gives the person's name as recorded in the source (only 1 NAME lines must follow GEDCOM format). The 2 AGE line gives the person's age at the time of the event. The 2 COUR line indicates the court where naturalization occurred.

The final event is a death event (tag DEAT). The 2 CAUS line gives the cause of death.

At the end of the record are three lines that refer to family records. A 1 FAMC line refers to a family record that the person belongs to as a child; its value is the cross-reference index value of that family. A 1 FAMS line refers to a family record that the person belongs to as a spouse or parent.

When using LifeLines to edit a person, you will not be able to edit the cross reference values on the 0 INDI, 1 FAMC or 1 FAMS lines; these are maintained by LifeLines.

Here is an example family record:

  0 @F6@ FAM
  1 HUSB @I25@
  1 WIFE @I26@
  1 MARR
    2 DATE 31 March 1891
    2 PLAC New London, New London, Connecticut
    2 SOUR New London Vital Records
  1 CHIL @I27@
  1 CHIL @I17@

The 0 FAM line assigns the family the cross-reference index of F6. The record contains 1 HUSB and 1 WIFE lines that refer to the two spouses/parents. The record also holds a marriage event (tag MARR) and two 1 CHIL lines that refer to two children in the family. When editing family records, you cannot edit the 0 FAM, 1 HUSB, 1 WIFE, or 1 CHIL lines; these are maintained by LifeLines.

When you create new records for your database, you are free to invent tags and structure your data in any way you see fit. However, it is good practice to use standard GEDCOM tags and value formats. LifeLines does enforce a small set of conventions that you must obey. Within person records, LifeLines requires that you use 1 NAME and 1 SEX lines with their special meanings and value formats. Though not required, LifeLines assumes that you will use 1 BIRT, 1 DEAT, 1 CHR, and 1 BURI lines for birth, death, baptism and burial events, respectively. In family records, LifeLines assumes you will use the 1 MARR event for marriage events. Within person records, you are not allowed to use 0 INDI, 1 FAMC or 1 FAMS lines, since these are used to maintain linkage information. Within family records, you are not allowed to use 0 FAM, 1 HUSB, 1 WIFE or 1 CHIL lines.

The indentation shown in the examples is not part of GEDCOM format. When LifeLines prepares records for you to edit, however, it always indents the records, making them easier to read and understand. You do not need to follow this indentation scheme when you edit the records. Indentation is removed from the data before it is stored in the database.

1.5. MAIN MENU

After LifeLines opens an existing database, or creates a new one, it presents you with the main menu:

Please choose an operation:
   b Browse the persons in the database
   s Search database
   a Add information to the database
   d Delete information from the database
   p Pick a report from list and run
   r Generate report by entering report name
   t Modify character translation tables
   u Miscellaneous utilities
   x Handle source, event and other records
   Q Quit current database
   q Quit program

Select an operation by striking the proper selection letter.

The browse operation lets you browse the database and perform many operations on the data. The search operation provides some simple wildcard search capabilities, which lead into browsing particular records. The add operation lets you add new information, and the delete operation removes information. The report operations read report programs and generates output reports. The modify character translation tables operation changes the translation tables. The miscellaneous utilities operation provides such things as backup and restore. The handle source, event and other records operation gives you access to these three record types. The quit operation closes the database and returns to UNIX.

The browse operation deserves special mention, because it provides a rich environment for searching, viewing, adding, modifying, merging and deleting information in the database. You will find that you operate from the browsing modes most of the time. The operations are all described in later sections.

1.6. CODESET

After you have created a new database, and before you actually add any data to it, is the time to set the codeset to be used in the database.

The codeset (or character encoding, to use precise Unicode terminology) is the decision as to how letters will be represented by the computer. If you have only ever used English letters in computing, you may not have had to encounter this issue, because as it happens, the English letters (a-z and A-Z) are stored numerically in the same fashion in almost all codesets used by computers. However, in the field of genealogy, you are especially likely to meet letters outside of the English alphabet (for example, accented vowels).

You have fundamentally three choices as to what codeset to use in your database, listed below from easiest to most powerful.

First, you may leave it entirely unspecified. This will give the traditional lifelines behavior. This is really only suitable if either (a), you only use English (ASCII) data, or (b), you work in an environment which entirely uses the same 8-bit codeset (eg, a GNU/Linux box which is all ISO-8859-15), and you only run lifelines in English. If you use any non-English data on MS-Windows, this is not likely to be suitable, because the lifelines screens run in the console, but you are likely to use MS-Windows applications either for editing or for viewing output, and the MS-Windows console uses a different codeset from MS-Windows applications. Also, if you use lifelines in a different language than English, this may not be suitable, because the gettext message catalogs (for non-English interface) will not be converted into your codeset.

Second, you may specify a particular 8-bit codeset. Assuming that you have iconv and gettext installed (or you are using the MS-Windows version, which comes with these), you may specify any 8-bit codeset supported by iconv, and iconv supports quite many. A natural choice for Western European languages would be ISO-8859-1, or (for MS-Windows only) CP-1252. With this option, gettext language files will be converted to your codeset.

Third, you may specify the use of UTF-8. This is a Unicode encoding, and is by far the most powerful option. In fact, this is the only really convenient way to be able to store, for example, names in English, names in Russian, and names in Greek, all in the same database, in their native scripts (alphabets). In recent versions, lifelines has become more knowledgeable about handling UTF-8, so that, for example, upper & lower casing only work correctly with versions from 3.0.28 on.

To actually specify a codeset, enter it via the u(tility) o(ptions) page (which is documented below). From the main menu, in the English version, press u to reach the utility page, and then o to edit the user options. To set a codeset of, e.g., ISO-8859-1, enter this string on its own line, without the surrounding quotes: "codeset=ISO-8859-1". Or, to specify the use of UTF-8, "codeset=UTF-8".

Further information about codeset conversion is found in the later chapter of that name (for example, information about producing reports which make use of HTML entity names for non-ASCII characters).

1.7. ENTERING THE FIRST PERSON

Note: Before you add the first person to your database, you specify internal codeset (review the Codeset chapter for information).

Normally you add persons to the database from the browsing modes, but when entering the first person there is no one in the database to browse to. To add the first person to a LifeLines database, first select the add operation from the main menu. You will be prompted with the add menu (described later). Strike p to add a person. LifeLines creates a template of a GEDCOM person record, and puts you in a screen editor to edit the template. The default template is:

  0 INDI
  1 NAME Fname /Surname/
  1 SEX MF
  1 BIRT
    2 DATE
    2 PLAC
    2 SOUR
  1 DEAT
    2 DATE
    2 PLAC
    2 SOUR

Edit the template to create the new person's record. Change the name to the person's name. Assign the person's sex by deleting either M or F. Fill out the birth and death events as best you can. If the person is alive, remove the death event. Remove any DATE and PLAC lines you do not have the information for.

The default template provides lines for one birth and one death event. You can expand the record with other events (even more birth or death events) and lines. Indentation makes it easier to read and edit the record, but isn't necessary. You may change the default edit template by defining the user option INDIREC (described later).

Here is how I might edit the template when creating a record about myself:

  0 INDI
  1 NAME Thomas Trask /Wetmore/ IV
  1 SEX M
  1 BIRT
    2 DATE 18 December 1949
    2 PLAC New London, New London, Connecticut
    2 SOUR Birth Certificate
  1 OCCU Software Engineer
  1 RESI
    2 DATE 1982 to 1995
    2 PLAC Newburyport, Essex, Massachusetts
    2 ADDR 2 Barton Street, Newburyport, MA 01950

... lots of other events and facts

When you edit a person record, don't add or modify INDI, FAMC or FAMS lines. LifeLines creates and maintains these lines through specific user commands.

When you finish editing and leave the editor, you automatically return to LifeLines. If you made an error (eg, didn't use proper level numbers or didn't follow the proper name convention), LifeLines displays an error message, and asks if you want to re-edit the record. If you don't, LifeLines doesn't add the person to the database.

When the record is in proper format, LifeLines asks if you are sure you want to add the person to the database. If you answer yes, the person is added; if you answer no, the person isn't. In both cases LifeLines returns to the main menu.

1.8. SCREEN EDITORS AND ENVIRONMENT VARIABLES

With LifeLines you maintain the database records using a screen editor. This is different than other genealogical programs where screens or forms are used to gather the data.The default screen editor for LifeLines is vi. (The MS-Windows version defaults instead to notepad.exe.) This can be overridden by the ED, EDITOR or LLEDITOR environment variables. For example, if you prefer the emacs screen editor, and if you use a bourne-compatible shell, you may add the line: ED=emacs to your login profile file, and LifeLines will use emacs for editing.

There are four other, LifeLines specific environment variables. They are LLDATABASES, LLARCHIVES, LLPROGRAMS and LLREPORTS. LLDATABASES and LLPROGRAMS are UNIX path list variables.

There is also a configuration file, and entries in it may be used in lieu of environment variables. It is ordinarily named .linesrc under UNIX, and lines.cfg under MS-Windows. A sample configuration file should have been included in the distribution.

See the section on System and User properties for more details.

LLDATABASES can be set to a list of directories that hold LifeLines databases. When you execute the LifeLines program, these directories will be searched in turn for the database mentioned on the command line. For example, LLDATABASES=.:/home/ttw4/LifeLines/Databases indicates that databases should be searched for in the current directory first, and if not found there, then searched for in: /home/ttw4/LifeLines/Databases

Each LifeLines database is implemented as a directory with specific contents. The LLDATABASES variable should be set to a list of directories that contain these database directories, not to a list of database directories themselves.

The environment variable LLPROGRAMS is used in the same way, but to specify the search path for LifeLines report generating and other programs (described later).

LLARCHIVES and LLREPORTS can each be set to specify a single directory. LLARCHIVES is used to select a directory where all database backup files will be stored, and LLREPORTS is used to select a directory where all generated reports and program outputs will be placed.

New databases without explicit paths will be created in the first directory listed in the LLDATABASES path. (This is a change; versions from 3.0.6 to 3.0.31 used a now obsolete variable LLNEWDBDIR).

You are not required to use these environment variables; when a variable is not defined, LifeLines uses the current directory as its default value. If you do use the variables, you can override their use by specifying files and directories as either absolute or relative paths.

You may use the configuration file in lieu of environment variables. This is especially oriented towards users on MS-Windows systems, on which environment variables are not as common a configuration technique.

LifeLines uses the curses library for terminal independent I/O. This requires you to specify your terminal type with the TERM environment variable. (This is not relevant in the MS-Windows version.)

1.9. BASICS OF BROWSING

You will use the browsing screens of LifeLines most of the time. When in these modes you can quickly search for or browse through the persons and families in the database. When you find a person or family you are interested in, you can then edit their records.

The browsing screens also allow you to add new persons and families to the database, add spouses to families, add children to families, swap the order of spouses and children, merge persons and merge families, and perform other operations. The browsing screens also lets you remove spouses from families and remove children from families.

There are six browsing screens. The person and family screens concentrate on a single person and family, respectively. The list screen allows you to browse through a list of persons. The two person browse screen shows two persons at once, and the two family browse screen shows two families at once. The auxiliary screen is used browsing any other type of records (e.g., events, sources, notes).

Each browsing screen has multiple view modes. The view mode affects how the information is displayed on the screen, but does not affect the menu choices available at the bottom of the screen. Menu commands are available on each screen to change amongst the view modes available for that screen.

The person screen has the most view modes. It has normal mode, which shows a summary of the vital records of the person. It (like all other screens) has GEDCOM mode, which shows the actual GEDCOM data of the record, and also expanded GEDCOM mode, which shows the actual GEDCOM data, but augments it with information on each line that contains a cross-reference (GEDCOM xref). It has two pedigree or tree modes, one showing an ancestral tree and one showing a descendant tree. The depth of the pedigree trees shown may be adjusted via menu commands.

The two person browse screen has the same modes as the person screen.

The two family browse screen and tandem family screen alike have normal mode (showing a summary of vitals), GEDCOM mode, and expanded GEDCOM mode.

The auxiliary screen has only GEDCOM mode and expanded GEDCOM mode. (The list screen has no view modes at present).

1.10. IDENTIFYING A PERSON OR LIST OF PERSONS TO BROWSE

To enter the browsing modes from the main menu strike b. LifeLines asks you to identify a person or list of persons to browse to:

Please identify person or persons to browse to.
Enter name, key, refn or list:

Enter either a name or partial name, or an internal key value, or a user-defined reference key (described later) or the name of a previously defined list of persons (described later), and strike return.

LifeLines allows wide flexibility in how to enter names. You may enter a name in upper or lower case or any combination. You may leave out all but the first given name, and, for given names, you may leave out any letters except the first. You may leave vowels out of the surname, and after four or five consonants have been typed, you may leave them out too. You must separate the given names from the surname by a slash, and if you enter given names after the surname (as in Chinese names), or any modifiers (such as Jr, Sr, IV, etc.), they must be separated from the surname by another slash. Here are a few of the ways I can enter my name:

You may browse to the list of all persons with the same surname by using the * character as the first initial. For example:

After you enter a name, LifeLines searches for all persons who match. There are three possibilities: no one matches; one person matches; or more than one person matches. In the first case LifeLines writes:

There is no one in the database with that name or key.

If one person matches, LifeLines enters the person browse mode displaying the matched person. If more than one person matches, LifeLines enters the list browsing mode with the list of matching persons.

You may also identify a person by entering his or her internal, cross-reference key value. The internal key values of all person records are an I followed by digits. When you enter a key value you may omit the I. If LifeLines finds a person with the key value you provide, LifeLines enters the person browsing mode displaying that person. You can also browse to a Family, Source, or Note by entering it's key, but you must include the letter identifing the key type, thus F11, S1, or N3 would browse to the family, source or note corresponding to the key if it exists.

The browse command b is also available from most browsing modes. The command works the same way from those modes as it does from the main menu.

1.11. ZIP IDENTIFYING A NEW PERSON

Some LifeLines operations need you to identify a person, not for the purpose of browsing, but for the purpose of completing an operation you have requested. For example, when you add a child to a family, LifeLines may ask you to identify the child. When this happens a panel pops up that asks you to identify a person. You respond by typing a name or key exactly as you would for the b command. If no one matches, LifeLines returns to the previous browsing mode. If the name matches persons in the database LifeLines displays something like:

Please choose from among these records.
  >Thomas Trask Wetmore, b. 1826, N.B. (42)
   Thomas Trask Wetmore IV, b. 1949, Conn. (1)
   Thomas Trask Wetmore III, b. 1925, Conn. (6)
   Thomas Trask Wetmore Jr, b. 1896, Conn. (11)
   Thomas Trask Wetmore Sr, b. 1866, N.S. (23)
   Thomas Trask Wetmore V, b. 1982, Mass. (5)
_______________________________________________
Commands: j Move down k Move up i Select q Quit

Use the j and k commands to move the selection cursor (>) to the correct person, and then use the i command to select that person. There may be more persons in the list than you can see at once. If this is so then you can use the j and k commands to scroll through the full list. If you don't find the proper person, use the q command and LifeLines asks whether you want to enter another name.

With version 3.0.15, lists may also be navigated with the up and down arrows, PageUp and PageDown keys, Home and End keys, and the Enter key. Shift-PageUp and Shift-PageDown move more than one page at a time in a given direction. The keyboard equivalents are j=UpArrow, k=DownArrow, u=PageUp, d=PageDown, ^=Home, $=End, U=Shift-PageUp, D=Shift-PageDown, i=Enter.

When LifeLines creates a list of names for you to select from, it tries to add extra information to the name; this helps determine which name to choose, and is important in databases where many persons have the same name. LifeLines also places the person's key value at the end of each menu line; this may be helpful in large databases.

Some browse screens provide the z command, which allows you to browse to a new person using the zip style of identification rather than the b style.

1.12. BROWSE DISPLAY BASICS

The screen display for each browsing screen is made up of panels. At the bottom of each display is a message panel used for one line messages. Each display contains one or two data panels showing information from the database. And each display has a panel with the operation menu available for that screen.

1.13. PERSON BROWSE SCREEN

After you identify a person to browse to, LifeLines enters the person browse screen. The top panel in the display gives basic information about the person (in the normal, or vitals, mode, which is the default). The middle panel provides a menu of commands. For example:

person: Thomas Trask WETMORE Sr (25)
  born: 13 March 1866, St. Mary's Bay, Digby, Nova Scotia
  died: 17 February 1947, New London, New London, Connecticut
  father: Daniel Lorenzo WETMORE, b. 1821, N.S., d. 1903, Conn. (48)
  mother: Mary Ann DOTY, b. 1824, N.S., d. 1897, Conn. (59)
  spouse: Margaret Ellen KANEEN, b. 1855, Eng., d. 1900, Conn. (26)
    child: Portia Louise WETMORE, b. 1892, Conn., d. 1921, Conn. (27)
    child: Thomas Trask WETMORE, b. 1896, Conn., d. 1970, Conn. (17)
  spouse: Arleen M KEENEY, m. 1914, Conn. (75)
_______________________________________________________________________
Please choose an operation:             (pg 1/3)
  e  Edit the person       g  Browse to family    p  Pedigree mode
  f  Browse to father      u  Browse to parents   n  Create new person
  m  Browse to mother      b  Browse to persons   a  Create new family
  s  Browse to spouse/s    h  Add as spouse       x  Swap two families
  c  Browse to children    i  Add as child        tt Enter tandem mode
  o  Browse to older sib   r  Remove as spouse    ?  Other menu choices
  y  Browse to younger sib d  Remove as child     q  Return to main menu
_______________________________________________________________________
LifeLines -- Person Browse Screen

The commands perform a wide variety of functions.

1.14. LIST BROWSE SCREEN

This browse screen handles lists of persons. The top panel shows information about one person in the list. The left panel shows a list of up to 12 persons. The person shown in the top panel is identified by the > character. The right panel is the menu of available commands.

person: Thomas Trask WETMORE Sr (25)
  born: 13 March 1866, St. Mary's Bay, Digby, Nova Scotia
  died: 17 February 1947, New London, New London, Connecticut
  father: Daniel Lorenzo WETMORE, b. 1821, N.S., d. 1903, Conn. (48)
  mother: Mary Ann DOTY, b. 1824, N.S., d. 1897, Conn. (59)
  spouse: Margaret Ellen KANEEN, b. 1855, Eng., d. 1900, Conn. (26)
_______________________________________________________________________
  Thomas Trask WETMORE (42)                Choose an operation:
  Thomas Trask WETMORE III (6)              j Move down list
  Thomas Trask WETMORE IV (1)               k Move up list
  Thomas Trask WETMORE (11)                 e Edit this person
 >Thomas Trask WETMORE Sr (23)              i Browse this person
  Thomas Trask WETMORE (5)                  m Mark this person
                                            r Remove from list
                                            t Enter tandem mode
                                            n Name this list
                                            b Browse new persons
                                            a Add to this list
                                            x Swap mark/current
                                            q Return to main menu
_______________________________________________________________________
LifeLines -- List Browse Screen

1.15. FAMILY BROWSE SCREEN

This browse screen displays information about a family. The top panel shows basic information about the family. The bottom panel shows the menu of available commands. If the database contains more than two parents for this family only the first two are displayed.

father: Thomas Trask WETMORE IV (1)
  born: 18 December 1949, New London, New London, Connecticut
  died:
mother: Luann Frances GRENDA (2)
  born: 10 July 1949, Pittsburgh, Allegheny, Pennsylvania
  died:
married: 1 August 1970, Governors Island, New York, New York
  child: Anna Vivian Wetmore, b. 1974, Alaska (3)
  child: Marie Margaret WETMORE, b. 1979, Conn. (4)
  child: Thomas Trask WETMORE V, b. 1982, Mass. (5)
_______________________________________________________________________
Please choose an operation:            (pg 1/4)
 e  Edit the family       %s  Add source           r  Remove spouse from
 f  Browse to father      %e  Add event            d  Remove child from
 m  Browse to mother      %o  Add other            x  Swap two children
 c  Browse to children    s  Add spouse to family  ?  Other menu choices
 n  Create new person     a  Add child to family   q  Return to main menu
_______________________________________________________________________
LifeLines -- Family Browse Screen (* toggles menu)

1.16. TANDEM PERSON BROWSE MODE

The tandem person browse screen displays information about two persons. Its main use it to support the person merging operation. The top two panels show two persons in the format used in the person and list screen displays. The bottom panel gives the menu of available commands. For example:

  person: Thomas Trask WETMORE Sr (25)
  born: 13 March 1866, St. Mary's Bay, Digby, Nova Scotia
  died: 17 February 1947, New London, New London, Connecticut
  father: Daniel Lorenzo WETMORE, b. 1821, N.S., d. 1903, Conn. (48)
  mother: Mary Ann DOTY, b. 1824, N.S., d. 1897, Conn. (59)
  spouse: Margaret Ellen KANEEN, b. 1855, Eng., d. 1900, Conn. (26)
______________________________________________________________________
person: Thomas Trask WETMORE IV (1)
  born: 18 December 1949, New London, New London, Connecticut
  died:
  father: Thomas Trask WETMORE III, b. 1925, Conn. (6)
  mother: Joan Marie HANCOCK, b. 1928, Conn. (7)
  spouse: Luann Frances GRENDA, m. 1970, N.Y. (2)
______________________________________________________________________
Please choose an operation:
 e Edit top person    s Browse top spouse/s   a Add family
 t Browse to top      c Browse top children   j Merge bottom to top
 f Browse top father  b Browse to persons     x Switch top/bottom
 m Browse top mother  d Copy top to bottom    q Return to main menu
______________________________________________________________________
LifeLines - Two Person Browse Screen

1.17. TANDEM FAMILY BROWSE MODE

The tandem family browse screen displays information about two families. Its main use it to support the family merging operation.The top two panels provide information about the two families you are browsing, and the bottom panel holds the menu of available commands. For example:

father: Thomas Trask WETMORE IV (1)
  born: 18 December 1949, New London, New London, Connecticut
mother: Luann Frances GRENDA (2)
  born: 10 July 1949, Pittsburgh, Allegheny, Pennsylvania
married: 1 August 1970, Governors Island, New York, New York
  child: Anna Vivian WETMORE, b. 1974, Alaska (3)
__________________________________________________________________
father: Thomas Trask WETMORE III (6)
  born: 26 October 1925, New London, New London, Connecticut
wife: Joan Marie Hancock (7)
  born: 6 June 1928, New London, New London, Connecticut
married: 5 February 1949, New London, New London, Connecticut
  child: Thomas Trask WETMORE IV, b. 1949, Conn. (1)
__________________________________________________________________
Please choose an operation:            (pg 1/3)
 e  Edit top person       m  Browse to mothers     )b Scroll bottom down
 t  Browse to top         (t Scroll top up         (( Scroll both up
 b  Browse to bottom      )t Scroll top down       ?  Other menu choices
 f  Browse to fathers     (b Scroll bottom up      q  Return to main menu
__________________________________________________________________
LifeLines -- Two Family Browse Screen (* toggles menu)

1.18. PEDIGREE BROWSE MODE

The pedigree browse screen displays a four-generation pedigree for the current person. The top panel holds the pedigree, and the bottom panel holds the menu of available commands. For example:

                  John WETMORE [1755-1848] (32)
            Daniel Van Cott WETMORE [1791-1881] (41)
                  Anna VAN COTT [1757-1802] (33)
      Daniel Lorenzo WETMORE [1821-1903] (48)
                  Thomas TRASK [-1836] (81)
            Hannah TRASK [1797-1829] (46)
                  Susannah PORTER [1754-] (82)
Thomas Trask WETMORE Sr [1866-1947] (25)
                  Samuel DOTY [1759-] (501)
            Samuel DOTY [1787-] (74)
                  Hephzibah PORTER [1764-1853] (502)
      Mary Ann DOTY [1827-1897] (59)
                  Nathan SAVERY [1748-1826] (510)
            Lydia SAVERY [1806-] (75)
                  Deidamia SABEAN [1765-1845] (511)
__________________________________________________________________
Please choose an operation:
 e Edit the person   m Browse to mother    g Browse to family
 i Browse to person  s Browse to spouse/s  b Browse to persons
 f Browse to father  c Browse to children  q Return to main menu
__________________________________________________________________
LifeLines - Pedigree Browse Mode

1.19. SEARCH MENU

If you choose Search database from the main menu, LifeLines displays the search menu:

How would you like to find a record?
  v Review visit history (12 records)
  c Review change history (3 records)
  f Full database scan
  q Return to previous menu

Selecting a non-empty visit history or change history will bring up a list of individuals (or families) that are in the history, allowing you to browse to that individual or family.

If you choose Full database scan off the search menu, LifeLines displays the fullscan menu.

What scan type?
  f  Full name scan
  n  Name fragment (whitespace-delimited) scan
  r  Refn scan
  q  Return to previous menu

1 NAME John /Smith/

*smith

*smith/

smith
smi*
joh*
*hn

1.20. ADD OPERATION

If you choose the add operation from the main menu, LifeLines displays the add menu:

What do you want to add?
  p Person - add new person to the database
  f Family - create family record from one or two spouses
  c Child - add a child to an existing family
  s Spouse - add a spouse to an existing family
  q Quit - return to the previous menu

These operations work in a straightforward way. LifeLines asks you the necessary questions, and lets you cancel at any time. The operations provided by this menu are also available from the browsing modes, and are often easier to perform there.

1.21. DELETE OPERATION

If you choose the delete operation at the main menu, LifeLines displays the delete menu:

What do you want to delete?
  c Child - remove a child from his/her family
  s Spouse - remove a spouse from a family
  p Person - remove a person completely
  q Quit - return to the previous menu

These operations also work in a straightforward way. LifeLines asks you the necessary questions and lets you cancel at any time.

You may also remove a child from his/her family, or remove a spouse/parent from his/her family, from the person browsing mode. In both cases, only a relationship is removed, not a person. On the other hand, the delete menu must be used if you want to completely remove a person from the database; this cannot be done from the browsing mode.

There is no special operation for removing a family record. LifeLines silently removes any family record that has no parent or child associated with it.

1.22. CODESET CONVERSION

(This section was previously entitled CHARACTER TRANSLATION.)

The intention is that you need only specify the internal codeset for each database you create (and this step may be automated via the NewDbProps property), and all else works pretty well without tuning. That is, lifelines tries to guess the correct codeset for your environment (including guessing the console and windows codesets when operating under MS-Windows, which it should do fairly well).

However, you may encounter situations where you wish to alter the codeset behavior, or the codeset conversion is not operating correctly (in which case we hope you will report the problem to the mailing list and/or sourceforge bugs list).

There are two ways to amend codeset conversion. The first method is by changing configuration variables. For example, if you wish to generate an HTML report of all your data, which includes names in Russian (in Cyrillic letters), for your cousin, and you know that your cousin's computer has no font for Cyrillic letters, you might wish to temporarily adjust your report output codeset so that you will get interpolated ASCII letters for the Russian letters. You could do this by temporarily altering the configuration variable ReportCodesetOut to be "ASCII" (actually, if any of your data has characters in it that are reserved in HTML, such as the less than sign, or the ampersand, you would probaby want "ASCII//HTML").

The second way to change codeset conversion, and the only way in lifelines 3.0.6, is to edit the embedded character translation tables, in which you actually specify the letters you want converted, letter by letter, and how you want them converted. This method, unlike the first, even works in databases with no specified internal codeset.

If you choose the modify character translation tables operation from the main menu, LifeLines displays the character translation menu:

Which character mapping do you want to edit?
   e Editor to Internal mapping
   m Internal to Editor mapping
   i GEDCOM to Internal mapping
   x Internal to GEDCOM mapping
   d Internal to Display mapping
   r Internal to Report mapping
   q Return to main menu

LifeLines can do codeset conversion in changing text from one form to another, and lifelines supports five different forms.

When converting text from one form to another LifeLines normally uses iconv conversion, and codesets specified in configuration variables. This may be augmented by codeset translation or extension using the text conversion (*.tt) files in the tt subdirectory. To use the tables in the tt subdirectory, you need to set the property "TTPATH" in your LifeLines configuration file to the path of the tt directory. There are two types of files in this directory.

Files of the form <codeset>_<codeset1>.tt convert from one codeset to another. For example, CP1250_UTF-8.tt can be used to convert characters in codeset CP1250 to their representations in UTF-8.

Files of the form <codeset>__<subcodeset>.tt apply a conversion within the codeset, for example, UTF-8__html.tt is a sub-conversion that converts UTF-8 characters that have special escape codes within html to those special codes. For example, specifing the report codeset to be UTF-8//html will apply the html sub-conversion to all the data being written. Probably not what you really wanted. See the report language function convertcode() in the reportmanual for details.

If your system lacks iconv, or you need more specialized conversion than provided with iconv, you may either write a text conversion file (a tt file), or you may edit one of the in-database translation tables.

The in-database translation tables convert between forms (as listed above). Every translation table converts either to the internal form, or from the internal form. That is, the internal form is used as an intermediate step in all operations. There are six supported translation tables. The following table shows the six tables and describes when they are applied:

After you select a translation table you are placed in the editor to edit the table. Translation tables are made up of lines that look like:

pattern pattern

There are five escape mechanisms used in patterns:

It is possible, and desirable, to provide a short name for the translation table, using the "##!name: " command. An example would be

##!name: UTF-8 to latex

Naming the translation table is desirable because these names are displayed, at least in part and if they fit, on the translation table menu.

It is possible to format the file using a character other than tab as the separator between source and destination code. To do requires using the "##!sep" command. Those exact six characters must begin the line, and then the next character is the new separator for all following lines. For clarity, this should only occur once, and near the top of the file before any actual translation lines, and a fairly clear separator should be used (e.g., the equal sign "=").

Any line which is blank, or which begins with two hash marks (##), is ignored. Therefore, comments begin with two hash marks.

For advanced users, it is possible to mix different types of conversion, for example iconv conversion and also translation table conversion, in the same form step. For example, it is possible to convert internal database text (internal form) first via the "internal to GEDCOM" in-database translation table, and then via the iconv conversion from configured internal codeset to configured GEDCOM codeset. In-database translation tables are always applied in the internal codeset, so when converting to the internal form, they are applied after iconv and/or tt conversions, and when converting from internal form, they are applied first.

An example of adding a mixin in-database translation table might be to escape certain characters which are control characters to an output computer language, e.g., latex. One could create an "Internal to Report" mapping in UTF-8 (if the database is internally UTF-8) to escape any characters that may occur in place names or textual descriptions and inadvertently cause grief in latex processing.

However, in this case, one could also write a tt file to achieve the same results, and be shared across databases, by naming it, eg, UTF-8__latex.tt. The double underscore ("__") signifies that this is a conversion to be applied to text which is in UTF-8, and to trigger lifelinesn to use this, one must specify a report codeset such as "UTF-8//latex" (if UTF-8 output is desired, but with the latex conversion first applied), or "ISO-8859-1//latex" (if ISO-8859-1 output is desired, but with the latex conversion first applied).

1.23. MISCELLANEOUS UTILITIES

If you choose the miscellaneous utilities operation, LifeLines displays the utilities menu:

What utility do you want to perform?
  s Save the database in a GEDCOM file
  r Read in data from a GEDCOM file
  R  Pick a GEDCOM file and read in
  k Find a person's key value
  i Identify a person from key value
  d Show database statistics
  m Show memory statistics
  e Edit the place abbreviation file
  o Edit the user options file
  c  Character set options
  q Return to the main menu

For example if you would like to replace the default person record template with the following:

  0 INDI
  1 NAME //
  1 SEX

1.24. IMPORT ERRORS

Errors generated during a GEDCOM import are logged to a file, by default named errs.log.

A number of errors are related to having an incorrect XREF value. An XREF is the internal name used to Identify a family, individual, note, source or other record. An XREF is bracked by two @ signs. As an example

  0 @F6@ FAM
  1 HUSB @I25@
  1 WIFE @I26@
  1 CHIL @I17@

Here F6 is the internal name of this family. The family refers to other individuals by specifing their XREF values. Also I25, I26 and I17 are XREF values of individuals.

XREF values used within LifeLines are totally under the control of LifeLines. The values that are used are always of the form, a single letter, followed by a number. However, when importing a gedcom LifeLines should accept almost anything as an XREF, converting it to what is needed for internal use. For the curious, the letters that LifeLines uses are I for Individual, F for Family, S for Source, E for Events, and X for other records.

1.25. HANDLING SOURCE, EVENT AND USER-DEFINED RECORDS

LifeLines supports source, event and other, user-defined record types. You can access these features in two ways: either through the x operation from the main menu, or via commands in the individual and family browse screens. The first approach might be most convenient when you are solely working with these record types. The second makes it easier to work with source, event and user-defined records in parallel with your person and family records; this can be useful for instance when you want to create references from your person and family record to your source, event and user defined records as you create them, and to view and edit records that you have referenced from within a person or family record.

Using the first of these two possibilities LifeLines displays the following menu:

What activity do you want to perform?

  s  Browse source records
  e  Browse event records
  x  Browse other records
  1  Add a source record to the database
  2  Edit source record from the database
  3  Add an event record to the database
  4  Edit event record from the database
  5  Add an other record to the database
  6  Edit other record from the database
  q  Return to main menu

  %s  Add source
  %e  Add event
  %o  Add other

  $s  List sources
  $n  List notes
  $$  List references

The handling of source, event and user-defined records in LifeLines is still in development. For example, sources cannot yet be searched by REFN or be deleted.

1.26. FAMILY STRUCTURE AND MERGING PERSONS AND FAMILIES

LifeLines 3.0.2 has relaxed most of restrictions on family structure that were imposed by earlier versions. For example, a family record may have more than one parent/spouse of the same sex; a person may be a child in more than family. This is a controversial issue. Some users insist that family relationships should imply biological relatedness, and that all other relationships should be handled by different means. Others insist that non-traditional families (any number of parents/spouses of any sex) should be allowed, and that children can be members of more than one family (eg, natural family and adoptive family). LifeLines no longer takes a position on this matter; you are free to set up families any way you like; the operations that add spouses and children to families no longer check for non-traditional arrangements. It is possible that a future release will include a user option to either disallow or to ask for confirmation about non-traditional relationships.

LifeLines provides features for merging persons together and for merging families together. The person merging feature is accessed from the tandem person browse mode, and the family merging feature is accessed from the tandem family browse mode. You browse to the two persons or families you want to merge and then use the j command. Merging is necessary when you discover that two or more person records, or two or more family records, represent the same person or family, respectively.

Versions of LifeLines prior to 3.0.2 required that persons and families meet certain criteria before they could be merged. The criteria ensured that the merged persons and families would still meet traditional family structuring rules. With the relaxation of the structuring rules, restrictions on merging have also been removed. It is now possible to create non-traditional relationships by merging traditional persons and/or families. For example, if you merge two persons that happen to be children in two different families, the merged person will be a child in both families. If you want to maintain only traditional relationships in your database you may have to makes further to changes to relationships after you complete a merge operation.

1.27. LINKING RECORDS TOGETHER AND USING THE REFN FEATURE

Records in a LifeLines database may refer to other records via cross-reference links. The lineage-linked references are maintained directly by LifeLines through operations found in the browsing mode menus. These references are the links from a person to families (1 FAMC and 1 FAMS), and the links from a family to persons (1 HUSB, 1 WIFE and 1 CHIL). Because LifeLines maintains these links you are not allowed to change these lines when you are editing records. There are a couple of seeming exceptions to this rule. For example, you may change the order of 1 CHIL lines in a family record in order to change the order of children in a family, and you may change the order of 1 FAMS lines in a person record to change the order of families the person was a spouse or parent in. These operations are allowed because they don't affect which person records refer to which family records and vice versa.

Besides the lineage-links that are maintained by LifeLines, you may place your own links in records. Probably the most common example of this is referring events within a person record to the record of the information source for the event. For example:

0 @I23@ INDI
  1 NAME Thomas/Whitmore/
  1 BIRT
    2 DATE about 1615
    2 PLAC England
    2 SOUR @S3@
...
0 @S3@ SOUR
  1 REFN cat
  1 TITL New England Marriages Prior to 1700
  1 AUTH Clarence Almon Torrey
...

The 2 SOUR @S3@ line in the person record refers to the source record. LifeLines allows any specific structure within a record (in this case a birth event) to refer to another record. It is not possible to refer to a specific location within another record, though this may be supported eventually.

This example implies that when linking one record to another you must know the key of the target record (S3 in the example). This is not desirable because internal record keys may change when the records are exported from one database or imported to another.

Because internal key values are not permanent, LifeLines allows you to assign a permanent user-defined key to any record in the database using the 1 REFN line. The value of this line is a string that you choose as your permanent key value for the record. When adding a link to a record that has a user REFN key value, you may use that value instead of the internal key value. For example, when adding the person in the previous example you could edit the new record as follows:

0 INDI
  1 NAME Thomas/Whitmore/
  1 BIRT
    2 DATE about 1615
    2 PLAC England
    2 SOUR <cat>

Instead of using the actual key value of the source, S3, the REFN value cat was used. The REFN value must be enclosed by angle brackets when used this way. LifeLines automatically replaces the REFN link with the proper internal key value when the record is stored in the database.

The REFN value may also be used when searching for person, source, event and user-defined records. You should not add more than one REFN line to a record, and every REFN value should be unique.

1.28. System and User Properties

There are a number of properties that can be specified to customize the behavior of LifeLines. These properties can be specified in LifeLines configuration files, in each LifeLines database or in some cases by environment variables.

System Properties are properties that have a predefined meaning to lifelines, such as LLEDITOR (see its meaning below). User Properties typically have no predefined meanings as they are simply a string that a report looks up in the property tables. It can be anything a user desires. To simplify report writing a number of User Properties are predefined with specific meanings. These User Property Names begin with 'user.' and are listed below. For example, many reports have abstracted the concept of the user's name to the property user.fullname. By defining this property in your llines startup file, it allows a report to reference your name as the source of the data being printed without having it hard-coded in the report.

When LifeLines begins execution, it reads any specified configuration files and extracts Properties from the files read. It is possible for multiple configuration files to be read. Properties defined in these files will be stored in the global property table. If multiple definitions of the same property are seen, the latest definition overrides prior definitions. Configuration files are read as follows:

When LifeLines searches for a property it looks for it as follows:

Properties are named group.subgroup.property or group.property, or even just property. The following keys are available at the moment:

Codeset Information:

For the following parameters related to codeset, the values are a String denoting code set in use in data. Special handling is provided for UTF-8, which may be entered as "UTF-8", "utf-8", or "65001". (The official, and preferred, name is UTF-8.