Cómo crear y aplicar parches con diff y patch en Linux

Guía Hardware » Guías de compra » Cómo crear y aplicar parches con diff y patch en Linux

Cuando hablamos de aplicar parches con patch en GNU/Linux no nos referimos a arreglar un vaquero roto, sino a un mecanismo muy usado en programación y administración de sistemas para introducir cambios de forma controlada. Un parche informático describe qué ha cambiado entre una versión y otra de uno o varios archivos, y permite que otra persona reproduzca esas modificaciones de manera rápida y fiable.

Este sistema se apoya sobre todo en dos comandos clásicos de los entornos Unix: diff para generar el parche y patch para aplicarlo. Aunque suenen a herramientas muy técnicas, su uso básico es bastante sencillo y resulta tremendamente útil tanto si colaboras con proyectos de software libre, como si mantienes tu propio código, documentación o incluso configuraciones de sistema.

Qué es exactamente un parche informático y para qué sirve

En el contexto de la informática, un parche es un conjunto de cambios que se aplican a uno o varios archivos con distintos objetivos: corregir errores (bugs), añadir nuevas funciones, actualizarse a versiones más recientes o limpiar partes obsoletas de un programa o documento. No se limita únicamente al código ejecutable, puede afectar a documentación, scripts, traducciones, ficheros de configuración y prácticamente cualquier tipo de texto.

De forma muy resumida, un parche describe qué líneas se añaden, cuáles se modifican y cuáles se eliminan. Esto permite transformar un archivo “viejo” en su versión “nueva” sin necesidad de enviar el archivo completo, algo clave cuando se trabaja en equipo o se mantiene un proyecto de gran tamaño. El destinatario del parche puede revisar los cambios con calma, aceptarlos o rechazarlos, y aplicarlos con un simple comando.

Un ejemplo típico sería el de alguien que revisa la documentación en español de un proyecto (por ejemplo, una aplicación médica como GNU Health) y detecta errores tipográficos o frases confusas. Esa persona corrige los archivos en su copia local, genera un parche y se lo envía al desarrollador o mantenedor del proyecto. Si el responsable considera que el contenido está bien, lo aplica sobre su repositorio y listo: las mejoras quedan integradas en el código oficial.

Este enfoque resulta muy cómodo porque, aunque hoy casi todo el mundo utiliza sistemas como Git, los parches siguen siendo una forma fácil de colaborar sin tener cuenta en el repositorio, sin subir ramas ni pelearse con interfaces web. Basta con mandar el archivo .patch por correo o adjuntarlo en un sistema de seguimiento de incidencias.

Cómo funciona la generación de parches con diff

La pieza clave para crear un parche en GNU/Linux es el comando diff, que compara dos archivos o directorios y muestra sus diferencias. A partir de esa comparación, podemos generar un archivo en formato estándar (normalmente estilo “unificado”) que luego se pueda aplicar con patch.

La idea práctica es muy sencilla: tomas un archivo original, haces una copia, modificas esa copia y, cuando has terminado los cambios, utilizas diff para obtener un listado estructurado de todas las diferencias. Ese listado se vuelca a un archivo con extensión .patch o .diff, que será el parche propiamente dicho.

Un flujo de trabajo típico con scripts en bash sería algo así: imaginemos que tienes un archivo llamado actualizar.sh con cierta lógica de actualización. Lo primero es conservar el original y tocar solo una copia, por seguridad y por claridad a la hora de generar el parche.

Copiarías el archivo con un comando del estilo:

cp actualizar.sh actualizar.sh.nuevo

A continuación, editarías actualizar.sh.nuevo con tu editor de texto favorito (nano, vim, VS Code, etc.) y harías todas las modificaciones que consideres necesarias: añadir funciones, corregir errores, eliminar secciones obsoletas o reordenar partes del script. Cuando termines, tendrás dos versiones: la original y la nueva.

Para generar el parche en formato unificado, usarías un comando como este:

diff -u actualizar.sh actualizar.sh.nuevo > cambios.patch

Aquí se combinan varios elementos importantes: diff -u compara el archivo viejo y el nuevo, y gracias a la redirección > mandamos la salida al archivo cambios.patch en lugar de dejarla en la pantalla. La opción -u (unified) hace que el resultado sea mucho más legible para seres humanos, porque incluye unas pocas líneas de contexto alrededor de cada cambio, lo que ayuda a entender qué se ha tocado.

