Info file uucp.info, produced by Makeinfo, -*- Text -*- from input file uucp.texi. This file documents Taylor UUCP, beta version 1.03. Copyright (C) 1992 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the section entitled "Copying" are included exactly as in the original, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that the section entitled "Copying" may be included in a translation approved by the author instead of in the original English.  File: uucp.info, Node: Top, Next: Copying, Prev: (dir), Up: (dir) Taylor UUCP 1.03 **************** This is the documentation for the Taylor UUCP package, beta version 1.03. The programs were written by Ian Lance Taylor. The author can be reached at `', or, equivalently, `', or `c/o Infinity Development, P.O. Box 520, Waltham MA, 02254'. There is a mailing list for discussion of the package. To join the list, send a message to `'. Make sure you include the address you want to receive messages at; do not rely on the `From:' header. To send a message to the list, send it to `'. * Menu: * Copying:: Taylor UUCP copying conditions * Introduction:: Introduction to Taylor UUCP * Overall Installation:: Taylor UUCP installation * Configuration files:: Taylor UUCP configuration files * Acknowledgements:: Acknowledgements * Index (concepts):: Concept index * Index (configuration file):: Index to new configuration files -- The Detailed Node Listing -- Taylor UUCP Overall Installation * Configuration:: Configuring Taylor UUCP * Compilation:: Compiling Taylor UUCP * Testing:: Testing Taylor UUCP * Installation:: Installing Taylor UUCP * Usage:: Using Taylor UUCP * TCP:: TCP together with Taylor UUCP Taylor UUCP configuration files * config file:: The main configuration file * sys file:: The system configuration file * port file:: The port configuration files * dial file:: The dialer configuration files * Example:: Brief example of configuration files  File: uucp.info, Node: Copying, Next: Introduction, Prev: Top, Up: Top Taylor UUCP Copying Conditions ****************************** This package is covered by the Gnu Public License. See the file `COPYING' for details. If you would like to do something with this package that you feel is reasonable but you feel is prohibited by the license, contact me to see if we can work it out. Here is some propaganda from the Free Software Foundation. If you find this stuff offensive or annoying, remember that you probably did not spend any money to get this code. I did not write this code to make life easier for developers of UUCP packages, I wrote it to help end users, and I believe that these are the most appropriate conditions for distribution. All the programs, scripts and documents relating to Taylor UUCP are "free"; this means that everyone is free to use them and free to redistribute them on a free basis. The Taylor UUCP-related programs are not in the public domain; they are copyrighted and there are restrictions on their distribution, but these restrictions are designed to permit everything that a good cooperating citizen would want to do. What is not allowed is to try to prevent others from further sharing any version of these programs that they might get from you. Specifically, we want to make sure that you have the right to give away copies of the programs that relate to Taylor UUCP, that you receive source code or else can get it if you want it, that you can change these programs or use pieces of them in new free programs, and that you know you can do these things. To make sure that everyone has such rights, we have to forbid you to deprive anyone else of these rights. For example, if you distribute copies of the Taylor UUCP related programs, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must tell them their rights. Also, for our own protection, we must make certain that everyone finds out that there is no warranty for the programs that relate to Taylor UUCP. If these programs are modified by someone else and passed on, we want their recipients to know that what they have is not what we distributed, so that any problems introduced by others will not reflect on our reputation. The precise conditions of the licenses for the programs currently being distributed that relate to Taylor UUCP are found in the General Public Licenses that accompany them.  File: uucp.info, Node: Introduction, Next: Overall Installation, Prev: Copying, Up: Top Introduction to Taylor UUCP *************************** General introductions to UUCP are available, and perhaps one day I will write one. In the meantime, here is a very brief one that concentrates on the programs provided by Taylor UUCP. Taylor UUCP is a complete UUCP package. It is covered by the GNU Public License, which means that the source code is always available. It is composed of several programs, the names of which were established by earlier UUCP packages. `uucp' The `uucp' program is used to copy file between systems. It is similar to the standard Unix `cp' program, except that you can refer to a file on a remote system by using `system!' before the file name. For example, to copy the file `notes.txt' to the system `airs', you would say `uucp notes.txt airs!~/notes.txt'. In this example `~' is used to name the UUCP public directory on `airs'. `uux' The `uux' program is used to request a program to be executed on a remote system. This is how mail and news are transferred over UUCP. As with `uucp', programs and files on remote systems may be named by using `system!'. For example, to run the `rnews' program on `airs' passing it standard input, you would say `uux - airs!rnews'. The `-' means to read standard input and set things up so that when `rnews' runs on `airs' it will receive the same standard input. Neither `uucp' nor `uux' actually do any work immediately. Instead they queue up requests for later processing. They then normally start a daemon process which processes the requests and calls up the appropriate systems. The daemon will usually also be started regularly to check if there is any work to be done and to do it. The advantage of this system is that it all happens automatically. You don't have to sit around waiting for the files to be transferred. The disadvantage is that if anything goes wrong it might be a while before anybody notices. `uustat' The `uustat' program does several things. It can be used to report the status of your jobs, and by default it will simply list all the jobs you have queued with `uucp' or `uux' that have not yet been processed. You can use `uustat' to remove any of your jobs from the queue. You can also it use it to show the status of the UUCP system in various ways, such as showing the connection status of all systems your system knows about. `uuname' The `uuname' program by default lists all the remote systems your system knows about. You can also use it to get the name of your local system. It is mostly useful for shell scripts. `uulog' The `uulog' program can be used to display entries in the UUCP log file. It can select the entries for a particular system or a particular user. You can use it to see what has happened to your queued jobs in the past. These five programs, `uucp', `uux', `uustat', `uuname', `uulog' are the user programs provided by Taylor UUCP. The first two add requests to the work queue, the third examines the work queue, the fourth examines the configuration files, and the last examines the log files. The real work is actually done by two daemon processes, which are normally run automatically rather than by a user. `uucico' The `uucico' daemon is the program which actually calls the remote system and transfers files and requests. `uucico' is normally started automatically by `uucp' and `uux' and most systems will also run it periodically to make sure that all requests are handled. `uucico' checks the queue to see what work needs to be done, and then calls the appropriate the system. If the call fails, perhaps because the phone line is busy, `uucico' leaves the requests in the queue and goes on to the next system to call. It is also possible to force `uucico' to call a remote system even if there is no work to be done for it, so that it can pick up any work that may be queued up remotely. `uuxqt' The `uuxqt' daemon processes execution requests made by the `uux' program on remote systems (it also processes requests made on the local system which require files from a remote system). It is normally started by `uucico'. Suppose you, on the system `bantam', want to copy a file to the system `airs'. You would run the `uucp' command locally, saying something like `uucp notes.txt airs!~/notes.txt'. This would queue up a request on `bantam' to call `airs' and start the `uucico' daemon. `uucico' would see that there was a request for `airs' and attempt to call it. When the call succeeded, another copy of `uucico' would be started on `airs'. The two copies of `uucico' would tell each other what they had to do, and the file would be transferred from `bantam' to `airs'. When the file transfer was complete the `uucico' on `airs' would move it into the UUCP public directory. UUCP is often used to transfer mail. This is normally done automatically by mailer programs. When `bantam' has a mail message to send to `ian' at `airs', it executes `uux - airs!rmail ian' and writes the mail message to the `uux' process as standard input. The `uux' program, running on `bantam' will read the standard input and store it and the `rmail' request on the work queue for `airs'. `uux' will then start the `uucico' daemon. The `uucico' daemon will call up `airs', just as in the `uucp' example, and transfer the work request and the mail message itself. The `uucico' daemon on `airs' will put the files on a local work queue. When the communication session is over, the `uucico' daemon on `airs' will start the `uuxqt' daemon. `uuxqt' will see the request to run, and will run `rmail ian' with the mail message as standard input. The `rmail' program, which is not part of the UUCP package, is then responsible for either putting the message in the right mailbox on `airs' or forwarding the message on to another system. Taylor UUCP comes with two other programs that are useful when installing and configuring UUCP. `uuchk' The `uuchk' program reads the UUCP configuration files and displays a rather lengthy description of what it finds. This is very useful when configuring UUCP to make certain that the UUCP package will do what you expect it to do. `tstuu' The `tstuu' program is a test harness for the UUCP package, which will help ensure that it has been configured and compiled correctly. It does not test everything, however, and it only runs on Unix systems which support Berkeley style pseudo-terminals. It can be useful when initially installing Taylor UUCP.  File: uucp.info, Node: Overall Installation, Next: Configuration files, Prev: Introduction, Up: Top Taylor UUCP Overall Installation ******************************** These are the installation instructions for the Taylor UUCP package. * Menu: * Configuration:: Configuring Taylor UUCP * Compilation:: Compiling Taylor UUCP * Testing:: Testing Taylor UUCP * Installation:: Installing Taylor UUCP * Usage:: Using Taylor UUCP * TCP:: TCP together with Taylor UUCP  File: uucp.info, Node: Configuration, Next: Compilation, Prev: Overall Installation, Up: Overall Installation Configuring Taylor UUCP ======================= You will have to decide what types of configuration files you want to use. This package supports a new sort of configuration file; *Note Configuration files::. It also supports V2 configuration files (`L.sys', `L-devices', etc.) and BNU configuration files (`Systems', `Devices', etc.). No documentation is provided for V2 or BNU configuration files. All types of configuration files can be used at once, if you are so inclined. Currently using just V2 configuration files is not really possible, because there is no way to specify a dialer (there are no built in dialers, and the program does not know how to read `acucap' or `modemcap'); however, V2 configuration files can be used with a new style dialer file (*note dial file::.), or with a BNU `Dialers' file. Use of BNU configuration file has one known bug. A blank line in the middle of an entry in the `Permissions' file will not be ignored as it should be. If you are installing a new system, or you want to use the new form of configuration files, you must write the configuration files. You must also decide what sort of spool directory you want to use. If you will only be using these programs, I recommend `SPOOLDIR_TAYLOR'; otherwise select the spool directory corresponding to your existing UUCP package. The details of the spool directory choices are described at somewhat tedious length in `sys3.unx'.  File: uucp.info, Node: Compilation, Next: Testing, Prev: Configuration, Up: Overall Installation Compiling Taylor UUCP ===================== 1. Take a look at the top of `Makefile.in' and set the appropriate values for your system. These control where the program is installed and which user on the system owns them (normally they will be owned by a special user `uucp' rather than a real person; they should probably not be owned by `root'). 2. Run the shell script `configure'. This script was generated using David MacKenzie's `autoconf' program. It takes a while to run. It will generate a file `conf.h', and copy `Makefile.in' to `Makefile' with substitions. You can pass certain arguments to `configure' in the environment. Useful arguments are `LIBS', `CC', and `INSTALL'. For example, if you wanted to include the `posix' library, then (using `sh' or `bash') you could enter `LIBS=-lposix ./configure'. On some systems you will want to use `LIBS=-lmalloc'. On some you will want `LIBS=-lsocket'. On Xenix derived systems do not use `LIBS=-lx' because this will bring in the wrong versions of certain routines; if you want to use `-lx' you must specify `LIBS=-lc -lx'. I know this information is a bit sketchy; on most systems you will not need to give a value for `LIBS' at all. If `configure' fails for some reason, or if you have a very wierd system, you may have to configure the package by hand. To do this, copy the file `conf.h-dist' to `conf.h' and edit it for your system. Then copy `Makefile.in' to `Makefile', find the words within `@' characters, and set them correctly for your system. 3. You should verify that `configure' worked correctly by checking the files `conf.h' and `Makefile'. There are two known problems on SCO 3.2.2 that `configure' will not figure out. The default version of `memmove' is buggy, so unless you have patched it you should set `HAVE_MEMMOVE' to 0. The `ftime' function will sometimes go backward in time by almost a second; this will not cause any real harm, but it will garble your transfer time statistics so you may want to set `HAVE_FTIME' to 0. If you find any problems in `conf.h' and `Makefile' please tell me about them so that I can fix them or at least add more warnings here. 4. This package uses the alloca function. The `configure' script will try to figure out how to make it work on your system. If alloca cannot be found, a simplistic substitute from `alloca.c' will be used. If you provide your own `alloca.o' file, it will be used instead; you might, for example, use the one from the GNU emacs distribution. If none of this makes any sense to you, don't worry; everything will probably work fine. 5. Edit `policy.h' for your local system. The comments should explain the various choices. The default values are intended to be reasonable, so you may not have to make any changes. 6. Type `make' to compile everything. You may get warnings about implicit function declarations; ignore these (if you think they can be eliminated, and you really know what you are talking about, you may tell me about them). You may also get warnings about `getopt.c' (this is from the GNU library and I do not want to change it) and about a variable not protected from `setjmp' in `sys2.c' (the data flow ensures that this can never be a problem). The `tstuu.c' file is not particularly portable; if you can't figure out how to compile it you can safely ignore it, as it is only used for testing. If you have any other problems there is probably a bug in the `configure' script. 7. Please report any problems you have. That is the only way they will get fixed for other people. Supply a patch if you can, or just ask for help.  File: uucp.info, Node: Testing, Next: Installation, Prev: Compilation, Up: Overall Installation Testing Taylor UUCP =================== This package is in use at many sites, and has been running at `airs.com' for several months. However, it will doubtless fail in some situations. Do not rely on this code until you have proven to yourself that it will work. You can use the `uuchk' program to test your configuration files. It will read them and print out a verbose description. This is particularly important if you are using V2 or BNU configuration files, because there may be bugs in how they are read. This program should not be made suid, because it will display passwords if it can read them. If your system supports BSD style pseudo-terminals, and you compiled the code to support the new style of configuration files, you should be able to use the `tstuu' program to test the `uucico' daemon. Just type `tstuu' with no arguments while logged in to the compilation directory (since it runs `./uucp', `./uux' and `./uucico') to run a lengthy series of tests (it takes over ten minutes on a slow VAX). You will need a fair amount of space available in `/usr/tmp'. You will probably want to put it in the background. Do not use `^Z', because the program traps on `SIGCHLD' and winds up dying. It will create a directory `/usr/tmp/tstuu' and fill it with configuration files, and create spool directories `/usr/tmp/tstuu/spool1' and `/usr/tmp/tstuu/spool2'. The program will finish with an execute file `X.SOMETHING' and a data file `D.SOMETHING' in `/usr/tmp/tstuu/spool1' (or, more likely, in subdirectories, depending on the choice of `SPOOLDIR' in `sysdep.h'). The log files `/usr/tmp/tstuu/Log1' and `/usr/tmp/tstuu/Log2' (or, if you have selected `HAVE_BNU_LOGGING', `/usr/tmp/tstuu/Log1/uucico/test2' and `/usr/tmp/tstuu/Log2/uucico/test1') should look fairly normal. You can test `uuxqt' by typing `./uuxqt -I /usr/tmp/tstuu/Config1'. This should leave a command file `C.SOMETHING' and a data file `D.SOMETHING' in `/usr/tmp/tstuu/spool1' or in subdirectories. Again, there should be no errors in the log file. Assuming you compiled the code with debugging enabled, the `-x' switch can be used to set debugging modes; see the `debug' command for details (*note config file::.). Use `-x all' to turn on all debugging and generate far more output than you will ever want to see. The `uucico' daemons will put debugging output in `/usr/tmp/tstuu/Debug1' and `/usr/tmp/tstuu/Debug2'. At this point you're pretty much on your own. On some systems you can also use `tstuu' to test my `uucico' against the system `uucico', by using the `-u' switch. For this to work, change the definitions of `ZUUCICO_CMD' and `UUCICO_EXECL' at the top of `tstuu.c' to something appropriate for your system. The definitions in `tstuu.c' are what I used for Ultrix 4.0, in which `/usr/lib/uucp/uucico' is particularly obstinate about being run as a child; I was only able to run it by creating a login name with no password whose shell was `/usr/lib/uucp/uucico'. Calling login in this way will leave fake entries in `wtmp' and `utmp'; if you compile `tstout.c' (in the `contrib' directory) as an suid `root' program, `tstuu' will run it to clear those entries out. On most systems, such hackery should not be necessary, although on SCO I had to su to `root' (`uucp' might also have worked) before I could run `/usr/lib/uucp/uucico'. You can test `uucp' and `uux' (give them the `-r' switch to keep them from starting `uucico') to make sure they create the right sorts of files. Unfortunately if you don't know what the right sorts of files are I'm not going to tell you here. If `tstuu' passes, or you can't run it for some reason or other, move on to testing with some other system. Set up the configuration files (*note Configuration files::.), or use an existing configuration. Tell `uucico' to dial out to the system by using the `-s' system switch (e.g. `uucico -s uunet'). The log file should tell you what happens. If you compiled the code with debugging enabled, you can use debugging mode to get a great deal of information about what sort of data is flowing back and forth; the various possibilities are described under the `debug' command (*note sys file::.). When initially setting up a connection `-x chat' is probably the most useful (e.g. `uucico -s uunet -x chat'); you may also want to use `-x handshake,incoming,outgoing'. You can use `-x' multiple times on one command line, or you can give it comma separated arguments as in the last example. Use `-x all' to turn on all possible debugging information. The debugging information is written to a file, normally `/usr/spool/uucp/Debug' although the default can be changed in `policy.h' and the configuration file can override the name with the `debugfile' command. The debugging file may contain passwords and some file contents as they are transmitted over the line, so the debugging file is only readable by the `uucp' user. You can use the `-f' switch to force `uucico' to call out even if the last call failed recently; using `-S' when naming a system has the same effect. Otherwise the status file (in the `.Status' subdirectory of the main spool directory, normally `/usr/spool/uucp') will prevent too many attempts from occurring in rapid succession. Again, let me know about any problems you have and how you got around them.  File: uucp.info, Node: Installation, Next: Usage, Prev: Testing, Up: Overall Installation Installing Taylor UUCP ====================== You can install by suing to `root' and typing `make install'. Or you can look at what make install does and do it by hand. It tries to preserve your old programs, if any. You can retrieve them by typing `make uninstall'.  File: uucp.info, Node: Usage, Next: TCP, Prev: Installation, Up: Overall Installation Using Taylor UUCP ================= This package does not come with any fancy shell scripts or scheduling programs. Maybe someday. If you have another package, you may well be able to use the scheduling mechanisms it provides. Otherwise, the program can be used by making crontab entries. Whenever you want to call all systems with outstanding work, use uucico -r1 Whenever you want to call a specific system foo, use uucico -s foo If you want to make sure that a system foo gets retried if the original call fails, create an empty work file for it. For example, if using `SPOOLDIR_TAYLOR' touch /usr/spool/uucp/foo/C./C.A0000 Under `SPOOLDIR_BNU', use touch /usr/spool/uucp/foo/C.fooA0000 I use the following crontab entries locally: 45 * * * * /bin/echo /usr/lib/uucp/uucico -r1 | /bin/su uucpa 40 4,10,15 * * * touch /usr/spool/uucp/uunet/C./C.A0000 Every hour, at 45 minutes past, this will check if there is any work to be done. Also, at 4:40am, 10:40am and 3:40pm this will create an empty work file for `uunet', forcing the next check to call `uunet'. You will also want to periodically trim the log files, which by default are `/usr/spool/uucp/Log' and `/usr/spool/uucp/Stats'. The `savelog' program in the `contrib' directory may be of use.  File: uucp.info, Node: TCP, Prev: Usage, Up: Overall Installation TCP together with Taylor UUCP ============================= If your system has a Berkeley style socket library, you can compile the code to permit making connections over TCP. Specifying that a system should be reached via TCP is easy, but nonobvious. If you are using the new style configuration files, *Note Configuration files::. Basically when definining the system put in the line `port type tcp' and, if necessary, `port service XXX' where XXX is the port number to use (the default is to look up `uucp' in `/etc/services' and if not found to use port 540). You can specify the address of the remote host with `address a.b.c'. If you don't specify an address, the remote system name will be used. You should give an explicit chat script for the system when you use TCP; the default chat script begins with a carriage return, which will not work with some UUCP TCP servers. If you are using V2 configuration files, add a line like this to `L.sys': foo Any TCP uucp foo.domain chat-script This will make an entry for system foo, to be called at any time, over TCP, using port number `uucp' (as found in `/etc/services'; this may be specified as a number), using remote host `foo.domain', with some chat script. If you are using BNU configuration files, add a line like this to Systems: foo Any TCP - foo.domain chat-script and a line like this to Devices: TCP uucp - - You only need one line in Devices regardless of how many systems you contact over TCP. This will make an entry for system foo, to be called at any time, over TCP, using port number `uucp' (as found in `/etc/services'; this may be specified as a number), using remote host `foo.domain', with some chat script. The `uucico' daemon can also be run as a TCP server. This code mostly works, but it's not perfect. I don't recommend investigating it unless you are willing to tinker a bit. Basically, you must define a port, either using the port file (*note port file::.) if you are using the new configuration method or with an entry in Devices if you are using BNU (there is no way to define a port using V2). If you are using BNU the port must be named `TCP' (a line as shown above will suffice). You can then start `uucico' as `uucico -p TCP' (after the `-p', name the port; in BNU it must be `TCP'). This will wait for incoming connections, and fork off a child for each one. Each connection will be prompted with `login:' and `Password:', and the results will be checked against the UUCP (not the system) password file (*note config file::.). Of course, you can get a similar effect by using the BSD `uucpd' program. You can also have `inetd' start up `uucico' with the `-l' switch, which will cause it to prompt with `login:' and `Password:' and check the results against the UUCP (not the system) password file. This may be used in place of `uucpd'.  File: uucp.info, Node: Configuration files, Next: Acknowledgements, Prev: Overall Installation, Up: Top Taylor UUCP configuration files ******************************* This chapter describes the configuration files accepted by the Taylor UUCP package if compiled with `HAVE_TAYLOR_CONFIG' defined in `conf.h'. All the configuration files follow a simple line-oriented keyword value format. The first word on each line is a keyword of some sort (empty lines are ignored, as are leading spaces; unlike BNU, lines with leading spaces are read). The rest of the line is interpreted according to the keyword. Most keywords are followed by numbers, boolean values or simple strings (with no embedded spaces). The `#' character is used for comments, and everything from a `#' to the end of the line is ignored unless the `#' is preceded by a `\' (backslash); if the `#' is preceeded by a `\', the `\' is removed but the `#' remains in the line (this can be useful for a phone number containing a `#') (the backslash is not a general quoting character; to enter the sequence `\#', you would use `\\#'). Everything after the keyword must be on the same line. A BOOLEAN may be specified as `y', `Y', `t', or `T' for true and `n', `N', `f', or `F' for false; any trailing characters are ignored, so `true', `false', etc., are also acceptable. * Menu: * config file:: The main configuration file * sys file:: The system configuration file * port file:: The port configuration files * dial file:: The dialer configuration files * Example:: Brief example of configuration files  File: uucp.info, Node: config file, Next: sys file, Prev: Configuration files, Up: Configuration files The main configuration file =========================== The main configuration file may be specified by the `-I' option to `uucico' (and all the other programs as well). It is named `config' and is in the directory NEWCONFIGDIR which is defined by the Makefile variable `newconfigdir' (by default it is `/usr/local/lib/uucp'). As all the values that may be specified in it also have defaults, there need not be a main configuration file at all. `nodename STRING' `hostname STRING' `uuname STRING' These keywords are equivalent. They specify the UUCP name of the local host. If there is no configuration file, an appropriate function will be used to get the host name, if possible. `spool STRING' Specify the spool directory. The default is from `sysdep.h'. Command files, work files, temporary files, log files, etc., are stored in this directory and in subdirectories of it. `sysfile STRINGS' Specify the system file(s). The default is the file `sys' in the directory NEWCONFIGDIR. These files holds information about other systems with which this system communicates; *Note sys file::. Multiple system files may be specified by given on the line, and the `sysfile' command may be repeated; each system file has its own set of defaults. `portfile STRINGS' Specify the port file(s). The default is the file `port' in the directory NEWCONFIGDIR. These files describe ports which are used to call other systems and accept calls from other systems; *Note port file::. No port files need be named at all. Multiple port files may be given on the line, and the `portfile' command may be repeated. `dialfile STRINGS' Specify the dial file(s). The default is the file `dial' in the directory NEWCONFIGDIR. These files describe dialing devices (modems); *Note dial file::. No dial files need be named at all. Multiple dial files may be given on the line, and the `dialfile' command may be repeated. `dialcodefile STRINGS' Specify the dialcode file(s). The default is the file `dialcode' in the directory NEWCONFIGDIR. These files specify dialcodes that may be used when sending phone numbers to a modem. This permits using the same set of phone numbers in different area-codes or with different phone systems, by using dialcodes to specify the calling sequence. When a phone number goes through dialcode translation, the leading alphabetic characters are stripped off. The dialcode files are read line by line, just like any other configuration file, and when a line is found whose first word is the same as the leading characters from the phone number, the second word on the line (which would normally consist of numbers) replaces the dialcode in the phone number. No dialcode file need be used. Multiple dialcode files may be specified on the line, and the `dialcodefile' command may be repeated; all the dialcode files will be read in turn until a dialcode is located. `pubdir STRING' Specify the public directory. The default is from `sysdep.h'. On Unix, when a file is named using a leading `~/', it is taken from or to the public directory. Each system may use a separate public directory by using the `pubdir' command in the system configuration file; *Note sys file::. `callfile STRINGS' Specify the call out login name and password file(s). The default is the file `call' in the directory NEWCONFIGDIR. If the call out login name or password for a system are given as `*' (*note sys file::.), these files are read to get the real login name or password. Each line in the file(s) has three words: the system name, the login name, and the password. This file is only used when placing calls to remote systems; the password file described under `passwdfile' below is used for incoming calls. The intention of the call out file is to permit the system file to be publically readable; the call out files must obviously be kept secure. These files need not be used. Multiple call out files may be specified on the line, and the `callfile' command may be repeated; all the files will be read in turn until the system is found. `passwdfile STRINGS' Specify the password file(s) to use for login names when `uucico' is doing its own login prompting, which it does when given the `-e', `-l' or `-w' switch. The default is the file `passwd' in the directory NEWCONFIGDIR. Each line in the file(s) has two words: the login name and the password (e.g. `Ufoo foopas'). The login name is accepted before the system name is known, so these are independent of which system is calling in; a particular login may be required for a system by using the `called-login' command in the system file (*note sys file::.). These password files are optional, although one must exist if `uucico' is to present its own login prompts. Multiple password files may be specified on the line, and the `passwdfile' command may be repeated; all the files will be read in turn until the login name is found. `logfile STRING' Name the log file. The default is from `sysdep.h'. Logging information is written to this file. If `HAVE_BNU_LOGGING' is defined in `conf.h', then by default a separate log file is used for each system. Using this command to name a log file will cause all the systems to use it. `statfile STRING' Name the statistics file. The default is from `sysdep.h'. Statistical information about file transfers is written to this file. `debugfile STRING' Name the file to which debugging information is written. The default is from `policy.h'. This command is only effective if the code has been compiled to include debugging (this is controlled by the `DEBUG' variable in `policy.h'). After the first debugging message has been written, messages written to the log file are also written to the debugging file to make it easier to keep the order of things straight. The debugging file is different from the log file because information such as passwords can appear in it, so it must be not be publically readable. `debug STRING ...' Set the debugging level. This command is only effective if the code has been compiled to include debugging. The default is to have no debugging. The arguments are strings which name the types of debugging to be turned on. The following types of debugging are defined: `chat' Output debugging messages for chat scripts. `handshake' Output debugging messages for the initial handshake. `proto' Output debugging messages for protocols. `port' Output debugging messages for actions on the communication port. `config' Output debugging messages while reading the configuration files. `spooldir' Output debugging messages for actions in the spool directory. `execute' Output debugging messages whenever another program is executed. `incoming' List all incoming data in the debugging file. `outgoing' List all outgoing data in the debugging file. `all' All of the above. The debugging level may also be specified as a number. A 1 will set `chat' debugging, a 2 will set both `chat' and `handshake' debugging, and so on down the possibilities. Currently a 9 will turn on all possible debugging, since there are 9 types of debugging messages listed above; more debugging types may be added in the future. The `debug' command may be used several times in the configuration file; every debugging type named will be turned on. When running any of the programs, the `-x' switch (actually, for `uulog' it's the `-X' switch) may be used to turn on debugging. The argument to the `-x' switch is one of the strings listed above, or a number as described above, or a comma separated list of strings (e.g. `-x chat,handshake'). The `-x' switch may also appear several times on the command line, in which case all named debugging types will be turned on. The `-x' debugging is in addition to any debugging specified by the `debug' command; there is no way to cancel debugging information. The debugging level may also be set specifically for calls to or from a specific system with the `debug' command in the system file (*note sys file::.). The debugging messages are somewhat idiosyncratic, and it may be necessary to refer to the source code for additional information in some cases. `unknown STRING ...' The STRING and subsequent arguments are treated as though they appeared in the system file (*note sys file::.). They are used to apply to any unknown systems that may call in, probably to set file transfer permissions and the like. If the `unknown' command is not used, unknown systems are not permitted to call in. `max-uuxqts NUMBER' Specify the maximum number of `uuxqt' processes which may run at the same time. Having several `uuxqt' processes running at once can significantly slow down a system, but since `uuxqt' is automatically started by `uucico', it can happen quite easily. The default for `max-uuxqts' is 0, which means that there is no limit. If BNU configuration files are being read and the code was compiled without `HAVE_TAYLOR_CONFIG', then if the file `Maxuuxqts' in the configuration directory contains a readable number it will be used as the value for `max-uuxqts'. `v2-files BOOLEAN' If the code was compiled to be able to read V2 configuration files, a false argument to this command will prevent them from being read. This can be useful while testing. The default is true. `bnu-files BOOLEAN' If the code was compiled to be able to read BNU configuration files, a false argument to this command will prevent them from being read. This can be useful while testing. The default is true.