Linux에서 파일에 패치를 적용하고 패치를 생성하는 방법

Linux 패치 명령을 사용하면 한 파일 세트에서 다른 파일 세트로 변경 사항을 빠르고 안전하게 전송할 수 있습니다. 간단한 방법으로 패치를 사용하는 방법을 배웁니다.

patch 및 diff 명령

컴퓨터에 텍스트 파일이 있다고 상상해보십시오. 다른 사람으로부터 해당 텍스트 파일의 수정된 버전을 받습니다. 수정된 파일의 모든 변경 사항을 원본 파일로 어떻게 빠르게 전송합니까? 그것이 patch와 diff가 작동하는 곳입니다. patch 및 diff는 Linux 및 macOS와 같은 기타 Unix 계열 운영 체제에서 찾을 수 있습니다.

diff 명령은 다음을 검사합니다. 파일의 두 가지 다른 버전 그리고 그들 사이의 차이점을 나열합니다. 차이점은 패치 파일이라는 파일에 저장할 수 있습니다.

patch 명령은 패치 파일을 읽고 내용을 지침 세트로 사용할 수 있습니다. 이러한 지침을 따르면 수정된 파일의 변경 사항이 원본에서 복제 파일.

이제 이 프로세스가 텍스트 파일의 전체 디렉토리에서 발생한다고 상상해 보십시오. 한 번에. 그것이 바로 패치의 힘이다.

수정된 파일을 받지 못하는 경우가 있습니다. 전송되는 것은 패치 파일뿐입니다. 하나의 파일을 보낼 수 있는데도 수십 개의 파일을 번갈아 보내거나 쉽게 다운로드할 수 있도록 하나의 파일을 게시해야 하는 이유는 무엇입니까?

실제로 파일을 패치하기 위해 패치 파일로 무엇을 합니까? 거의 혀를 트위스트하는 것 외에도 좋은 질문입니다. 이 기사에서 이에 대해 안내해 드리겠습니다.

patch 명령은 소프트웨어 소스 코드 파일로 작업하는 사람들이 가장 자주 사용하지만 목적, 소스 코드 여부에 관계없이 모든 텍스트 파일 세트에서 똑같이 잘 작동합니다.

예제 시나리오

이 시나리오에서 우리는 두 개의 다른 디렉토리를 포함하는 work라는 디렉토리에 있습니다. 하나는 작업 중이고 다른 하나는 최신이라고 합니다. 작업 디렉토리에는 소스 코드 파일 세트가 있습니다. 최신 디렉토리에는 소스 코드 파일 중 일부가 수정된 최신 버전이 들어 있습니다.

안전을 위해 작업 디렉토리는 현재 버전의 텍스트 파일 복사본입니다. 그것들의 유일한 사본은 아닙니다.

파일의 두 버전 간의 차이점 찾기

diff 명령은 두 파일 간의 차이점을 찾습니다. 기본 동작은 터미널 창에 수정된 줄을 나열하는 것입니다.

한 파일은 slang.c라고 합니다. 작업 디렉토리의 버전을 최신 디렉토리의 버전과 비교할 것입니다.

-u(통합) 옵션은 diff가 변경된 각 섹션 전후의 수정되지 않은 일부 텍스트 행도 나열하도록 지시합니다. 이러한 라인을 컨텍스트 라인이라고 합니다. 패치 명령이 원본 파일에서 변경해야 하는 위치를 정확하게 찾는 데 도움이 됩니다.

diff가 비교할 파일을 알 수 있도록 파일 이름을 제공합니다. 원본 파일이 먼저 나열되고 수정된 파일이 나열됩니다. 이것은 우리가 diff를 위해 발행하는 명령입니다:

diff -u working/slang.c latest/slang.c

diff는 파일 간의 차이점을 보여주는 출력 목록을 생성합니다. 파일이 동일하면 출력이 전혀 나열되지 않습니다. diff에서 이러한 유형의 출력을 보면 두 파일 버전 간에 차이가 있고 원본 파일에 패치가 필요함을 확인할 수 있습니다.

패치 파일 만들기

패치 파일에서 이러한 차이점을 캡처하려면 다음 명령을 사용하십시오. diff의 출력이 slang.patch라는 파일로 리디렉션되는 위와 동일한 명령입니다.

diff -u working/slang.c latest/slang.c > slang.patch