En ese archivo .patch verás bloques con líneas que empiezan con “+” para las adiciones, “-” para lo que se elimina y algunas líneas sin prefijo que aportan contexto. También encontrarás cabeceras que indican el nombre de los archivos implicados y las secciones donde se producen los cambios. Este formato se ha convertido en estándar de facto y es compatible con infinidad de herramientas de desarrollo.

Cómo interpretar y revisar un archivo .patch

Aunque no es obligatorio entender al detalle la sintaxis de un parche para usarlo, conviene tener una noción básica de qué contiene el archivo generado por diff -u. Si lo abres con un editor de texto, verás algo parecido a:

--- actualizar.sh 2026-04-01 10:00:00
+++ actualizar.sh.nuevo 2026-04-01 10:05:00

Esas dos primeras líneas indican archivo original y archivo modificado. A partir de ahí aparecen bloques que comienzan con “@@ … @@” y que representan los distintos fragmentos donde hay cambios. Dentro de cada bloque, las líneas con “-” pertenecen al fichero original y se eliminarán, las líneas con “+” aparecerán en el nuevo archivo y las que no llevan ni “+” ni “-” se dejan como contexto.

Este formato permite que la herramienta patch pueda aplicar el parche incluso si las líneas no se encuentran exactamente en el mismo número, siempre que el contexto coincida razonablemente. Además, esa estructura facilita que un desarrollador revise el parche a simple vista y entienda rápidamente qué se ha tocado y por qué.

No es raro que algunos autores pidan parches “limpios y bien formateados”, precisamente para que su revisión sea más sencilla. Por eso resulta tan recomendable utilizar la opción -u y cuidar un poco el aspecto del diff, sobre todo en proyectos de cierta envergadura donde los mantenedores reciben muchos cambios.

Aplicar un parche con el comando patch

Una vez generado el archivo .patch y enviado a quien corresponda, llega el momento de aplicar esos cambios sobre el código o los documentos originales. Aquí entra en juego el comando patch, que se encarga de leer el parche y modificar los archivos implicados según las instrucciones que contiene.

La forma más sencilla de usarlo es situarte en el directorio adecuado (donde estén los archivos originales) y ejecutar algo del estilo:

patch < cambios.patch

De este modo, patch lee el parche de la entrada estándar y detecta automáticamente de qué fichero se trata mirando las cabeceras (las líneas “—” y “+++” que comentábamos antes). Si todo encaja, irá recorriendo los bloques del parche y aplicando cada fragmento sobre el archivo correspondiente, añadiendo, eliminando o modificando líneas.

Si se prefiere ser más explícito, también es posible indicar el fichero a parchear de forma directa, por ejemplo:

patch actualizar.sh < cambios.patch

En este caso, le estamos diciendo a patch en qué archivo aplicar las instrucciones que contiene cambios.patch. Esto es útil cuando quieres asegurarte de que no se toca nada que no deba tocarse, o cuando el parche solo afecta a un archivo concreto.

Durante el proceso, si patch encuentra algún problema con el contexto (por ejemplo, que el archivo ha cambiado demasiado desde que se generó el parche), puede preguntar qué hacer o incluso generar archivos .rej con los trozos que no ha sido capaz de aplicar. Es una señal clara de que hay que revisar el estado del código base y quizá regenerar el parche a partir de una versión más actual.

Cómo decide patch qué archivo debe modificar

Una duda frecuente cuando alguien se enfrenta por primera vez a esta herramienta es cómo sabe patch sobre qué fichero debe aplicar los cambios. La respuesta está en las cabeceras del propio archivo .patch, donde aparecen las líneas “—” (archivo original) y “+++” (archivo modificado), normalmente con la ruta completa o relativa a partir del directorio donde se generó el diff.

Si abres el fichero de cambios con un editor, verás algo como:

--- viejo.txt 2026-04-01 10:00:00
+++ nuevo.txt 2026-04-01 10:05:00

En muchos flujos de trabajo, el archivo original y el nuevo tienen el mismo nombre y solo cambian de ruta, pero el formato del parche mantiene ambas referencias. Cuando ejecutas patch sin parámetros, la herramienta lee esa información y busca el archivo correspondiente en la ubicación actual o siguiendo la ruta indicada en el parche.

