diff

위키百科, 우리 모두의 百科事典.

diff
原著者 더글라스 맥클로이
開發者 AT&T 벨 硏究所
發表日 1974年 6月 (49年 前) ( 1974-06 )
플랫폼 유닉스 , 유닉스 系列
種類 命令語

컴퓨터 에서 diff 는 두 個의 파일 間 差異에 對한 情報를 出力하는 파일 比較 유틸리티이다. 一般的으로 하나의 파일 버전과 同一한 파일의 다른 버전 間의 變更 事項을 보여주는 데 쓰인다. diff는 文書 파일의 줄 사이 變更 事項을 보여준다. 이 命令語로 만든 파일은 유닉스 系列 프로그램인 patch 命令語를 利用하여 出力물을 生成할 수 있다.

歷史 [ 編輯 ]

diff 유틸리티는 1970年代 初에 AT&T 벨 硏究所 와 倂合 中이던 유닉스 運營 體制 床에서 開發되었다. 最終 버전은 1974年의 유닉스 第5版에 더글라스 맥클로이 (Douglas McIlroy)가 完全히 다시 쓴 판이다.

알고리즘 [ 編輯 ]

diff 命令은 最長 共通 部分 水熱 問題를 解決하는 데 基盤을 둔다.

이 問題에서 다음과 같이 두 個의 項目이 있다고 假定하자.

       a
 b
 c
 d
 f
 g
 h 
j
 q 
z

       a b c d e f g i j k r x y z

여기서 共通이 되는 가장 긴 部分은 다음과 같다.

       a b c d f g j z

두 個의 項目을 比較하여 追加(+ 記號로 標示)되거나 削除(- 記號로 標示)되는 部分들은 다음과 같이 나타낸다.

       e   h i   q   k r x y
       +   - +   -   + + + +

使用法 [ 編輯 ]

命令 줄에 다음과 같이 두 個의 파일 이름을 指定한다.

diff [原本 파일 이름 또는 元本 디렉터리 이름] [새 파일 이름 또는 새 디렉터리 이름]

이는 原本 파일이 새 八日이 될 것임을 가리킨다. 디렉터리로 指定할 境遇 diff는 두 디렉터리에 存在하는 各 파일마다 差異點을 分析한다. -r 옵션을 利用하면 下部 디렉터리까지 檢索한다.

原本 파일과 새 파일의 內容이 다음과 같다고 假定하자.

  

原本 파일 :

1
  This part of the
2
  document has stayed the
3
  same from version to
4
  version.  It shouldn't
5
  be shown if it doesn't
6
  change.  Otherwise, that
7
  would not be helping to
8
  compress the size of the
9
  changes.
10

11
 This paragraph contains
12
 text that is outdated.
13
 It will be deleted in the
14
 near future.
15

16
 It is important to spell
17
 check this dokument. On
18
 the other hand, a
19
 misspelled word isn't
20
 the end of the world.
21
 Nothing in the rest of
22
 this paragraph needs to
23
 be changed. Things can
24
 be added after it.
  

새 파일 :

1
  This is an important
2
  notice! It should
3
  therefore be located at
4
  the beginning of this
5
  document!
6

7
  This part of the
8
  document has stayed the
9
  same from version to
10
 version.  It shouldn't
11
 be shown if it doesn't
12
 change.  Otherwise, that
13
 would not be helping to
14
 compress anything.
15

16
 It is important to spell
17
 check this document. On
18
 the other hand, a
19
 misspelled word isn't
20
 the end of the world.
21
 Nothing in the rest of
22
 this paragraph needs to
23
 be changed. Things can
24
 be added after it.
25

26
 This paragraph contains
27
 important new additions
28
 to this document.

이 境遇 diff 命令은 두 個 파일의 內容을 比較하여 다음과 같은 差異點을 만들어낸다.

0a1,6

> This is an important

> notice! It should

> therefore be located at

> the beginning of this

> document!

>
8,14c14

< compress the size of the

< changes.

<
< This paragraph contains

< text that is outdated.

< It will be deleted in the

< near future.

---

> compress anything.

17c17
< check this dokument. On

---

> check this document. On

24a25,28
>
> This paragraph contains

> important new additions

> to this document.

傳統的인 出力 方式에서 a added (追加)를 가리키고, d deleted (削除)를, 그리고 c changed (變更)을 가리킨다. 原本 파일의 줄 수는 a / d / c 앞에 나타나고, 修正되는 파일의 줄 수는 그 뒤에 나타난다.

基本的으로 두 個의 파일에 內容이 完全히 一致하는 줄은 나타나지 않는다. [1]

種類 [ 編輯 ]

1975年 以後로 核心 알고리즘의 改善, 命令語로의 有用한 機能 追加, 새로운 出力 포맷 設計 等이 變更 事項에 包含되었다.

