Provided by: dist_3.5-30-3_all bug


       pat - patch generator tools


       pat [ -ahmnV ] [ filelist ]
       patcil [ -abfhnpqsV ] [ filelist ]
       patdiff [ -ahnV ] [ filelist ]
       patbase [ -ahV ] [ filelist ]
       patlog [ -hnruV ]
       patmake [ -hV ]
       patsend [ -hiquV ] [ patchlist ] [ recipients ]
       patnotify [ -hquV ] [ recipients ]
       patpost [ -hrV ] patchlist newsgroups
       patftp [ -hV ] [ patchlist ]
       patname [ -ahnmV ] -v version [ filelist ]
       patsnap [ -ahV ] [ -o snapshot ] [ filelist ]
       patcol  [  -achnmsCV  ]  [  -d  directory  ]  [ -f mani ] [ -S snap ] [
       filelist ]
       patclean [ -ahnmV ] [ filelist ]


       Pat and its associated programs generate patches for any  package  that
       has  been stored under RCS.  These programs hide many of the details of
       RCS that get in your way when constructing and maintaining  a  package.
       All  you  need  to  do to create a new patch is to edit your files, run
       pat, and furnish some descriptions to RCS and in  the  generated  patch
       file.   Details  such  as  how  to  initialize a new RCS file, what the
       comment string should be, how create a new branch,  how  to  deal  with
       subdirectories,  how to do diffs and how to organize the patch file are
       handled automatically.

       Before using any of the pat programs you must initialize  your  package
       by  running  packinit in the top-level directory of your package.  This
       produces a .package file that all of the dist programs make use of.

       In any of the programs that want a filelist, if you specify -a instead,
       all  files  in will be processed.  In any of the programs
       that want a patchlist, a null patchlist means the current  patch.   You
       may  use  hyphens,  commas and spaces to delimit patch numbers.  If the
       right side of a hyphen is the null string, the  current  patchlevel  is
       assumed  as  the  maximum  value. All the programs invoked with -h will
       print a small usage message with the meaning of each available options.
       The -V option gives the current version number.

       Pat  itself  is  a  wrapper  program  that  calls  patcil, patdiff, and
       patmake.  Usually you can just invoke pat and ignore  all  the  others.
       Pat  will  update  the MANIFEST file, if necessary (it will be an exact
       copy of  the  file,  provided  that  a  MANIFEST  already
       existed), eventually calling patcil on it.

       If  you  specify -n instead of a filelist, pat will find all files that
       are newer than patchlevel.h, put you into an editor to  trim  down  the
       list,  then  use that file list.  If every file of the list is removed,
       pat will be aborted.

       Patcil is used to do a ci -l on any listed files.  (It is assumed  that
       you always want to keep your files checked out.)  In addition to the -a
       switch, there is a -b switch which does a quick checkin  of  a  set  of
       files.   Instead of calling rcs on each file, it calls rcs on the whole
       list of files.  This is useful for checking in a trunk revision.   When
       you are checking in a new trunk revision you might also want to use the
       -s flag which will strip out old RCS  Log  entries  from  the  previous
       revision  so  that  you can start over fresh.  You probably should also
       use a -f which is passed through to the ci to force unchanged files  to
       be checked in.  To check in a new trunk revision, I say

            patcil -s -f -a

       Patcil  will ask for the log entry instead of letting ci do it, and has
       a little prompter built in that lets  you  manipulate  the  message  in
       various  ways.   Type  h  for a listing of what you can do.  One of the
       nicest things is that you can pop up into an editor, optionally with  a
       diff  listing  of  the  changes  since  the  last patch, in case you’ve
       forgotten what you changed.  If you type a CR as the  first  thing,  it
       includes the previous log message.  Exit the prompter with a CR.

       There are two different ways to use patcil.  You can either call patcil
       yourself, or let pat call it for you.  It doesn’t matter how many times
       you  call  patcil before running pat, since patdiff knows what the last
       patch base is to compare with.  Patcil can be called  in  any  of  your
       directories;  the  other  programs  must  be  called  in your top-level
       directory (or in bugs, when meaningful).

       When you are creating a new file at a given patchlevel, you must patcil
       it with the -p option. Otherwise, it will simply be checked-in as a new
       trunk revision. The name of the file will be added to the
       if  it does not already appear in it. If the name is found along with a
       description, that description will be passed through to rcs to properly
       initialize the RCS file.

       Patbase can be used to reset the patch base to the current version when
       you’ve scrapped the previous  patch  sequence  and  are  making  a  new
       distribution  kit.   What it really does is an rcs -Nlastpat:REV, where
       REV is the current revision.  If patdiff blows up and you want  to  set
       the  patch  base  back  to  some previous version, you have to call rcs
       -Nlastpat:REV yourself.

       Patdiff actually does the diffs  that  go  into  the  patch,  comparing
       whatever  version -Nlastpat points to with the most recently checked in
       version.  It then updates -Nlastpat to point to  the  current  version.
       It leaves the diff sitting in the bugs subdirectory for patmake to pick
       up.  It can either use rcsdiff,  or  a  diff  command  of  your  choice
       specified  when  you  run  packinit,  in  case your diff is better than

       Patlog is invoked by patmake usually, to update the ChangeLog file  (or
       whatever name that file has been given when you ran packinit).  It will
       gather log messages and launch an editor for you to make the  necessary
       updates.   If you have configured your package to also include RCS logs
       in the ChangeLog, another editor session will  be  launched  for  those
       too.  Finally, a final log is built as a candidate entry for ChangeLog,
       which you may also modify as you wish.

       When you don’t have configured  a  ChangeLog  file,  patlog  will  only
       gather  the  information  it needs to pass on to patmake and will exit.
       If you wish to call it yourself, you must do that  after  a  least  one
       sucessfull patdiff run. I recommend using the -n option the first time,
       and then use the -u option along with -n on subsequent runs to recreate
       files  only  when  needed. The -r option (which supersedes -u) prevents
       patlog from recreating an existing file, even if it is out of date.

       Patlog will call patcil and  patdiff  on  your  ChangeLog  file  (after
       having  stuffed  the  candidate  log entry you edited at the top of the
       file), unless prevented to do so by  the  -n  option.  This  means  the
       issued  patch  will update ChangeLog with current patch information, as
       you would expect it.

       Patmake combines all the pieces of the patch into one file and  invokes
       an  editor  so  you can add the subject and description.  It throws all
       your log  messages  in  as  Subjects  and  as  Description,  under  the
       assumption  that  it’s  easier  to  delete  what you don’t want than to
       remember everything you did.  You’ll also want to expand each  item  in
       the  Description  so  they  don’t just repeat the Subject lines. If you
       have a ChangeLog file, this  must  have  been  done  already,  or  your
       ChangeLog will not accurately represent what is described in the patch,
       given that it has already been updated when patmake puts  together  all
       the pieces (see the note about patlog above).

       Big  patches  will  be  split  in order to keep size of each patch to a
       reasonable size. This is handled automatically, so you  don’t  have  to
       bother  with  it.   The  priority  of  each patch is merely intuited by
       patmake, given the assumption that small changes have a great priority.

       Patsend,  patpost and patftp are used to distribute your patches to the
       world.  Patsend mails a set of patches to a set of recipients.  The  -u
       switch  adds  all  the  currently  registered  users who have asked for
       patches to be mailed to them, as well as the recipients specified while
       running  packinit.   The  -i switch includes information with the patch
       about how the user may deregister themselves so  they  do  not  receive
       future  patches  automatically;  this  is  also the default when the -u
       switch is used.  Patpost posts a set of patches to a set of newsgroups.
       Patftp merely copies the patch into your public ftp directory.

       Patnotify  simply  notifies users that a new patch has been released so
       that they can retrieve it by themselves from an archive site or via  e-
       mail  if  they are interested. The -u switch can be used to include all
       the currently registered users who have asked for such a  notification.
       The  message  includes  the  patch priority and description, as well as
       instructions on how to automatically request the patch (which will work
       only if you have mailagent installed).

       Both  patsend  and  patnotify  let  you  edit  the  address list before
       actually sending anything, unless you add the -q option.

       Patname can be used to  tag  a  set  of  files  with  a  symbolic  name
       (specified  with  -v).  This  will  set  the  name  for the most recent
       revision of each file.

       Patsnap will get a snapshot of your release by creating a SNAPSHOT file
       (name  can be changed via -o) listing the file names and the latest RCS
       revision number for that file. Such snapshots can be used  to  identify
       the  release  at  some  random  patchlevel  and  then  later be able to
       retrieve it by feeding the snapshot file to patcol.

       Patcol will check out a locked version of  a  file,  eventually  in  an
       alternate directory (specified with -d, thus mirroring the distribution
       tree).  All the files which have no RCS counterpart (e.g. patchlevel.h)
       will  be  simply copied by patcol. This is used by makedist to fake the
       distribution before making the kits. By default, patcol will not do the
       copyright  expansion  processing, but clients like makedist force it by
       using its -C option.  Alternatively,  you  may  force  copying  of  the
       checked-out  version  into  a  directory  by  using  the  -c  switch in
       conjunction with -d (or that former switch is simply ignored).

       Patcol can also take its file list from a  SNAPSHOT  file  via  the  -S
       switch, in which case it will check out the files using the RCS version
       specified by the snapshot file, such as one created by patsnap. You may
       instead  specify  -a,  -m  or  -n  to respectively use all the files in,  all  the  modified  files  (the  one  which  have   been
       patciled), or all the files newer than patchlevel.h.

       Patclean  will remove the working files after having checked in all the
       changes. You may  restores your working files by using patcol.

       Patindex may be used from the top level directory or  within  the  bugs
       directory.  It will list all the patches and their Subject: lines. This
       program knows about compressed patches and will decompress  them  while
       producing the listing.


       This  section  describes the RCS layer, in case  something in the tools
       breaks, so that you may fix your RCS files and restart the operation.

       All the patch tools get the main RCS trunk revision number out of  your
       .package  files,  say it’s 2.5. Then, at the time you ran packinit, you
       have chosen a branch for patches, usually number  1,  which  means  all
       your  modifications  will  be stored on the 2.5.1 RCS branch. The tools
       will create the branch for you when the time comes.

       Each last released revision is tagged with an RCS lastpat symbol.  When
       the  patch is built by patdiff, the lattest version on the 2.5.1 branch
       is compared with the one tagged as lastpat. This is why you may  safely
       issue  more than one patcil beffore issuing the patch and still have it
       all worked out. Of course patdiff will move  the  lastpat  tag  to  the
       lattest branch revision after processing a given file.

       All  the  log  messages  and  the  modified files are kept in your bugs
       directory, in hidden files (name starting with a dot). Those logs  will
       be  collected  when the patch is issued and the modified files are used
       by pat’s -m switch.

       Patdiff collects its patch hunks under the  bugs  directory,  in  files
       terminating with a .nn extension, where nn represents the current patch
       level + 1. (Which is going to be the next  patchlevel  when  the  patch
       will be made by patmake, unless it is too big to fit in one file).

       Patlog prepares a set of files for patmake: the .clog file collects the
       information that will go under  the  Description:  section  within  the
       patch,  and .xlog ones collect the ChangeLog candidate entry.  Finally,
       .rlog files store the RCS information that is to  be  included  in  the
       ChangeLog,  if requested. Note that the topmost three lines are garbage
       and are ignored by all the tools handling those files.

       In order to start up a new baseline  (i.e.  to  change  the  RCS  trunk
       revision  number),  you  need to rerun packinit and change that number.
       Then issue a new patcil, probably with the -s, -a and -f options...


       bugs/*.[0-9]+  Diffs for each file, gathered by  patmake  to  create  a
       bugs/patch*    Issued patches (can be compressed with compress only)
                      Description  to  be  filled into the patch (or the first
                      part if the patch is split into several parts).
                      Log messages for that patch
                      Files modified in that patch (checked in with patcil)
                      The priority of the next patch, computed by  patlog  for
                      patmake’s perusal.
                      The RCS logs computed by patlog.
                      The  Subject:  lines  for  the  next  patch, computed by
                      patlog for patmake’s perusal.
                      The candidate entry for ChangeLog.
       users          File filled in by  mailagent’s  "@SH  package"  command,
                      normally  issued  by  Configure,  recording  some of the
                      users who kindly registered themselves.


       PAGER          Which pager to use in patcil (overrides default)
       EDITOR         What editor should be used (overrides default)
       VISUAL         Same role as EDITOR but this one is checked first


       makedist(1), metaconfig(1).


       Most of this should be built into RCS.


       Larry Wall (version 2.0).
       Raphael Manfredi <>.

                                      ram                               PAT(1)