Si la ruta incrustada en el parche no coincide exactamente con la tuya —por ejemplo, porque el autor lo tenía dentro de /tmp/proyecto/viejo.txt y tú lo has descargado en otro directorio—, patch puede preguntarte interactiva y explícitamente por el archivo sobre el que quieres actuar. En ese momento puedes indicar la ruta correcta o incluso cambiar el nombre del archivo si fuera necesario.

Esta flexibilidad hace que no sea imprescindible reproducir al milímetro la estructura de directorios del autor del parche, aunque cuanto más se parezca, menos guerra dará el proceso. No obstante, existe un mecanismo muy práctico para adaptar rutas automáticamente sin tocar el archivo .patch a mano.

Uso del parámetro -p y ajuste de rutas en patch

Para evitar editar a mano el archivo de cambios y, al mismo tiempo, adaptar las rutas que figuran en el parche a tu propio árbol de directorios, patch ofrece la opción -p, que indica cuántos componentes de la ruta se deben “recortar” desde el principio.

Imaginemos que en el parche aparece una ruta como:

/tmp/blogcrearpatchsyaplicarlosenlinux/viejo.txt

Si ejecutas:

patch -p0 < cambios.patch

Le estás diciendo a patch que no elimine ningún directorio de la ruta, de modo que intentará localizar exactamente /tmp/blogcrearpatchsyaplicarlosenlinux/viejo.txt. Es equivalente a no utilizar la opción -p, y solo funcionará si tu estructura de carpetas coincide con la del autor del parche.

En cambio, si usas:

patch -p1 < cambios.patch

Estarás eliminando el primer componente (/tmp) de la ruta completa, con lo que patch buscará el archivo bajo:

blogcrearpatchsyaplicarlosenlinux/viejo.txt

Y si te vas a:

patch -p2 < cambios.patch

Se recortarán los dos primeros directorios del camino (en el ejemplo, /tmp/blogcrearpatchsyaplicarlosenlinux/), quedando únicamente viejo.txt como ruta efectiva. Es decir, patch intentará parchear el archivo que encuentre con ese nombre en el directorio donde estás ejecutando el comando.

Este parámetro resulta especialmente útil cuando trabajas con parches que afectan a múltiples archivos en distintos subdirectorios, típicamente en proyectos grandes o cuando sincronizas cambios entre máquinas o distribuciones diferentes. En lugar de abrir el .patch y tocar a mano todas las rutas, juegas con -p0, -p1, -p2… hasta que encaje con tu estructura local.

Relación entre parches y actualización de software

Una cuestión interesante es cómo se relaciona todo esto con las actualizaciones de software que usamos a diario: cuando el sistema operativo te ofrece una nueva versión de una aplicación, ¿qué está pasando realmente por debajo? ¿Se desinstala el programa entero? ¿Se recompila desde cero? ¿O se aplican parches similares a los que genera diff?

La respuesta varía según el tipo de sistema y el gestor de paquetes, pero en muchos casos se utilizan mecanismos conceptualmente parecidos a los parches: se almacenan solo los cambios entre versiones para ahorrar ancho de banda y acelerar las actualizaciones. En entornos de desarrollo, cuando se actualiza un proyecto de código fuente, a menudo se descargan parches que se aplican sobre el árbol actual, reconstruyendo los ejecutables después.

En aplicaciones de escritorio y móviles, los sistemas pueden optar por descargar directamente paquetes completos con los binarios ya compilados, aunque internamente esos paquetes se hayan generado a partir de parches aplicados al código original. En sistemas operativos, ocurre algo parecido: se distribuyen nuevos paquetes con las versiones actualizadas o se aplican conjuntos de parches al kernel y a diversas librerías.

La diferencia principal está en el nivel de abstracción: para un usuario final, un “parche de seguridad” o una “actualización acumulativa” se traduce en que el sistema instala algo y, tras un reinicio o no, el programa se comporta de forma distinta. Pero detrás, los desarrolladores han estado trabajando con parches de código fuente, cambios en configuraciones y scripts que se integran y distribuyen empaquetados.

Gestión de parches a gran escala en ciberseguridad

Cuando hablamos de entornos corporativos, la cosa va un paso más allá: no basta con que un administrador teclee patch en un servidor aislado. Las organizaciones necesitan gestionar miles de parches en docenas o cientos de equipos, documentar qué se ha instalado, cuándo y por qué, y ser capaces de demostrar en una auditoría que están al día con las actualizaciones de seguridad.