編輯 스크립트 [ 編輯 ]

-e 옵션을 利用하면 현대 버전의 diff를 通해 編輯 스크립트 를 만들어낼 수 있다. 結果는 이를테면 다음과 같다:

 24a

 This paragraph contains
 important new additions
 to this document.
 .
 17c
 check this document. On
 .
 8,14c
 compress anything.
 .
 0a
 This is an important
 notice! It should
 therefore be located at
 the beginning of this
 document!

 .

文脈 形式 [ 編輯 ]

BSD 는 文脈 形式 (-c)을 追加하고 파일시스템 디렉터리 構造를 再歸的으로 探索하는 機能 (-r)을 1981年 7月에 2.8 BSD에 追加하여 出市하였다. 버클리가 導入한 diff의 環境 포맷은 些少하게 變更된 소스 코드의 패치를 配布하는 데 큰 도움이 되었다.

diff -c [原本 파일] [새 파일] 을 利用하면 다음과 같은 出力물을 만들어낸다:

*** /path/to/original ''timestamp''
--- /path/to/new ''timestamp''

***************
*** 1,3 ****
--- 1,9 ----

+ This is an important

+ notice! It should

+ therefore be located at

+ the beginning of this

+ document!

+

  This part of the
  document has stayed the
  same from version to
***************
*** 5,20 ****
  be shown if it doesn't
  change.  Otherwise, that
  would not be helping to
! compress the size of the

! changes.

!

! This paragraph contains

! text that is outdated.

! It will be deleted in the

! near future.


  It is important to spell
! check this dokument. On

  the other hand, a
  misspelled word isn't
  the end of the world.
--- 11,20 ----

  be shown if it doesn't
  change.  Otherwise, that
  would not be helping to
! compress anything.


  It is important to spell
! check this document. On

  the other hand, a
  misspelled word isn't
  the end of the world.
***************
*** 22,24 ****
--- 22,28 ----

  this paragraph needs to
  be changed. Things can
  be added after it.
+

+ This paragraph contains

+ important new additions

+ to this document.

統一 形式 [ 編輯 ]

統一 形式 ( unidiff )은 文脈 形式의 技術的 改善을 물려받았지만, 原本 텍스트와 새 텍스트가 서로 隣接하게 標示되는 더 작은 diff를 만든다. 統一 形式은 " -u " 옵션을 使用하여 利用할 수 있다. 이 出力은 patch 프로그램의 入力에 쓰인다. 많은 프로젝트에서 "diff"를 明確하게 統一 形式으로 提出하도록 하는데, 德分에 統一 形式은 소프트웨어 開發者 사이에서 패치를 주고받는 가장 普遍的인 形式이 되었다.

統一된 文脈의 diff는 1990年 8月 웨인 데이비슨 이 unidiff라는 이름으로 처음 開發하였다. 리처드 스톨만 이 1個月 뒤 GNU 프로젝트 의 diff 유틸리티에 統一 diff 支援을 追加하면서 1991年 1月 GNU diff 1.15에 이 機能이 들어갔다.

統一 形式은 文脈 形式과 비슷하게 두 줄의 헤더로 始作하는데, 原本 파일은 "---"로 始作하고 새 파일은 "+++"로 始作한다. 以後에 하나 또는 그 以上의 修正 덩어리(change hunks) 가 뒤따르는데, 파일 안에서 다른 部分을 담고 있다. 안바뀐 文脈的 前後 라인은 하나의 空白 文字로 始作하고, 追加된 라인은 하나의 "+"로 始作하고, 削除된 라인은 "-"로 始作한다.

하나의 덩어리는 範圍 情報(range information) 로 始作하고 以後에 곧바로 追加된 라인, 削除된 라인, 그리고 文脈的 前後 라인이 뒤따른다. 範圍 情報는 "@@" 로 둘러 쌓여 있고, 文脈 形式에서 두 줄에 걸쳐 表現하던 것을 한 줄로 합쳐서 表現한다. 範圍 情報 形式은 다음과 같다.

@@ -l,s +l,s @@ optional section heading

덩어리 範圍 情報 (hunk range information)은 두 個의 덩어리 範圍를 담고 있다. 原本 파일의 덩어리에 對한 範圍는 마이너스(-) 符號로 始作하고, 새 파일의 덩어리에 對한 範圍는 플러스(+) 符號로 始作한다. 各各의 덩어리 範圍는 l,s 形式을 따르는데, l 은 始作 라인 番號이고 s 는 修正 덩어리가 各各의 파일에 適用되는 라인의 個數이다. GNU diff의 많은 버전에서, 各各의 範圍 情報는 s 가 1일 때 콤마와 뒤에 오는 s 값을 省略할 수 있다. 여기서 가장 重要한 部分은 첫 番째 範圍의 l 값이다. 나머지 값은 diff로부터 計算해낼 수 있다.

