Is it possible to tell
patch not to generate
I find it extremely annoying that patch creates these.
If you're not giving any option to
patch other than
-pN, it only creates those files when a patch fails to apply cleanly.
So, one option is to stop creating (or accepting) bad patches. :)
Back in the real world, this is a feature. When
patch(1) fails to apply a patch segment to the original file, it saves the temporary original file copy out durably as
*.orig, dumps the rejected segment to
*.rej, and continues trying to apply patch segments. The idea is that you can open the
*.rej file and complete the patch process manually by copying bits and pieces over to the patched file. The
*.orig file can also be useful when the patch process accidentally wrecks something, and you need to refer to the original version to fix it.
I don't always fix a bad patch with text from the
*.orig files, but it's nice to have them in case I need them.
Once I've fixed up a bad patch, I run the following script at the project root to quickly clean things up:
#!/bin/bash find . '(' \ -name \*-baseline -o \ -name \*-merge -o \ -name \*-original -o \ -name \*.orig -o \ -name \*.rej \ ')' -delete
I call it
cleanup-after-bad-patch because the long name partially insures against running this accidentally, since it could remove files you still need. To be honest, though, I normally run it by typing
cleanTabEnter, that being sufficient to find this script in the
PATH on my development machines.
The additional patterns it checks for are for the files output by my version control system of choice when it encounters the same problem during a merge operation. You may wish to adjust it for your VCS/SCM tools.
To tell patch not to produce backups just omit the
-b and any
To instruct it not to create
.rej files add
-r - option to the command.
--no-backup-if-mismatch option will avoid the ".orig" files.
You might also want to try the
--merge option, which creates an in-file conflict.
In all cases you should have some way to get back to a good state quickly if the merge becomes overwhelming.
I'm stuck with patch v2.5.4 where
-r - causes it to create reject files named
I found that
--reject-file= i.e. empty value causes patch to fail with exit code
2 IF it tries to write a reject file. If there are no rejects it works as expected. While not a complete solution for older version of patch, under some circumstances this may be acceptable or desired.
The best I could come up with (admittedly a way to sweep the dirt under the rug) is using
-r <tmpfile>, i.e.:
# patch -r /tmp/deleteme.rej -i patchfile filetobepatched
since in v2.5.8,
-r - actually creates the
patch -p1 -B /dev/null -r - < file.patch