Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
bk patch(7.3.3)						       bk patch(7.3.3)

       bk patch	- apply	a diff file to an original

       bk patch	[options] [originalfile	[patchfile]]

       but usually just

       bk patch	-pnum <	patchfile

       bk  patch  takes	a patch	file patchfile containing a difference listing
       produced	by bk diff and applies those differences to one	or more	origi-
       nal  files,  producing patched versions.	 Normally the patched versions
       are put in place	of the originals.  Backups can be made;	see the	-b  or
       --backup	 option.   The	names  of  the files to	be patched are usually
       taken from the patch file, but if there's just one file to  be  patched
       it can specified	on the command line as originalfile.

       Upon startup, bk	patch attempts to determine the	type of	the diff list-
       ing, unless overruled by	a -c (--context), -e (--ed), -n	(--normal), or
       -u  (--unified)	option.	 Context diffs (old-style, new-style, and uni-
       fied) and normal	diffs are applied by  bk  patch	 itself,  while	 ed(1)
       diffs are simply	fed to ed via a	pipe.

       bk  patch  tries	 to skip any leading garbage, apply the	diff, and then
       skip any	trailing garbage.  Thus	you could feed an article  or  message
       containing  a  diff  listing  to	 bk patch, and it should work.	If the
       entire diff is indented by a consistent amount, or if  a	 context  diff
       contains	 lines	ending in CRLF or is encapsulated one or more times by
       prefixing - to lines starting with - as specified by Internet RFC  934,
       this is taken into account.

       With  context diffs, and	to a lesser extent with	normal diffs, bk patch
       can detect when the line	numbers	mentioned in the patch are  incorrect,
       and attempts to find the	correct	place to apply each hunk of the	patch.
       As a first guess, it takes the line number mentioned for	the hunk, plus
       or minus	any offset used	in applying the	previous hunk.	If that	is not
       the correct place, bk patch scans both forwards and backwards for a set
       of  lines matching the context given in the hunk.  First	bk patch looks
       for a place where all lines of the context match.  If no	such place  is
       found, and it's a context diff, and the maximum fuzz factor is set to 1
       or more,	then another scan takes	place ignoring the first and last line
       of  context.  If	that fails, and	the maximum fuzz factor	is set to 2 or
       more, the first two and last two	lines  of  context  are	 ignored,  and
       another	scan  is made.	(The default maximum fuzz factor is 2.)	 If bk
       patch cannot find a place to install that hunk of the  patch,  it  puts
       the hunk	out to a reject	file, which normally is	the name of the	output
       file plus a .rej	suffix,	or # if	.rej would generate a file  name  that
       is  too	long  (if even appending the single character #	makes the file
       name too	long, then # replaces the file name's last  character).	  (The
       rejected	hunk comes out in ordinary context diff	form regardless	of the
       form of the input patch.	 If the	input was a normal diff, many  of  the
       contexts	are simply null.)  The line numbers on the hunks in the	reject
       file may	be different than in the patch file: they reflect the approxi-
       mate  location  that bk patch thinks the	failed hunks belong in the new
       file rather than	the old	one.

       As each hunk is completed, you are told if the hunk failed, and	if  so
       which  line  (in	 the new file) bk patch	thought	the hunk should	go on.
       If the hunk is installed	at a different line from the line number spec-
       ified in	the diff you are told the offset.  A single large offset might
       indicate	that a hunk was	installed in the wrong place.	You  are  also
       told  if	 a  fuzz  factor was used to make the match, in	which case you
       should also be slightly suspicious.  If the --verbose option is	given,
       you are also told about hunks that match	exactly.

       If no original file origfile is specified on the	command	line, bk patch
       tries to	figure out from	the leading garbage what the name of the  file
       to edit is, using the following rules.

       First,  bk  patch takes an ordered list of candidate file names as fol-

       =>  If the header is that of a context diff, bk patch takes the old and
	   new	file  names  in	 the header.  A	name is	ignored	if it does not
	   have	enough slashes to satisfy the or option.  The  name  /dev/null
	   is also ignored.
       =>  If there is an Index: line in the leading garbage and if either the
	   old and new names are both absent or	if bk patch is	conforming  to
	   POSIX, bk patch takes the name in the Index:	line.
       =>  For	the  purpose  of the following rules, the candidate file names
	   are considered to be	in the order (old, new,	index),	regardless  of
	   the order that they appear in the header.

       Then bk patch selects a file name from the candidate list as follows:

       =>  If  some  of	the named files	exist, bk patch	selects	the first name
	   if conforming to POSIX, and the best	name otherwise.
       =>  If bk patch is not ignoring RCS, ClearCase, and SCCS	 (see  the  or
	   option),  and  no  named files exist	but an RCS, ClearCase, or SCCS
	   master is found, bk patch selects the first named file with an RCS,
	   ClearCase, or SCCS master.
       =>  If  no  named  files	 exist,	 no RCS, ClearCase, or SCCS master was
	   found, some names are given,	bk patch is not	conforming  to	POSIX,
	   and	the  patch appears to create a file, bk	patch selects the best
	   name	requiring the creation of the fewest directories.
       =>  If no file name results from	the above heuristics,  you  are	 asked
	   for the name	of the file to patch, and bk patch selects that	name.

       To  determine the best of a nonempty list of file names,	bk patch first
       takes all the names with	the fewest path	name components; of those,  it
       then  takes all the names with the shortest basename; of	those, it then
       takes all the shortest names; finally, it  takes	 the  first  remaining

       Additionally,  if the leading garbage contains a	Prereq:	line, bk patch
       takes the first word from the prerequisites line	 (normally  a  version
       number)	and checks the original	file to	see if that word can be	found.
       If not, bk patch	asks for confirmation before proceeding.

       The upshot of all this is that you should be able to say,  while	 in  a
       news interface, something like the following:

	  | bk patch -d	/usr/src/local/blurfl

       and patch a file	in the blurfl directory	directly from the article con-
       taining the patch.

       If the patch file contains more than one	patch, bk patch	tries to apply
       each  of	 them  as if they came from separate patch files.  This	means,
       among other things, that	it is assumed that the name  of	 the  file  to
       patch  must  be	determined for each diff listing, and that the garbage
       before each diff	listing	contains interesting things such as file names
       and revision level, as mentioned	previously.

       -b  or  --backup
	   Make	 backup	 files.	 That is, when patching	a file,	rename or copy
	   the original	instead	of removing it.	 When backing up a  file  that
	   does	 not  exist,  an empty,	unreadable backup file is created as a
	   placeholder to represent the	 nonexistent  file.   See  the	-V  or
	   --version-control  option  for  details about how backup file names
	   are determined.
	   Back	up a file if the patch does not	match the file exactly and  if
	   backups are not otherwise requested.	 This is the default unless bk
	   patch is conforming to POSIX.
	   Do not back up a file if the	patch does not match the file  exactly
	   and if backups are not otherwise requested.	This is	the default if
	   bk patch is conforming to POSIX.
       -B pref	or  --prefix=pref
	   Prefix pref to a file name when generating its simple  backup  file
	   name.   For example,	with -B	/junk/ the simple backup file name for
	   src/patch/util.c is /junk/src/patch/util.c.
	   Read	and write all files in binary mode, except for standard	output
	   and	/dev/tty.   This option	has no effect on POSIX-conforming sys-
	   tems.  On systems like DOS where this option	 makes	a  difference,
	   the patch should be generated by diff -a --binary.
       -c  or  --context
	   Interpret the patch file as a ordinary context diff.
       -d dir  or  --directory=dir
	   Change  to  the  directory  dir  immediately, before	doing anything
       -D define  or  --ifdef=define
	   Use the #ifdef ...  construct to mark changes, with define  as  the
	   differentiating symbol.
	   Print the results of	applying the patches without actually changing
	   any files.
       -e  or  --ed
	   Interpret the patch file as an ed(1)	script.
       -E  or  --remove-empty-files
	   Remove output files that are	empty  after  the  patches  have  been
	   applied.   Normally	this option is unnecessary, since bk patch can
	   examine the time stamps on the header to determine whether  a  file
	   should  exist  after	patching.  However, if the input is not	a con-
	   text	diff or	if bk patch is conforming to POSIX, bk patch does  not
	   remove  empty  patched  files unless	this option is given.  When bk
	   patch removes a file, it also attempts to remove any	empty ancestor
       -f  or  --force
	   Assume  that	the user knows exactly what he or she is doing,	and do
	   not ask any questions.  Skip	patches	whose headers do not say which
	   file	 is to be patched; patch files even though they	have the wrong
	   version for the Prereq: line	in the patch; and assume that  patches
	   are not reversed even if they look like they	are.  This option does
	   not suppress	commentary; use	-s for that.
       -F num  or  --fuzz=num
	   Set the maximum fuzz	factor.	 This option  only  applies  to	 diffs
	   that	 have  context,	 and causes bk patch to	ignore up to that many
	   lines in looking for	places to install a hunk.  Note	that a	larger
	   fuzz	factor increases the odds of a faulty patch.  The default fuzz
	   factor is 2,	and it may not be set to more than the number of lines
	   of context in the context diff, ordinarily 3.
       -g num  or  --get=num
	   This	 option	 controls the actions of bk patch when a file is under
	   RCS or SCCS control,	and does not exist or is read-only and matches
	   the	default	version, or when a file	is under ClearCase control and
	   does	not exist.  If num is positive,	bk patch gets (or checks  out)
	   the	file  from  the	 revision  control  system;  if	zero, bk patch
	   ignores RCS,	ClearCase, and SCCS and	does not get the file; and  if
	   negative,  bk  patch	 asks  the  user whether to get	the file.  The
	   default value of this option	is given by the	value of the PATCH_GET
	   environment	variable  if  it  is set; if not, the default value is
	   zero	if bk patch is conforming to POSIX, negative otherwise.

	   Print a summary of options and exit.
       -i patchfile  or	 --input=patchfile
	   Read	the patch from patchfile.  If patchfile	is -, read from	 stan-
	   dard	input, the default.
       -l  or  --ignore-whitespace
	   Match  patterns loosely, in case tabs or spaces have	been munged in
	   your	files.	Any sequence of	one or more blanks in the  patch  file
	   matches  any	sequence in the	original file, and sequences of	blanks
	   at the ends of lines	are ignored.   Normal  characters  must	 still
	   match exactly.  Each	line of	the context must still match a line in
	   the original	file.
       -n  or  --normal
	   Interpret the patch file as a normal	diff.
       -N  or  --forward
	   Ignore patches that seem to be reversed or  already	applied.   See
	   also	-R.
       -o outfile  or  --output=outfile
	   Send	output to outfile instead of patching files in place.
       -pnum  or  --strip=num
	   Strip  the smallest prefix containing num leading slashes from each
	   file	name found in the patch	file.  A sequence of one or more adja-
	   cent	 slashes is counted as a single	slash.	This controls how file
	   names found in the patch file are treated, in case  you  keep  your
	   files  in  a	 different  directory than the person who sent out the
	   patch.  For example,	supposing the file name	in the patch file was


	   setting -p0 gives the entire	file name unmodified, -p1 gives


	   without the leading slash, -p4 gives


	   and not specifying -p at all	just gives you blurfl.c.  Whatever you
	   end	up  with is looked for either in the current directory,	or the
	   directory specified by the -d option.
	   Conform more	strictly to the	POSIX standard,	as follows:

	   =>  Take the	first existing file from the list  (old,  new,	index)
	       when intuiting file names from diff headers.
	   =>  Do not remove files that	are empty after	patching.
	   =>  Do not ask whether to get files from RCS, ClearCase, or SCCS.
	   =>  Require that all	options	precede	the files in the command line.
	   =>  Do not backup files when	there is a mismatch.
	   Use	style  word  to	quote output names.  The word should be	one of
	   the following:

	   literal	Output names as-is.
	   shell	Quote names  for  the  shell  if  they	contain	 shell
			metacharacters or would	cause ambiguous	output.
	   shell-always	Quote names for	the shell, even	if they	would normally
			not require quoting.
	   c		Quote names as for a C language	string.
	   escape	Quote as with c	except omit  the  surrounding  double-
			quote characters.

	   You	can  specify  the  default value of the	--quoting-style	option
	   with	the environment	variable QUOTING_STYLE.	 If  that  environment
	   variable is not set,	the default value is shell.
       -r rejectfile  or  --reject-file=rejectfile
	   Put rejects into rejectfile instead of the default .rej file.
       -R  or  --reverse
	   Assume  that	 this  patch  was  created  with the old and new files
	   swapped.  (Yes, I'm afraid that  does  happen  occasionally,	 human
	   nature  being  what	it  is.)   bk patch attempts to	swap each hunk
	   around before applying it.  Rejects come out	in the swapped format.
	   The	-R  option does	not work with ed(1) diff scripts because there
	   is too little information to	reconstruct the	reverse	operation.

	   If the first	hunk of	a patch	fails, bk patch	reverses the  hunk  to
	   see if it can be applied that way.  If it can, you are asked	if you
	   want	to have	the -R option set.  If it can't, the  patch  continues
	   to  be  applied  normally.	(Note:	this  method  cannot  detect a
	   reversed patch if it	is a normal diff and if	the first  command  is
	   an  append (i.e. it should have been	a delete) since	appends	always
	   succeed, due	to the fact that  a  null  context  matches  anywhere.
	   Luckily,  most patches add or change	lines rather than delete them,
	   so most reversed normal diffs begin with  a	delete,	 which	fails,
	   triggering the heuristic.)
       -s  or  --silent	 or  --quiet
	   Work	silently, unless an error occurs.
       -t  or  --batch
	   Suppress  questions	like  -f, but make some	different assumptions:
	   skip	patches	whose headers do not contain file names	(the  same  as
	   -f);	 skip patches for which	the file has the wrong version for the
	   Prereq: line	in the patch; and assume that patches are reversed  if
	   they	look like they are.
       -T  or  --set-time
	   Set	the  modification  and access times of patched files from time
	   stamps given	in context diff	headers,  assuming  that  the  context
	   diff	 headers  use  local  time.   This  option is not recommended,
	   because patches using local time cannot easily be used by people in
	   other  time zones, and because local	time stamps are	ambiguous when
	   local clocks	move backwards	during	daylight-saving	 time  adjust-
	   ments.  Instead of using this option, generate patches with UTC and
	   use the -Z or --set-utc option instead.
       -u  or  --unified
	   Interpret the patch file as a unified context diff.
       -v  or  --version
	   Print out the revision header and patch level of bk patch and exit.
       -V method  or  --version-control=method
	   Use method to determine backup file names.  The method can also  be
	   given by the	PATCH_VERSION_CONTROL (or, if that's not set, the VER-
	   SION_CONTROL) environment variable, which  is  overridden  by  this
	   option.   The method	does not affect	whether	backup files are made;
	   it affects only the names of	any backup files that are made.

	   The value of	method is like the GNU Emacs  `version-control'	 vari-
	   able;  bk patch also	recognizes synonyms that are more descriptive.
	   The	valid  values  for  method  are	 (unique   abbreviations   are

	   existing  or	 nil
	       Make  numbered  backups of files	that already have them,	other-
	       wise simple backups.  This is the default.
	   numbered  or	 t
	       Make numbered backups.  The numbered backup file	name for F  is
	       F.~N~ where N is	the version number.
	   simple  or  never
	       Make simple backups.  The -B or --prefix, -Y or --basename-pre-
	       fix, and	-z or --suffix options specify the simple backup  file
	       name.  If none of these options are given, then a simple	backup
	       suffix is used; it is the  value	 of  the  SIMPLE_BACKUP_SUFFIX
	       environment variable if set, and	is .orig otherwise.

	   With	 numbered  or  simple  backups,	if the backup file name	is too
	   long, the backup suffix ~ is	used  instead;	if  even  appending  ~
	   would make the name too long, then ~	replaces the last character of
	   the file name.
	   Output extra	information about the work being done.
       -x num  or  --debug=num
	   Set internal	debugging flags	of interest only to patch patchers.
       -Y pref	or  --basename-prefix=pref
	   Prefix pref to the basename of a file name when generating its sim-
	   ple backup file name.  For example, with -Y .del/ the simple	backup
	   file	name for src/patch/util.c is src/patch/.del/util.c.
       -z suffix  or  --suffix=suffix
	   Use suffix as the simple backup suffix.  For	example, with -z - the
	   simple  backup file name for	src/patch/util.c is src/patch/util.c-.
	   The backup suffix may also be specified by the SIMPLE_BACKUP_SUFFIX
	   environment variable, which is overridden by	this option.
       -Z  or  --set-utc
	   Set	the  modification  and access times of patched files from time
	   stamps given	in context diff	headers,  assuming  that  the  context
	   diff	 headers  use  Coordinated Universal Time (UTC,	often known as
	   GMT).  Also see the -T or --set-time	option.

	   The -Z or --set-utc and -T or --set-time options  normally  refrain
	   from	 setting  a  file's  time if the file's	original time does not
	   match the time given	in the patch header, or	if its contents	do not
	   match  the  patch exactly.  However,	if the -f or --force option is
	   given, the file time	is set regardless.

	   Due to the limitations of bk	diff output format, these options can-
	   not	update	the  times  of	files whose contents have not changed.
	   Also, if you	use  these  options,  you  should  remove  (e.g.  with
	   make	clean)	all  files  that  depend on the	patched	files, so that
	   later invocations of	make do	not get	confused by the	patched	files'

	   This	 specifies  whether  bk	 patch gets missing or read-only files
	   from	RCS, ClearCase,	or SCCS	 by  default;  see  the	 -g  or	 --get
	   If  set,  bk	 patch conforms	more strictly to the POSIX standard by
	   default: see	the --posix option.
	   Default value of the	--quoting-style	option.
	   Extension to	use for	simple backup file names instead of .orig.
	   Directory to	put temporary files in;	bk patch uses the first	 envi-
	   ronment  variable  in  this list that is set.  If none are set, the
	   default is system-dependent;	it is normally /tmp on Unix hosts.
	   Selects version control style;  see	the  -v	 or  --version-control

	   temporary files
	   controlling terminal; used to get answers to	questions asked	of the

       bk patch	uses the GNU implementation of patch(1).

       There are several things	you should bear	in mind	if you are going to be
       sending out patches.

       Create  your  patch systematically.  A good method is the command where
       old and new identify the	old and	new directories.  The  names  old  and
       new  should  not	 contain  any  slashes.	 The bk	diff command's headers
       should have dates and times in Universal	Time  using  traditional  Unix
       format,	so  that  patch	recipients can use the -Z or --set-utc option.
       Here is an example command, using Bourne	shell syntax:

	  LC_ALL=C TZ=UTC0 diff	-Naur gcc-2.7 gcc-2.8

       Tell your recipients how	to apply  the  patch  by  telling  them	 which
       directory  to  cd  to,  and  which bk patch options to use.  The	option
       string -Np1 is recommended.  Test your procedure	by pretending to be  a
       recipient and applying your patch to a copy of the original files.

       You can save people a lot of grief by keeping a patchlevel.h file which
       is patched to increment the patch level as the first diff in the	 patch
       file  you  send	out.   If you put a Prereq: line in with the patch, it
       won't let them apply patches out	of order without some warning.

       You can create a	file by	sending	out a diff that	compares /dev/null  or
       an empty	file dated the Epoch (1970-01-01 00:00:00 UTC) to the file you
       want to create.	This only works	if the file you	want to	create doesn't
       exist  already  in  the target directory.  Conversely, you can remove a
       file by sending out a context diff that compares	the file to be deleted
       with an empty file dated	the Epoch.  The	file will be removed unless bk
       patch is	conforming to POSIX and	the -E or --remove-empty-files	option
       is  not	given.	An easy	way to generate	patches	that create and	remove
       files is	to use the -N option to	bk diff	or --new-file option.

       If the recipient	is supposed to use the option, do not send output that
       looks like this:

	  diff -Naur v2.0.29/prog/README prog/README
	  --- v2.0.29/prog/README   Mon	Mar 10 15:13:12	1997
	  +++ prog/README   Mon	Mar 17 14:58:22	1997

       because	the two	file names have	different numbers of slashes, and dif-
       ferent versions of patch	interpret  the	file  names  differently.   To
       avoid confusion,	send output that looks like this instead:

	  diff -Naur v2.0.29/prog/README v2.0.30/prog/README
	  --- v2.0.29/prog/README   Mon	Mar 10 15:13:12	1997
	  +++ v2.0.30/prog/README   Mon	Mar 17 14:58:22	1997

       Avoid  sending patches that compare backup file names like README.orig,
       since this might	confuse	bk patch into patching a backup	 file  instead
       of  the	real  file.   Instead, send patches that compare the same base
       file names in different directories, e.g. old/README and	new/README.

       Take care not to	send out reversed patches, since it makes people  won-
       der whether they	already	applied	the patch.

       Try  not	to have	your patch modify derived files	(e.g. the file config-
       ure where there is a line configure:  in  your  makefile),
       since the recipient should be able to regenerate	the derived files any-
       way.  If	you must send diffs of derived files, generate the diffs using
       UTC,  have  the	recipients  apply  the	patch with the -Z or --set-utc
       option, and have	them remove any	unpatched files	that depend on patched
       files (e.g. with	make clean).

       While  you  may be able to get away with	putting	582 diff listings into
       one file, it may	be wiser to group related patches into separate	 files
       in case something goes haywire.

       Diagnostics  generally indicate that bk patch couldn't parse your patch

       If the --verbose	option is given, the  message  Hmm...  indicates  that
       there  is  unprocessed  text  in	 the  patch  file and that bk patch is
       attempting to intuit whether there is a patch in	that text and, if  so,
       what kind of patch it is.

       bk patch	returns	exit status

       0   if all hunks	were applied successfully
       1   if some hunks could not be applied
       2   if a	serious	error occurred

       When  applying a	set of patches in a loop it behooves you to check this
       exit status so you don't	apply a	later patch  to	 a  partially  patched

       Context	diffs  cannot  reliably	 represent the creation	or deletion of
       empty files, empty directories,	or  special  files  such  as  symbolic
       links.  Nor can they represent changes to file metadata like ownership,
       permissions, or whether one file	is a hard link to another.  If changes
       like  these  are	 also  required,  separate  instructions (e.g. a shell
       script) to accomplish them should accompany the patch.

       bk patch	cannot tell if the line	numbers	are off	in  an	ed(1)  script,
       and  can	 detect	bad line numbers in a normal diff only when it finds a
       change or deletion.  A context diff using fuzz factor 3	may  have  the
       same  problem.	Until  a  suitable interactive interface is added, you
       should probably do a context diff in these cases	to see if the  changes
       made sense.  Of course, compiling without errors	is a pretty good indi-
       cation that the patch worked, but not always.

       bk patch	usually	produces the correct results, even when	it has to do a
       lot  of	guessing.   However,  the results are guaranteed to be correct
       only when the patch is applied to exactly the same version of the  file
       that the	patch was generated from.

       The  POSIX  standard  specifies	behavior that differs from traditional
       patch behavior.	You should be aware of these differences if  you  must
       interoperate  with patch	versions 2.1 and earlier, which	do not conform
       to POSIX.

       In traditional
	   patch, the -p option's operand was optional,	 and  a	 bare  -p  was
	   equivalent to -p0.  The -p option now requires an operand, and -p 0
	   is now equivalent to	-p0.  For maximum compatibility,  use  options
	   like	-p0 and	-p1.

	   Also,  traditional patch simply counted slashes when	stripping path
	   prefixes; bk	patch counts pathname components.  That	is, a sequence
	   of  one or more adjacent slashes now	counts as a single slash.  For
	   maximum portability,	avoid sending patches containing  //  in  file
       In traditional
	   patch,  backups  were  enabled  by  default.	  This behavior	is now
	   enabled with	the -b or --backup option.

	   Conversely, in POSIX	patch, backups are never made, even when there
	   is  a  mismatch.   In  bk  patch, this behavior is enabled with the
	   --no-backup-if-mismatch option, or by conforming to POSIX with  the
	   --posix  option or by setting the POSIXLY_CORRECT environment vari-

	   The option of traditional patch is equivalent to the	options	of  bk
	   patch  used	a  complicated (and incompletely documented) method to
	   intuit the name of the file to be patched from  the	patch  header.
	   This	 method	 did  not conform to POSIX, and	had a few gotchas.  bk
	   patch uses a	different, equally complicated (but better documented)
	   method  that	 is  optionally	POSIX-conforming; we hope it has fewer
	   gotchas.  The two methods are compatible if the file	names  in  the
	   context  diff  header  and  the Index: line are all identical after
	   prefix-stripping.   Your  patch  is	normally  compatible  if  each
	   header's file names all contain the same number of slashes.
       When traditional
	   patch  asked	 the user a question, it sent the question to standard
	   error and looked for	an answer from the first file in the following
	   list	  that	was  a	terminal:  standard  error,  standard  output,
	   /dev/tty, and standard input.  Now  bk  patch  sends	 questions  to
	   standard  output and	gets answers from /dev/tty.  Defaults for some
	   answers have	been changed so	that bk	patch never goes into an infi-
	   nite	loop when using	default	answers.
	   patch  exited  with	a  status value	that counted the number	of bad
	   hunks, or with status 1 if there was	real trouble.	Now  bk	 patch
	   exits  with	status	1 if some hunks	failed,	or with	2 if there was
	   real	trouble.
       Limit yourself to the following options when sending instructions
	   meant to be executed	by anyone running bk patch, traditional	patch,
	   or  a  patch	that conforms to POSIX.	 Spaces	are significant	in the
	   following list, and operands	are required.


       Please report bugs via email to

       bk patch	could be smarter about partial	matches,  excessively  deviant
       offsets and swapped code, but that would	take an	extra pass.

       If code has been	duplicated (for	instance with #ifdef OLDCODE ... #else
       ... #endif), bk patch is	incapable of patching both versions,  and,  if
       it  works at all, will likely patch the wrong one, and tell you that it
       succeeded to boot.

       If you apply a patch you've already applied, bk patch thinks  it	 is  a
       reversed	 patch,	 and offers to un-apply	the patch.  This could be con-
       strued as a feature.

       Copyright 1984, 1985, 1986, 1988	Larry Wall.
       Copyright 1989, 1990, 1991, 1992, 1993, 1994, 1995,  1996,  1997,  1998
       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  that  the
       entire  resulting derived work is distributed under the terms of	a per-
       mission notice identical	to this	one.

       Permission is granted to	copy and distribute translations of this  man-
       ual into	another	language, under	the above conditions for modified ver-
       sions, except that this permission notice may be	included  in  transla-
       tions approved by the copyright holders instead of in the original Eng-

       Larry Wall wrote	the original version of	patch.	 Paul  Eggert  removed
       patch's	arbitrary limits; added	support	for binary files, setting file
       times, and deleting files; and made it conform better to	POSIX.	 Other
       contributors  include  Wayne  Davison,  who  added unidiff support, and
       David MacKenzie,	who added configuration	and backup support.


       Marshall	T. Rose	and Einar A. Stefferud,	Proposed Standard for  Message
       Encapsulation,	  Internet    RFC    934    <URL:
       notes/rfc934.txt> (1985-01).  bk-diff, bk-credits


GNU				  1998/03/21		       bk patch(7.3.3)


Want to link to this manual page? Use this URL:

home | help