Ahí entra en juego el llamado software de gestión de parches, que automatiza buena parte del proceso. Estas herramientas suelen integrarse con los sistemas operativos más habituales (Windows, macOS, Linux) y se encargan de monitorizar los activos en busca de parches pendientes. Cuando detectan nuevas actualizaciones disponibles, pueden descargarlas y aplicarlas automáticamente, ya sea en tiempo real o siguiendo una ventana de mantenimiento programada.

Para optimizar el uso de ancho de banda, muchas soluciones de este tipo descargan los parches en un servidor central dentro de la red corporativa y desde ahí los distribuyen al resto de equipos. Además, suelen incorporar funciones adicionales como documentación automatizada de lo que se ha instalado, pruebas previas en grupos piloto y mecanismos de reversión por si una actualización provoca problemas.

Estas herramientas pueden funcionar como productos independientes o integradas dentro de plataformas de ciberseguridad más amplias. Por ejemplo, no es raro que una solución de gestión de vulnerabilidades o de gestión de superficie de ataque incluya módulos de inventario de activos y despliegue de parches. Igualmente, muchas soluciones EDR (detección y respuesta en endpoints) incorporan la capacidad de instalar actualizaciones de forma centralizada.

Algunas organizaciones optan por delegar todo este trabajo en un proveedor externo, mediante servicios gestionados (MSP), mientras que otras lo gestionan internamente con sus propios equipos. En cualquier caso, el objetivo es similar: reducir al mínimo el número de parches críticos que se quedan sin aplicar porque los usuarios “no encuentran el momento” de actualizar. Automatizar la detección, aprobación y aplicación de parches es clave para mantener un buen nivel de seguridad.

En este contexto, los parches dejan de ser solo pequeños archivos .patch ejecutados a mano y pasan a formar parte de estrategias de actualización y cumplimiento normativo mucho más complejas, donde cada cambio debe quedar registrado y trazable para futuras revisiones o auditorías.

Conviene no confundir los parches en el sentido de diff/patch con otros muchos usos del término “parche” que podemos encontrar en el día a día. Por ejemplo, en el mundo textil existen los parches termoadhesivos que se aplican con plancha, muy populares para personalizar ropa o reparar prendas sin necesidad de coser.

Estos parches físicos suelen utilizarse sobre prendas de algodón, poliéster o mezclas similares, evitando tejidos impermeables o demasiado delicados. Se colocan en la zona deseada, con la cara adhesiva en contacto con la tela, se protegen con un paño de algodón o papel de horno y se fijan aplicando calor con una plancha doméstica o una prensa térmica.

El proceso es conceptualmente parecido a “aplicar un parche” en informática: se superpone un añadido sobre un soporte existente (en un caso, código fuente o binarios; en el otro, la tela) para mejorar, corregir o reforzar algo. En los parches termoadhesivos, después de aplicar calor a temperatura alta sin vapor durante unos segundos, se deja enfriar y se comprueba si los bordes han quedado bien pegados. Si alguno se levanta, se puede repetir la operación.

Para que duren más, es habitual darles un pequeño refuerzo, ya sea cosiendo ligeramente los bordes o utilizando pegamento textil adicional. Además, se recomienda lavar la prenda del revés y evitar temperaturas excesivas (sobre todo en secadora), porque el adhesivo puede debilitarse.

En el lado del software ocurre algo similar: aplicar parches sin un mínimo de cuidado o sin comprobar el resultado puede dar lugar a errores, incompatibilidades o fallos de seguridad. Por eso, tanto en el ámbito técnico como en el textil, es buena idea seguir unas pautas claras y revisar el resultado en lugar de dar por hecho que todo ha salido bien a la primera.

Curiosamente, incluso en el mundo de los bordados personalizados se habla de “fabricar parches de calidad” y de elegir buenos materiales para que el resultado sea duradero. En software, el equivalente sería diseñar parches bien probados, documentados y fáciles de revertir en caso de que algo salga mal.

Mirando todo el panorama, desde el pequeño script en bash hasta los complejos sistemas de gestión automatizada de parches corporativos, queda claro que la idea de parchear es mucho más amplia de lo que parece: se trata, al fin y al cabo, de aplicar cambios controlados sobre algo que ya existe, manteniendo la estabilidad pero permitiendo que evolucione y mejore con el tiempo.