原本에 對한 덩어리 範圍는 모든 文脈的/削除(變更 包含) 덩어리 라인의 合이어야 한다. 새 파일에 對한 덩어리 範圍는 모든 文脈的/追加(變更 包含) 덩어리 라인의 合이어야 한다. 萬若 덩어리 크기 情報가 덩어리 안의 라인의 個數랑 안맞으면, 그 diff는 有效하지 못한 것으로 判斷되어 拒絶된다.

덩어리 範圍 뒤에는 그 덩어리가 屬한 섹션 또는 函數의 이름이 올 수도 있다. 이러면 diff를 읽기가 쉬워진다. GNU diff로 diff를 만들 때는, 헤딩은 正規 表現式 에 依해 認識된다.

萬若 한 라인이 修正되었다면, 이 修正은 한 줄의 削除와 한 줄의 追加로 表現된다. 原本과 새 파일의 덩어리가 같은 덩어리에 나타나기 때문에, 이런 變更은 서로 隣接해서 나타난다. 다음 例示를 보면 안다.

-check this dokument. On

+check this document. On

diff -u [原本 파일] [새 파일] 을 利用하면 다음과 같은 出力물을 만들어낸다:

--- /path/to/original ''timestamp''

+++ /path/to/new ''timestamp''

@@ -1,3 +1,9 @@

+This is an important

+notice! It should

+therefore be located at

+the beginning of this

+document!

+

 This part of the
 document has stayed the
 same from version to
@@ -5,16 +11,10 @@

 be shown if it doesn't
 change.  Otherwise, that
 would not be helping to
-compress the size of the

-changes.

-

-This paragraph contains

-text that is outdated.

-It will be deleted in the

-near future.

+compress anything.


 It is important to spell
-check this dokument. On

+check this document. On

 the other hand, a
 misspelled word isn't
 the end of the world.
@@ -22,3 +22,7 @@

 this paragraph needs to
 be changed. Things can
 be added after it.
+

+This paragraph contains

+important new additions

+to this document.

여기서, diff 의 出力에 色깔이 漆해져 있으면 더 읽기 쉽다. diff 유틸리티 道具는 色이 있는 出力을 뱉진 않는다. 出力은 純粹한 텍스트다. 하지만, 많은 道具가 여기에 文法 强調를 통해 色깔을 漆해준다.

參考로 파일 이름과 타임 스탬프를 잘 區分하기 위해서 이 둘 사이에는 탭 文字가 구분자로 쓰이고 있다. 이것은 스크린 上에서는 安保이기 때문에 diff 結果를 콘솔/터미널 사이에서 複寫 붙여넣기 하다보면 잃어버릴 수도 있다.

統一 形式에 追加的인 修正이나 擴張을 통해 特定 文脈에서 特定 프로그램이 理解할 수 있도록 한 것도 있다. 例를 들어, 서브버전 과 같은 몇몇 버전 컨트롤 시스템은 버전, "作業中인 카피(working copy)", 또는 diff의 헤더 섹션에 追加的인 코멘트를 明示하기도 한다.

몇몇 道具는 서로 다른 여러 個의 파일에 對한 diff를 하나로 합치는 것을 許容하기도 하는데, 修正된 各各의 파일에 對해서 다음과 같은 헤더를 使用한다.

Index: path/to/file.cpp

줄바꿈 文字로 끝나지 않는 파일의 특별한 境遇는 處理되지 않는다. unidiff 유틸리티 道具 뿐만 아니라 POSIX diff 標準에서도 이러한 類型의 파일을 處理하는 方法을 定義하고 있지 않다. (事實, 이런 파일은 嚴密한 POSIX 定義에 依하면 "텍스트" 파일조차 아니다.)

기타 [ 編輯 ]

이 밖에도 sdiff과 diffmk가 存在한다.

各州 [ 編輯 ]

  1. David MacKenzie; Paul Eggert; Richard Stallman (1997). 《 Comparing and Merging Files with GNU Diff and Patch 》. Bristol: Network Theory. ISBN   0-9541617-5-0 .   |title= 에 外部 링크가 있음 ( 도움말 )
  • Paul Heckel (1978). “A technique for isolating differences between files”. 《Communications of the ACM》 21 (4): 264?268. doi : 10.1145/359460.359467 .   [1]
  • A generic implementation of the Myers SES/LCS algorithm with the Hirschberg linear space refinement (C source code)

自由 파일 比較 道具 [ 編輯 ]

같이 보기 [ 編輯 ]

外部 링크 [ 編輯 ]