¿Es posible decirle a patchno generar .origy .rejarchivos? Me resulta extremadamente molesto que el parche los cree.
¿Es posible decirle a patchno generar .origy .rejarchivos? Me resulta extremadamente molesto que el parche los cree.
Respuestas:
Si no está dando ninguna opción a patchotra -pN, solo crea esos archivos cuando un parche no se aplica de manera limpia.
Entonces, una opción es dejar de crear (o aceptar) parches malos. :)
De vuelta en el mundo real, esta es una característica. Cuando patch(1)no se puede aplicar un segmento de parche al archivo original, guarda la copia del archivo original temporal de forma duradera *.orig, volca el segmento rechazado *.rejy continúa tratando de aplicar segmentos de parche. La idea es que puede abrir el *.rejarchivo y completar el proceso de parche manualmente copiando partes y piezas en el archivo parcheado. El *.origarchivo también puede ser útil cuando el proceso de parche destruye accidentalmente algo, y debe consultar la versión original para solucionarlo.
No siempre soluciono un parche malo con el texto de los archivos *.rejy *.orig, pero es bueno tenerlos en caso de que los necesite.
Una vez que he arreglado un parche malo, ejecuto el siguiente script en la raíz del proyecto para limpiar rápidamente las cosas:
#!/bin/bash
find . '(' \
-name \*-baseline -o \
-name \*-merge -o \
-name \*-original -o \
-name \*.orig -o \
-name \*.rej \
')' -delete
Lo llamo cleanup-after-bad-patchporque el nombre largo asegura parcialmente contra ejecutar esto accidentalmente, ya que podría eliminar los archivos que aún necesita. Sin embargo, para ser honesto, normalmente lo ejecuto escribiendo cleanTabEnter, eso es suficiente para encontrar este script en PATHmis máquinas de desarrollo.
Los patrones adicionales que verifica son para los archivos de salida de mi sistema de control de versiones de elección cuando encuentra el mismo problema durante una operación de fusión. Es posible que desee ajustarlo para sus herramientas VCS / SCM .
A decir parche no a las copias de seguridad producen simplemente omitir los -by las --backup-...opciones.
Para indicarle que no cree .rejarchivos, agregue la -r -opción al comando.
GNU patch 2.6Mac tal vez intente-r /dev/null
La --no-backup-if-mismatchopción evitará los archivos ".orig".
También es posible que desee probar la --mergeopción, que crea un conflicto en el archivo.
En todos los casos, debe tener alguna forma de volver a un buen estado rápidamente si la fusión se vuelve abrumadora.
Estoy atascado con el parche v2.5.4 donde -r -hace que cree los archivos de rechazo nombrados -.
Descubrí que, por --reject-file=ejemplo, el valor vacío hace que el parche falle con el código de salida 2 SI intenta escribir un archivo de rechazo. Si no hay rechazos, funciona como se esperaba. Si bien no es una solución completa para la versión anterior del parche, en algunas circunstancias esto puede ser aceptable o deseado.
Lo mejor que se me ocurrió (es cierto que una forma de barrer la tierra debajo de la alfombra) es usar -r <tmpfile>, es decir:
# patch -r /tmp/deleteme.rej -i patchfile filetobepatched
desde v2.5.8, en -r -realidad crea el -archivo.
parche -p1 -B / dev / null -r - <file.patch
-Bbandera no envía la *.origsalida a /dev/null, como parece desde su comando. Simplemente sucede que los usuarios normales no pueden escribir en archivos llamados cosas así /dev/nullfoo.cpp. Si haces esto como root, obtendrás basura en tu /devárbol. En segundo lugar, -r -no suprime el *.rejarchivo. Simplemente parece hacerlo porque el error debido a la -Bbandera falsa impide que te muestre lo que realmente haría sin el -B, que es crear un archivo llamado -en el directorio actual.
man patch: "-r Coloca los rechazos en el archivo de rechazo en lugar del archivo .rej predeterminado. Cuando el archivo de rechazo es -, descarta los rechazos".