1 files changed, 573 insertions, 0 deletions
diff --git a/gnu/libexec/uucp/TODO b/gnu/libexec/uucp/TODO
new file mode 100644
index 000000000000..a1cc643ab52f
--- /dev/null
+++ b/gnu/libexec/uucp/TODO
@@ -0,0 +1,573 @@
+This is a list of things to do for the Taylor UUCP package.  Please
+feel free to work on any of them.  You may want to check with me first
+to make sure that nobody else is working on them as well.
+
+Some of these are my thoughts, but most are suggestions from other
+people; I have tried to give credit.  They are in the order I received
+them; the missing numbers have already been implemented.
+
+Just because something is on the list doesn't mean that I necessarily
+think it is a good idea.  It does mean that I think it's worth
+thinking about.
+
+2.
+
+John Cowan <cowan@snark.thyrsus.com> says:
+
+>I think you should accept a broader range of time specifications.
+>Consider using getdate() (from your handy Usenet news source code)
+>with its high-powered yacc parser.
+
+Of course, getdate() accepts a single date, but we want a range.  A
+better syntax would be certainly be nice.
+
+9.
+
+Gordon Burditt <gordon@sneaky.lonestar.org> warns about modifications
+to the TZ environment variable, to fool uucico into dialing out at an
+inappropriate time.
+
+10.
+
+Gordon Burditt <gordon@sneaky.lonestar.org> says:
+
+>(4) Less important, because few people will have this problem, is a 
+>port-specific dialcodes file.  Why?  Well, one system I had was connected
+>to 2 inside lines "dial 9 for outside line", and one outside line (which
+>doesn't want the 9).  A number of the systems called were "inside", so
+>you didn't add the 9 on those lines dialing from inside, but you did add 
+>"390" to the 4-digit number if you dialed it via "outside".  Also not 
+>unheard of are systems with 2 outside lines that are local to different 
+>area codes, or one local outside line and one WATS line (which MUST
+>have an area code).
+>Example:
+>	inside-line Dialcodes		outside-line Dialcodes
+>	pbx	""			pbx	"390"
+>	local	"9"			local	""
+>	nyc	"9-1212"		nyc	"1212"
+
+12.
+
+Ralf E. Stranzenbach <ralf@reswi.ruhr.de> says:
+
+>It would be nice to also have the option of running a shell script each time  
+>uucico connects/disconnects a systen. I do not mean shell scripts for dial/in.  
+>I would like to do some accounting and batching when the connection  
+>establishes.
+
+13.
+
+les@chinet.chi.il.us (Leslie Mikesell) writes:
+
+>>local-send /usr/spool/uucppublic !/usr/spool/uucpublic/private
+>>
+>>The directories are searched from left to right, and the last one to
+>>match determines whether the file may be sent or not.  This is
+>>slightly more general than NOWRITE, since it permits a public
+>>directory within a private directory within a public directory,
+>>although probably nobody will ever want that.
+>
+>Interesting... The obvious enhancement is to generalize to shell-like
+>wild cards for the READ/WRITE/COMMANDS entries.
+
+14.
+
+Should there be a way for chat scripts to specify the parity to
+generate?  I don't think there's much point to specifying what parity
+to accept.
+
+17.
+
+The -b and -s switches to uux are not implemented by uuxqt.
+
+18.
+
+If we are supposed to call a system back, we should do it immediately
+rather than merely queuing up an empty command file.
+
+22.
+
+Add an ftp port type which uses anonymous ftp rather than any of the
+UUCP protocols to do file transfers.  This would allow ftp work to be
+done late at night, and allow neighbors of cooperative Internet sites
+to use UUCP forwarding for anonymous FTP.
+
+31.
+
+David Nugent: add a -C option to uucico to only call the system if
+there is work to do.
+
+32.
+
+It would be nice if uucico could sleep until a line was available.
+This is complicated by the possibility of wanting to wait for any of
+several different lines, and one would really want some sort of
+semaphore function to do it right.  If the available lines could be
+sorted, then each could be assigned to a byte in a line lock file.
+Looking for a line could be done by sleeping on a read lock on all
+possible lines.  Once it came through, write locks would be attempted.
+If they all failed, somebody else snuck in, so you would sleep on a
+read lock again.  This isn't great because a process could be starved,
+but it might be better than nothing.
+
+This could be tied in to uucp and uux, such that they wouldn't
+actually fire up uucico unless a line was known to be available; an
+additional switch would be used to fire up uucico anyhow (or one could
+switch the default behaviour and the switch).
+
+So how do you sort the lines?  You could just use the index in the
+port (or Devices) file, but what if multiple ports used the same
+physical device?  Hmmm.
+
+43.
+
+David Nugent: it would be nice to be able to set debugging, log, and
+statistics files on a site by site basis.
+Brian Murrell: heck, set those files on a port by port basis as well.
+
+74.
+
+Yanek Martinson: allow each system to independently choose whether to
+permit shell execution.
+
+81.
+
+Marty Shannon: log reason for dial failure (chat-fail string) in
+.Status file.
+
+83.
+
+Switch between 'M' and 'S' correctly in the BNU log file output.
+
+86.
+
+Les Mikesell: allow a separate program to be specified to handle the
+communications with a particular system.
+
+105.
+
+T. William Wells: close and open the Debug file after each file
+transfer.  Alternatively, cycle through a series of Debug file names
+every 1000 lines or so.
+
+106.
+
+Marty Shannon: add a time command for ports, to specify when they may
+be used.
+
+115.
+
+T. William Wells: new options for uustat:
+	-i display job ids only
+Also, there should perhaps be a configuration option to request uustat
+to only display jobs submitted by the user running uustat, except for
+root and uucp.
+
+117.
+
+Marc Unangst: provide some way to change the debugging level of a
+running uucico.  T. William Wells suggests having it read a file to
+change arbitrary configuration information, although obviously one has
+to be careful of what gets changed while a connection is active.
+
+120.
+
+Jarmo Raiha: new chat-fail commands: one to not update the status file
+and require a retry wait, and one to permit the string to occur a few
+times before reporting an error.
+
+124.
+
+Peter da Silva: perhaps there should be a ``chat-end-program'' command
+to let a program be run after the initial handshake has been completed
+and the protocol has been selected and turned on.  This would let
+people run stty to change their terminal parameters.
+
+128.
+
+Richard Stallman: have an interactive program to set up a chat script.
+It would let you type directly to the port, recording what you type as
+send strings and recording what comes back from the other side as
+expect strings.
+
+129.
+
+Use POSIX fcntl locks when possible instead of creating a lock file.
+
+130.
+
+Chip Salzenberg: BSD lets you override the timeout for a particular
+expect string by using a trailing ~.
+
+138.
+
+T. William Wells: BNU apparently uses a file named A.whatever to hold
+the line number reached in current C. file processing.  This is a
+hack, and won't work right with size control anyhow, but
+fsysdep_did_work could, for example, clobber the first byte in the
+line to a # or something to mark that it had been finished.  Still a
+hack, but a better one.
+
+139.
+
+Patrick Smith: incorporate patches to generate full debugging traces
+with less debugging file overhead.  The debugging file repeats too
+much information at great length right now--not good.
+
+141.
+
+Franc,ois Pinard: batch up pauses and delays in chat scripts and do
+them all at once in a single system call.  This is particularly useful
+for pauses on systems which don't support subsecond sleeps.  For
+everything else it's a fairly minor optimization.
+
+142.
+
+Franc,ois Pinard: give uustat an option to requeue jobs to another
+system.  This only makes a lot of sense for rmail executions, but it's
+fairly easy to do for any type of command.  I think uucico does all
+the file checking needed to ensure that this doesn't break security,
+but that should be double-checked.
+
+144.
+
+T. William Wells: add a -g option to uucico to permit specifying the
+maximum grade to be transferred at that time.  This could restrict the
+timegrade command further, but should not be permitted to override it.
+
+145.
+
+T. William Wells: if uucico or uuxqt get started with bad arguments,
+put an indication in the log file since stderr may be /dev/null.
+
+146.
+
+Richard Todd: it would be nice to sometimes be able to request the
+other side to turn on debugging.
+
+147.
+
+Bart Schaefer: some more possible options for uucico:
+    -R reverse roles (hangup immediately).  Not too exciting.
+    some method to restrict calling to particular systems.
+
+148.
+
+Jarmo Raiha: some method to control the work queue at the remote end.
+This could get awfully general, though.
+
+149.
+
+The interaction of the time command and defaults can be confusing,
+since any time command in the actual system entry, even a fairly
+specific one, will wipe out the default entry.  Not sure what can be
+done about this.
+
+150.
+
+Jarmo Raiha: should there be some way to specify modem initialization
+strings when uucico is hanging on a port with -l or -e?  This would
+presumably require a new type of chat script associated with a dialer.
+
+151.
+
+Petri Helenius: log complete CONNECT string reported by modem, so that
+the baud rate is recorded in the log file.
+
+152.
+
+Marc Evans: let the protocol selection be based on the CONNECT string,
+so that different protocols could be selected based on what type of
+connection was made.
+
+153.
+
+Chris Lewis: provide a signal to get a core dump even on systems which
+won't do core dumps if the uid is not the euid.  One could catch a
+signal, call setuid (getuid ()), and then raise the signal again.
+Unfortunately the core dump has to wind up in a directory which is
+world writable, so that the process is able to create the core file,
+but is not world readable, since that would permit anybody to read the
+core dump file and extract private information from it.
+
+154.
+
+Les Mikesell: write a new version of dial.o, with provisions for
+running a chat script.
+
+155.
+
+Scott Blachowicz: perhaps there should be some way to telling uucico
+to not log certain errors.  This could get fairly complex, though.
+
+156.
+
+Franc,ois Pinard: have uustat -m report the time of the last
+successful conversation when reporting a failure.
+
+158.
+
+Thomas Fischer: should there be a way to completely disable an entry
+in the sys, port or dial file?  Such as a ``disable'' command?
+
+159.
+
+Petri Helenius: when uuxqt -s is invoked, lock uuxqt for the system so
+that only one uuxqt is invoked per system.  If the -c option is used,
+don't lock on a per system basis, and ignore any per system locks
+(regardless of -s).  If neither option is used, respect existing
+system and command locks, and do any other type of file.
+
+161.
+
+Scott Blachowicz: provide some sort of include mechanism for the
+configuration files.
+
+162.
+
+Chris Lewis: add uuxqtpolicy command, probably in config, supporting
+the following values which determine when uuxqt should be run:
+	- never (let cron or something else worry about it)
+	- perinvocation (when uucico exits for good - current behaviour)
+	- persite (when uucico terminates a conversation - HDBish)
+	- periodic (per 5 or 10 incoming X. files - BSDish)
+	- perturnaround?
+
+163.
+
+Sort jobs in the send queue by size.  Pretty easy.
+
+164.
+
+Ed Carp: preserve files if uuxqt execution fails.
+
+165.
+
+Marc Sheldon: use exit codes from <sysexits.h> in uux and uucp.
+
+166.
+
+Chip Salzenberg: allow chat failure strings to specify a retry time.
+
+167.
+
+Gregory Bond: allow a dialer sequence for a TCP port, so you can make
+a TCP connection to a modem and then dial out.
+
+168.
+
+Jose A. Manas: allow a maximum connect time, after which we try to
+hang up the connection.  This requires a protocol extension, since
+there's no way to force the other side to hang up.  The best we can do
+without an extension is refuse to send any new jobs ourselves.  Of
+course, we could just drop the connection.
+
+169.
+
+Franc,ois Pinard: when given uustat -k00FC, check each possible job ID
+and use it if there is an unambiguous one.
+
+170.
+
+T. William Wells: if ! HAVE_SETREUID && ! HAVE_SAVED_SETUID, fork a
+subprocesses to revoke setuid and read the file over a pipe.
+
+171.
+
+Provide some option to have the internal uuconf functions not start
+with an underscore.
+
+172.
+
+T. William Wells: have some way to configure the parity for cu.
+
+173.
+
+Gert Doering: uuchk should display unknown system information.
+
+175.
+
+T. William Wells:
+Cu will not let itself be interrupted before the connection is
+established. If the chat script doesn't write something, cu does
+something odd, I've forgotten exactly what. Cu takes an
+inordinate amount of time after the line drops to exit. Somebody,
+cu, I think, but maybe uucico, drops dtr twice sometimes. Again,
+somebody will attempt to write after a hangup signal has been
+received. Once a hangup has been received, I/O should not be
+attempted. Among other things this will save the bacon of those
+who have brain damaged serial drivers (FAS, sigh, is among them)
+that don't handle output properly on a dropped line.
+
+Me:
+Note that sometimes you do want to write to a line after receiving a
+hangup signal.  For example, you might want to use ATZ to reset a
+modem.
+
+176.
+
+Hans-Dieter Doll: provide some way (another escape sequence) to pass
+the protocol to a chat-program.  Or, allow the protocol as an argument
+to the chat script command, which is more general, but maybe a bit too
+fancy.
+
+177.
+
+Nickolay Saukh: use a default port for cu, you can just do ``cu
+number''.
+
+178.
+
+Don Phillips: should there be some way to restrict of grade of
+transfers even when the other system places the call?
+
+179.
+
+Nickolay Saukh: add something to chat scripts to specify the timeout
+for an expect string, e.g. AT\c OK\W3 to wait for 3 seconds.  Except
+that perhaps the unit should not be seconds.  Berkeley apparently uses
+~number, not \W number, but I don't see any reason to prevent use of
+the ~ character in an expect string.
+
+180.
+
+Nickolay Saukh: if we have received a partial file, request the remote
+system to start sending from that point.  We currently accept SVR4
+style remote file positioning requests, but we do not generate them.
+
+181.
+
+Mark Powell: provide some way to restrict file transfer by size as
+well as grade?  One way would be to let uux select the grade based on
+the file size.
+
+182.
+
+Mark Powell: permit using multiple timetables in a single time
+statement.
+
+183.
+
+Optionally check for interrupts in fcopy_file, since it can take a
+long time to copy a file named in a uucp request.
+
+184.
+
+Ian Moran: if an attempt is made to a copy a file to a directory which
+denies write permission, perhaps the file should be saved somewhere.
+It must be saved in a private location, though.
+
+185.
+
+A syntax error in a command received from the remote system should not
+hold up the queue.  Unfortunately, I don't know what can be done
+except deny the command and report it.  Reporting a garbled command
+error should report the command correctly, rather than just the first
+character.
+
+186.
+
+Franc,ois Pinard: have an option to control nostop vs. stop on the cu
+command line.
+
+187.
+
+Fix the notion of %nostop to be SVID compatible.
+
+188.
+
+Frank Conrad: provide a means to set the strip mode for a port, to
+make it easy to use it from cu.
+
+189.
+
+Marc Unangst: there should be a way to specify that a system should
+only be called if there are jobs of a certain grade, but if the system
+is called then jobs of any grade should be transferred.  This
+basically means splitting the ``timegrade'' command into two commands:
+``place-call-timegrade'' and ``transfer-timegrade''.  Or maybe another
+optional argument to ``timegrade'':
+    timegrade grade time-string [retry] [transfer-any]
+not to mention
+    time time-string [retry] [transfer-any]
+Or maybe a separate command for a system or port like
+    transfer-any BOOL
+
+190.
+
+Chip Salzenberg: it would be really nice if uucico could automatically
+figure out when it could use an E command, so that uux didn't have to
+generate it and so that uucico could use with other versions of uux.
+Unfortunately, it would require uucico to read the execution file to
+see if it were suitable; this would be complex, but it would probably
+be worth it since normally the execution file would wind up not being
+sent.  Of course, the current method works too; it's just harder to
+combine with other versions of UUCP.
+
+191.
+
+Brian J. Murrell: should there be a way to cu a specific alternate?
+
+192.
+
+Andrew A. Chernov: Perhaps cu -pport system should be able to try
+different alternates for the system, because there might be different
+phone numbers to try.
+
+193.
+
+Brian J. Murrell: it would be nice to be able to ^C a cu chat script
+if you know it's going to fail.  Right now you have to use ^\.
+
+194.
+
+Steven S. Dick: have some way to force uucico off the phone at a
+certain time.  If that is done, it might be cool to have some way to
+predict how long a file transfer will take, and not do it if it will
+take too long.  But, if doing file restart, you can just quit and then
+pick it up later.
+
+195.
+
+Franc,ois Pinard: if the disk fills up, or some other error occurs,
+while receiving a file, perhaps it would make sense to turn the
+connection around immediately and see if the other side had anything
+to do, and then try again later.  This would require a protocol
+extension.  I don't know if it's worth it.  The code should be checked
+to see how well it handles a disk full situation.
+
+196.
+
+For real adjustability, provide some mechanism for picking the lead
+characters to use for the shell scripts, between : and #!.
+
+197.
+
+Try alternate IP addresses if there are any.
+
+198.
+
+Lele Gaifax: mention the device in Stats, and provide some way to
+associate the entry in Log with the entry in Stats.
+
+199.
+
+Michael Richardson: provide some way to turn on parity for the login
+chat, since some systems apparently require it.  Provide some way for
+cu to control parity after connecting.
+
+200.
+
+Chip Salzenberg: add max-remote-debug to config.
+
+201.
+
+Gert Doering: change the timeout message in chat scripts to reflect
+which chat script timed out (dialer or login).
+
+202.
+
+Bill Foote: have uuchk check whether a system is defined more than
+once.
+
+203.