모든 것이 잘되면 패치가 파일을 패치하고 있음을 알려주는 한 줄의 출력이 있습니다.

원본 파일의 백업 만들기

-b(백업) 옵션을 사용하여 패치가 변경되기 전에 패치된 파일의 백업 복사본을 만들도록 패치에 지시할 수 있습니다. -i(입력) 옵션은 사용할 패치 파일의 이름을 패치에 알려줍니다.

patch -u -b working.slang.c -i slang.patch

파일은 출력에 가시적인 차이 없이 이전과 같이 패치됩니다. 그러나 작업 폴더를 살펴보면 slang.c.orig라는 파일이 생성되었음을 알 수 있습니다. 파일의 날짜 및 시간 스탬프는 slang.c.orig가 원본 파일이고 slang.c가 패치에 의해 생성된 새 파일임을 보여줍니다.

디렉토리에 diff 사용하기

diff를 사용하여 두 디렉토리에 있는 파일 간의 모든 차이점을 포함하는 패치 파일을 생성할 수 있습니다. 그런 다음 패치와 함께 해당 패치 파일을 사용하여 단일 명령으로 작업 폴더의 파일에 이러한 차이점을 적용할 수 있습니다.

diff와 함께 사용할 옵션은 이전에 사용한 -u(통합 컨텍스트) 옵션, diff가 하위 디렉토리를 보도록 만드는 -r(재귀) 옵션 및 -N(새 파일) 옵션입니다.

-N 옵션은 diff에게 작업 디렉토리에 없는 최신 디렉토리의 파일을 처리하는 방법을 알려줍니다. diff가 패치 파일에 명령을 넣도록 강제하여 thatpatch가 최신 디렉토리에는 있지만 작업 디렉토리에는 없는 파일을 생성합니다.

단일 하이픈(-)을 사용하도록 옵션을 함께 묶을 수 있습니다.

우리는 디렉토리 이름만 제공할 뿐이며 특정 파일을 보도록 diff에 지시하지 않습니다.

diff -ruN working/ latest/ > slang.patch

패치 파일 내부 엿보기

패치 파일을 간단히 살펴보겠습니다. 내용을 보기 위해 less를 사용하겠습니다.

파일 상단은 slang.c의 두 버전 간의 차이점을 보여줍니다.

패치 파일을 더 아래로 스크롤하면 structs.h라는 다른 파일의 변경 사항을 설명하는 것을 볼 수 있습니다. 이것은 패치 파일에 여러 파일의 다른 버전 간의 차이점이 확실히 포함되어 있는지 확인합니다.

도약하기 전에 보세요

대규모 파일 컬렉션을 패치하는 것은 약간 불안할 수 있으므로 –dry-run 옵션을 사용하여 모든 것이 정상인지 확인하고 변경 사항을 적용하기로 결정합니다.

–dry-run 옵션은 실제로 파일을 수정하는 것 외에 모든 작업을 수행하도록 패치에 지시합니다. 패치는 파일에 대한 모든 비행 전 검사를 수행하고 문제가 발생하면 보고합니다. 어느 쪽이든 파일이 수정되지 않습니다.

문제가 보고되지 않으면 –dry-run 옵션 없이 명령을 반복하고 자신 있게 파일을 패치할 수 있습니다.

-d(디렉토리) 옵션은 패치에 작업할 디렉토리를 알려줍니다.

-i(입력) 옵션을 사용하여 diff의 지침이 포함된 패치 파일을 패치에 알리지 않습니다. 대신 패치 파일을 다음을 사용하여 패치로 리디렉션합니다. <. wp_automatic_readability="17.5">

patch --dry-run -ruN -d working 

Out of the entire directory, diff found two files to patch. The instructions regarding the modifications for those two files have been checked by patch , and no problems have been reported.
Pre-flight checks are OK; we’re ready for take-off.
Patching a Directory
To genuinely apply the patches to the files we use the previous command without the --dry-run option.
patch -ruN -d working 

This time each line of output doesn’t start with “checking,” each line starts with “patching.”
And no problems are reported. We can compile our source code, and we’ll be on the latest version of the software.
Settle Your Differences
This is by far the easiest and safest way to use  patch. Copy your target files to a folder and patch that folder. Copy them back when you’re happy that the patching process completed error free.