아래 그림 한장으로 개념 끝


'개발자 기본 소양' 카테고리의 다른 글

GIT 개념도  (0) 2013.01.11
spi i2c 개요  (0) 2012.09.20
diff 로 두 디렉토리 파일 비교  (0) 2012.05.23
디스크와 파일 시스템  (0) 2012.05.08
SWAP  (0) 2012.04.30
오픈소스 라이센스 비교  (0) 2012.04.11

spi i2c 개요



'개발자 기본 소양' 카테고리의 다른 글

GIT 개념도  (0) 2013.01.11
spi i2c 개요  (0) 2012.09.20
diff 로 두 디렉토리 파일 비교  (0) 2012.05.23
디스크와 파일 시스템  (0) 2012.05.08
SWAP  (0) 2012.04.30
오픈소스 라이센스 비교  (0) 2012.04.11

출처 : http://blog.naver.com/johnforstar/30113040636

diff 명령어를 사용할 때 아무 옵션도 주지 않고 두 디렉토리를 비교하게 되면, 두 디렉토리에 어떤 파일만 있는지 혹은 어떤 디렉토리만 있는지, 어떤 디렉토리가 공통인지 에 대해서만 알려준다.

그래서 두 디렉토리의 어떤 파일들이 서로 다른지 알고 싶을 경우에는 -r 옵션을 주어서 전체 디렉토리 트리를 재귀적으로 탐색하면서 비교할 필요가 있다.  그리고 -q 옵션을 주어서 다른 파일들을 line by line 으로 비교하는 것을 없애주면 더욱더 보기 좋게 된다.


여기서 추가적으로 | 를 사용하여 sort 를 하게 되면 다른 것들이 알파벳 순서로 정렬이 되어서 출력이 되어 보기가 훨씬 수월해 진다.

간단한 팁 같지만 여러모로 쓰기에 유용한 팁 같아서 따로 글로 남겨둔다. :)


 $ diff -rq dir1 dir2 | sort


다른 예제: dir1, dir2 의 다른 파일들중에서 "some_text" 가 들어가 있는 파일들을 알파벳 순서로 정렬한 뒤, 목록을 diff.txt 파일로 저장한다.

 $ diff -rq dir1 dir2 | grep "some_text" | sort > diff.txt

나 같으면 소스 상에 .git들이 있어서 차이가 나서 제외하고 싶었다. 그럴땐 -exclude 옵션을 쓰면 된다.

 $ diff -rq --exclude=.git /home/test/android android /home/sync/android


'개발자 기본 소양' 카테고리의 다른 글

GIT 개념도  (0) 2013.01.11
spi i2c 개요  (0) 2012.09.20
diff 로 두 디렉토리 파일 비교  (0) 2012.05.23
디스크와 파일 시스템  (0) 2012.05.08
SWAP  (0) 2012.04.30
오픈소스 라이센스 비교  (0) 2012.04.11

원문 : http://powerwin.tistory.com/237


디스크와 파일 시스템의 기초

    [디스크 정보] 디스크와 파티션 관리하기

    [디스크 정보] 디스크의 종류와 용어 1 장 - 디스크, 파티션, 볼륨, 드라이브
    [디스크 정보] 디스크의 종류와 용어 2 장 - MBR 디스크와 GPT 디스크
    [디스크 정보] 디스크의 종류와 용어 3 장 - 활성, 시스템, 부팅, 페이지 파일, 크래시 덤프
       ├ 활성 파티션에 대한 좀 더 자세한 이야기 - 활성 파티션의 개념과 특성 정리 -
       ├ MBR 의 구조와 활성 파티션, 활성 파티션은 어덯게 설정 되는가?
       └ 활성 파티션은 반드시 하나만 존재할 수 있는가?
    [디스크 정보] 디스크의 종류와 용어 4 장 - 레이드 그리고 동적 디스크
    [디스크 정보] 디스크의 종류와 용어 5 장 - 가상 디스크

    [디스크 정보] 파일 시스템과 포맷 1 장 - 파일 시스템과 포맷
    [디스크 정보] 파일 시스템과 포맷 2 장 - 일반 포맷과 빠른 포맷
    [디스크 정보] 파일 시스템과 포맷 3 장 - 섹터와 클러스터

    [디스크 정보] 파티션 개수의 한계
    [디스크 정보] '메가, 기가, 테라, 페타...' 저장 용량의 단위
    [디스크 정보] 시스템 예약 파티션 : 비트락커와 이를 위한 분할 로드(split-Load) 구성의 등장



윈도우 7 - 디스크 관리의 기본

    [디스크 관리] 윈도우 디스크 관리의 시작 - 디스크 관리 시작하기
    [디스크 관리, DiskPart] '팩 이름이 잘못되었습니다' 에러 해결법

    [디스크 관리] 디스크 초기화 - 새로운 디스크의 인식과 기본 디스크로의 초기화
    [디스크 관리] 파티션 생성하기 - 새로운 파티션의 생성
    [디스크 관리] 파티션 확장하기 - 공간이 부족한 파티션의 크기를 확장하는 방법
    [디스크 관리] 파티션 축소하기 - 너무 큰 파티션의 크기를 축소하는 방법
    [디스크 관리] 파티션 삭제하기 - 필요 없어진 파티션을 삭제하는 방법
    [디스크 관리] 파티션 활성화하기 - 파티션을 활성화하는 방법

    [디스크 관리] 가상 디스크의 생성과 관리 - VHD 의 생성과 연결

    [디스크 관리] 파티션(볼륨)을 나타내는 이름 - 드라이브 문자의 관리
    [디스크 관리] 파티션(볼륨)에 접근하는 다른 방법 - 드라이브 경로의 관리
    [디스크 관리, 윈도우 7] 파티션(볼륨)에 예쁜 꼬리표를 - 볼륨 레이블의 관리
    [디스크 관리, 윈도우 7, Format] 파티션(볼륨) 포맷하기
 
 

윈도우 7 - 본격적인 디스크의 관리

    [DiskPart] 좀 더 강력하게 디스크를 관리한다 - DiskPart 시작하기
    [DiskPart] 목록을 확인하고 작업할 대상을 선택하는 방법 - List, Select


    [DiskPart] 새로운 파티션의 생성과 파티션 생성에 관한 이야기들 - Create Partition
    [DiskPart] 파티션의 크기 확장하기 - Extend
    [DiskPart] 파티션의 크기 축소하기 - Shrink
    [DiskPart] 파티션을 활성화하기(비활성화하기) - Active, Inactive
    [DiskPart] 필요없는 파티션을 삭제하기 - Delete Partition, Delete Volume
      └ 아차! 실수로 파티션을 삭제하였다면? - 삭제된 파티션을 복구하는 방법

    [DiskPart] 드라이브 문자와 드라이브 경로의 관리 - Assign, Remove
      ├ 왜? 드라이브 문자를 변경할 수 없나요?
      ├ 레지스트리를 통해 강제로 드라이브 문자 변경하기
      └ 레지스트리를 통해 노출을 원치 않는 드라이브를 탐색기에서 숨기고 접근을 막기



디스크를 관리하다 보면 생길 수 있는 의문들

   왜? 드라이브 문자를 변경할 수 없나요?



추가 정보 및 문제 해결

  [Convert] FAT32 파일 시스템을 NTFS 파일 시스템으로 변환하기 
  윈도우 XP 에서 exFAT 파일 시스템 사용하기
  레지스트리를 통해 강제로 드라이브 문자 변경하기
  레지스트리를 통해 노출을 원치 않는 드라이브를 탐색기에서 숨기고 접근을 막기
  디스크 서명(Disk Signature)이란?
  디스크 서명 충돌 문제 해결하기

  잘못 나눠진 파티션의 예제 (1) - 타 커뮤니티 질문

'개발자 기본 소양' 카테고리의 다른 글

spi i2c 개요  (0) 2012.09.20
diff 로 두 디렉토리 파일 비교  (0) 2012.05.23
디스크와 파일 시스템  (0) 2012.05.08
SWAP  (0) 2012.04.30
오픈소스 라이센스 비교  (0) 2012.04.11
VIM을 사용하자  (0) 2011.03.16
SWAP 개발자 기본 소양 2012.04.30 09:28

출처 : http://blog.nextcube.pe.kr/entry/mkswap-%EA%B3%BC-swapon-swapoff-%EB%AA%85%EB%A0%B9%EC%96%B4

1. swap ?
swap 이란 하드디스크를 메모리처럼 사용하는 기법
물리적인 메모리가 모자라면 하드디스크를 메모리처럼 데이터를 기록하여 메모리를 확보
프로그램들을 많이 실행해서 메모리가 부족해지면, 메모리 상에 적재된 프로그램 중 지금 당장 필요하지 않은 프로그램 데이터를 하드디스크에 옮겨서 메모리 공간을 확보

2. mkswap
swap 파티션이나 swap 파일을 생성하는 명령어

사용

mkswap [option] swapfile or swappartition [size]

옵션
-c : swap 파티션 생성시 사용

예문
10240K 사이즈의 /swap_file 생성
mkswap /swap_file 10240

dd 명령으로 swap 파일로 사용할 파일을 용량이 넉넉한 파티션에 생성 후
mkswap 명령으로 해당 파일을 swap 파티션으로 만들어준다.

3. swapon
swap 파티션이나 swap 파일을 구동하는 명령어

사용
swapon [option] swapfile or swappartition

옵션
-a : /etc/fstab 에 있는 swap 을 모두 활성화
-s : swap 파티션의 상태를 보여줌

예문
/etc/fstab 에 있는 swap 을 모두 활성화
swapon -a


4. swapoff
swap 파티션이나 swap 파일의 구동을 중단시키는 명령어

사용
swapoff swapfile or swappartition

예문
swapoff /swap_file


Chapter 5. 메모리 관리

여기서는 리눅스 메모리 관리에 대하여 설명한다. 즉, 가상 메모리와 디스크 버퍼 캐쉬와 같은 내용에 대해 다룬다. 그리고 메모리 관리가 필요한 이유와 그에 필요한 작업들, 그밖에 시스템 관리자로서 관심을 가져야 할 여러 주제들을 설명할 것이다.

가상 메모리란?

리눅스는 가상 메모리(virtual memory)란 것을 지원한다. 이것은 메모리 사용량이 늘어남에 따라, 디스크의 일부를 마치 확장된 RAM처럼 사용할 수 있게 해주는 기술이다. 이 기술에 따르면, 커널은 실제 메모리(RAM)에 올라와 있는 메모리 블록들 중에 당장 쓰이지 않는 것을 디스크에 저장하는데, 이를 통해 사용가능한 메모리 영역을 훨씬 늘릴 수 있게 된다. 만일 디스크에 저장되었던 메모리 블록이 다시 필요하게 되면 그것은 다시 실제 메모리 안으로 올려지며, 대신 다른 블록이 디스크로 내려가게 된다. 그러나 이런 과정이 일어나고 있다는 것이 사용자에게는 전혀 보이지 않으며, 프로그램들에게도 그저 많은 양의 메모리가 있는 것처럼 보일 뿐이어서, 점유하고 있는 메모리가 디스크에 있는지 실제 메모리에 있는지 전혀 신경쓸 필요가 없게 된다. 그러나, 하드디스크를 읽고 쓰는 시간은 RAM보다 훨씬 느리기 때문에(보통 천배쯤 느리다), 프로그램의 실행은 그만큼 더디게 된다. 이렇듯 가상적인 메모리로 쓰이는 하드디스크의 영역을 `스왑 영역(swap space)'이라고 한다(swap은 바꿔치기를 한다는 뜻).

리눅스는 스왑 영역으로 일반적인 파일을 사용할 수도 있고 별도의 스왑을 위한 파티션을 사용할 수도 있다. 스왑 파티션은 속도가 빠른 반면에, 스왑 파일은 그 크기를 자유롭게 조절할 수 있다(또한 스왑 파일을 사용하면, 리눅스 설치시에 파티션을 다시 해야 할 필요없이 모든 것을 그냥 설치할 수 있다). 스왑 영역이 얼마나 많이 필요한지를 미리 알고 있다면 그만큼 스왑 파티션을 잡으면 된다. 그러나 스왑 영역이 얼마나 필요할지 확실히 모른다면, 우선 스왑 파일을 사용해서 시스템을 가동해 보고 필요한 공간이 얼마인지 파악한 후에 스왑 파티션을 잡도록 하자.

또한 리눅스에서는 여러개의 스왑 파티션과 스왑 파일을 섞어서 사용할 수 있다. 이 방법을 이용하면, 언제나 큰 용량의 스왑 영역을 잡을 필요없이 그때 그때 필요한 만큼만 스왑을 늘려줄 수 있으므로 편리하다.

운영체제 용어에 관한 이야기 : 컴퓨터 과학에서는 스와핑(해당 프로세스 전체를 스왑 영역으로 내보냄)과 페이징(몇 킬로바이트의 작은 단위로 내보냄)을 구별하는 것이 일반적이다. 이 중에서 페이징이 좀더 효율적인 방법이며, 리눅스에서도 이 방법을 쓴다. 그러나 전통적인 리눅스 용어로는 이 두가지를 모두 뭉뚱그려서 스와핑이라고 흔히 불러왔다.


스왑 공간 생성하기

스왑 파일은 평범한 파일이다. 즉, 커널이 보기엔 일반 파일과 다를 바가 없다. 다만 다른 점이라면 스왑 파일에는 빈틈(holes)이 없으며, mkswap과 함께 사용하게 되어 있다는 점 정도이다. 그리고 스왑 파일은 꼭 자신의 파일시스템(local filesystem)에 있어야 하며, NFS를 통해 마운트된 파일시스템에 있어선 안 된다.

스왑 파일 안에 홀(hole)이 없어야 한다는 점은 중요하다. 스왑 파일은 디스크의 일부를 미리 점유하고 있는데, 이렇게 하면 디스크 섹터를 일일이 할당하는 과정을 거치지 않고서도 메모리 페이지를 파일로 빠르게 스왑시킬 수 있다. 즉, 커널은 파일에 미리 할당되어 있는 섹터를 곧바로 사용하기만 하면 되는 것이다. 스왑 파일 안에 빈틈이 있다는 것은 아무 섹터도 할당되지 않은 공간이 파일 안에 있다는 뜻인데, 이렇게 되면 커널이 스왑을 사용하는데 곤란을 겪게 된다.

홀이 없는 스왑 파일을 생성하기 위한 좋은 방법은 다음과 같다.

$ dd if=/dev/zero of=/extra-swap bs=1024 count=1024
1024+0 records in
1024+0 records out
$
위에서 /extra-swap이란 것은 스왑 파일의 이름이며, bs= 뒤에 오는 숫자는 입출력 단위의 크기를 지정한 것이고(1024 byte, 즉 1 kilobyte), count= 뒤의 숫자는 입출력 단위의 몇배 크기의 파일을 만들 것인지를 지정하기 위한 것이다(즉, 여기서는 1024 kilobyte 크기의 파일을 만든 것이 되겠다). count는 꼭 4의 배수로 지정해 주는 것이 좋은데, 그 이유는 커널이 스왑하는 메모리 페이지(memory page)의 단위가 4 kilobyte이기 때문이다. 만일 파일의 크기를 4 kilobyte의 배수로 하지 않는다면, 파일 끝에 남는 몇 킬로바이트는 아예 사용되지 않을 것이다.

스왑 파티션도 사실 특별한 것은 없다. 만드는 것도 다른 보통 파티션과 다를 것이 없지만, 특별한 점이라면 스왑파티션에는 어떤 파일시스템도 사용되지 않으며 날것(raw partition) 그대로 쓴다는 점이다. 스왑용으로 쓸 파티션은 type 82로 지정해 두는 것이 좋은데, 이렇게 해두면 파티션의 용도가 명확해진다. 그러나 사실 커널은 이런 것에 그다지 구애받진 않는다.

스왑 파일이나 스왑 파티션을 만들고 나면, 그 앞부분에 일종의 인식표를 달아두어야 한다. 여기에는 커널이 사용하는 몇가지 정보가 위치하게 된다. 이것을 해주는 명령어는mkswap인데, 다음과 같이 쓰인다.

$ mkswap /extra-swap 1024
Setting up swapspace, size = 1044480 bytes
$
이렇게 했다고 해서 이 스왑 공간을 사용하게 된 것은 아니다. 다만 커널이 이것을 가상 메모리로 사용할 수 있도록 준비만 마친 것이다.

mkswap 명령은 사용에 주의가 필요하다. 이 명령은 파일이나 파티션이 사용 중인지 아닌지를 판별해 주지 않기 때문이다. 따라서 mkswap을 부주의하게 사용하면 중요한 파일과 파티션을 간단히 날려버릴 수 있다! 그러나 다행히도, mkswap 명령은 주로 시스템 설치시에만 사용된다는 점이 우리를 안심시켜 주긴 한다.

리눅스의 메모리 관리자는 각각의 스왑 공간의 크기를 약 127MB로 제한하고 있다(몇가지 기술적인 이유로 인해 실제 한계치는 (4096-10) * 8 * 4096 = 133890048 bytes 즉 127.6875 megabytes이다). 대신, 최대 8개의 스왑 공간을 연결해 사용하면 스왑을 대략 1GB까지 확장할 수가 있다. [1]


스왑 공간 사용하기

스왑 공간을 초기화하는 데는 swapon 명령을 사용한다. 이 명령은 커널에게 해당 공간을 스왑으로 사용할 수 있다는 점을 알려준다. 이 명령에게는 추가하고자 하는 스왑 공간의 경로를 인수로 전달해 주어야 한다. 임시 스왑 파일을 스왑 공간에 추가하고자 한다면 다음과 같이 한다.

$ swapon /extra-swap
$
스왑 공간들은 /etc/fstab 파일에 의해서 자동적으로 사용될 수도 있다.
/dev/hda8        none        swap        sw     0     0
/swapfile        none        swap        sw     0     0
시스템이 시작될 때, 스크립트를 통해서 swapon -a 명령이 실행되는데 이 명령은 /etc/fstab에 나열되어 있는 스왑 공간들을 모두 사용하게 해 준다. 그래서 흔히 swapon 명령은 추가적인 스왑이 필요할 때만 사용되는 것이 보통이다.

free 명령을 쓰면 스왑의 사용 상황을 모니터 할 수 있다. 이것은 현재 얼마나 많은 용량의 스왑이 사용되고 있는지 알려준다.

$ free
             total       used       free     shared    buffers
Mem:         15152      14896        256      12404       2528
-/+ buffers:            12368       2784
Swap:        32452       6684      25768
$
여기서 Mem: 이라고 쓰여진 첫째줄은 실제 물리적 메모리의 상황을 보여주는 것이다.커널은 물리적 메모리를 약 1 megabyte 정도 사용하는데, total이라고 쓰여진 세로줄에서 보여주는 전체메모리 양에는 이 커널이 차지하는 공간이 빠져 있다. used라는 세로줄은 현재 사용중인 메모리 양을 보여주고 있으며(두번째 가로줄은 버퍼 로 사용되는 부분을 제외하고 계산한 양이다), free란 세로줄에서는 전혀 사용되지 않은 양을 보여주고 있다. 또한 shared란 부분은 프로세스간에 공유되고 있는 메모리를 나타내고 있는 것이므로, 그 양이 많은 것은 기쁜 일이다. buffers는 현재 디스크 버퍼 캐쉬로 사용되는 메모리 양을 보여주고 있다.

마지막 줄인 Swap:은 위와 같은 항목을 스왑 공간에 똑같이 적용시킨 내용이다. 이 항목이 모두 제로라면, 스왑 공간이 아예 동작하고 있지 않다는 뜻이다.

같은 정보를 top 명령이나 /proc/meminfo 파일을 통해 얻을 수 있다. 그러나 어느 경우든, 특정한 스왑 공간에 대한 정보를 얻는 것은 좀 어렵다.

스왑 공간은 swapoff 명령으로 기능을 멎게 할 수 있다. 그러나 임시로 잡은 스왑 공간이 아니라면, 스왑을 끌 필요는 없다. 만약 스왑을 끄게되면, 스왑 공간에 들어있던 메모리 페이지들이 먼저 실제 메모리로 들어가야 되는데, 실제 메모리에 여유가 없는 경우에는 또 다른 스왑 공간으로 방출되게 된다. 그런데 이 메모리 페이지들을 모두 수용하기에 가상메모리마저도 부족하다면, 그때부터는 리눅스 시스템이 무진장 버벅대기 시작할 것이다. 시간이 아주 많이 걸린 후에는 좀 잠잠해지겠지만, 여전히 시스템은 사용불능 상태에 있게 된다. 따라서 스왑을 끄기 전에, 충분한 여유 메모리가 있는지 꼭 확인해 보아야만 한다(free 같은 것으로).

swapon -a 명령으로 자동적으로 사용되는 스왑 공간들은, 마찬가지로 swapoff -a 명령을 써서 끌 수 있다. 이것도 역시 /etc/fstab 파일에 나열되어 있는 스왑 공간만을 끄기 때문에, 나머지 수동으로 추가시킨 스왑들은 영향을 받지 않는다.

때때로, 실제 메모리가 많이 비어 있는데도 불구하고 스왑을 아주 많이 쓰고 있는 경우를 보게 될 수가 있다. 보통 이런 일이 발생하는 경우는 이렇다. 어떤 덩치 큰 프로세스가 실제 메모리를 많이 점유하는 바람에 시스템이 스왑을 많이 사용하게 되었다고 하자. 이 프로세스가 종료되면 실제 메모리엔 여유 공간이 많이 남게 되지만, 스왑으로 한번 내려간 데이터는 그것이 당장 필요하지 않는 한 실제 메모리로 불려지지 않는다. 따라서 스왑 영역을 많이 사용하면서도 실제 메모리가 많이 비어있는 현상이 꽤 오래 지속될 수 있는 것이다. 그러므로 이런 현상에 특별히 신경쓸 필요는 없다. 하지만, 최소한 그 원리는 이해하고 있어야 나중에 불안하지 않을 것이다.


다른 운영체제와 스왑 공간을 공유하기

가상 메모리 기술은 이미 많은 운영체제에 내장되어 있다. 그런데, 운영체제는 단지 그것이 실행 중일 때만 스왑을 필요로 한다. 따라서 한 컴퓨터에서 다양한 운영체제를 사용한다면, 각각의 운영체제마다 따로 스왑 공간을 마련해 주는 것은 낭비일 것이다. 실제로 서로 다른 운영체제가 스왑 공간을 공유하는 것이 가능한데, 다만 그렇게 하기 위해서는 조금의 해킹이 필요하다. 실제로 이것을 어떻게 구현할 수 있는가에 대한 정보는 각종 Tip이나 HOWTO를 참고하기 바란다.

스왑 공간 할당하기

보통, 스왑 공간을 잡을 때는 그 크기를 물리적인 메모리의 두 배 정도로 하는 것이 적당하다고 말하는 사람들이 많은데, 사실 이것은 좀 근거없는 이야기이다. 여기서 좀더 합리적인 방법을 알아보도록 하자.

  • 우선, 필요한 메모리의 총량을 어림잡아 본다. 필요한 메모리의 총량이라는 것은, 한순간에 필요한 메모리의 최대 크기, 즉 한꺼번에 돌리고 싶은 모든 프로그램들이 필요로 하는 메모리의 총량을 말하는 것이다. 실제로 원하는 모든 프로그램을 한번에 다 띄워놓는다면 바로 이런 상태를 만들 수 있다.

    예를 들어, X를 띄우고 싶다면 여기엔 대략 8MB 정도의 메모리 할당이 필요하다. gcc를 돌리고 싶다면 보통 4MB 정도가 필요하지만, 특별히 큰 프로그램을 컴파일한다면 아마 수십 메가바이트 이상이 필요할 것이다. 또한 커널은 그 자체가 대략 1MB 정도 차지하며, 일반적인 쉘들과 작은 유틸리티들은 각각 수백 킬로바이트 정도 잡아먹는다(다 합치면 1 메가 정도 될 것이다). 이런 어림짐작들이 꼭 정확해야 할 필요는 없지만, 좀 더 비관적인 태도로 계산해 볼 필요는 있다.

    한가지 명심할 것은, 만약 같은 프로그램을 동시에 돌리고 있는 여러 사람이 있다면, 이들도 모두 각각 메모리를 잡아먹는다는 점이다. 다만, 예를 들어, 같은 프로그램을 두사람이 돌린다고 했을 때 그 메모리 점유량이 원래의 꼭 두배가 되는 것은 아닌데, 왜냐면 프로그램의 실행 코드와 공유 라이브러리들은 메모리에 한벌씩만 올려두고 공유해 사용할 수 있기 때문이다.

    free와 ps 명령을 적절히 사용하면 메모리 필요량을 알아보는 데 유용하다.

  • 이제, 앞에서 나온 값에다 안전보장용 여유분을 좀 더하자. 이렇게 하는 이유로서는, 우선 프로그램의 크기 계산이 틀렸을 수도 있고, 또한 실행하고자 하는 프로그램을 몇개 빠뜨렸을 수도 있기 때문이다. 이런 경우를 대비하여 좀 여유 공간을 두어야 하는데, 필요하다고 계산된 크기의 10% 정도를 여유로 잡아두면 충분할 것이다.(스왑을 너무 적게 잡는 것보다는 너무 많이 잡는 것이 낫지만, 그래도 지나치게 많은 양을 스왑으로 잡는 것은 낭비일 뿐이다. 스왑이 더 필요하다면 나중에 추가할 수도 있다.) 이렇게 필요한 크기가 계산되었으면, 편의를 위해 반올림을 해서 메가바이트 단위로 만들자.

  • 위의 계산에 근거하면, 총 얼마 정도의 메모리가 필요한지 파악이 될 것이다. 이제, 필요한 스왑 공간을 계산하기 위하여, 총 필요 메모리량에서 실제 물리적 메모리량을 빼자.(어떤 UNIX 버전에서는, 실제 물리적 메모리의 이미지를 위한 공간까지 스왑에 포함시켜주어야 한다. 이런 경우에는 위의 두번째 단계에서 산출된 필요 메모리 크기 전부를 스왑 공간으로 할당해야 하며, 빼기를 해서는 안된다.)

  • 만일 산출된 스왑 공간이 실제 메모리의 두배를 넘는다먼, 실제 메모리를 좀 더 확충하는 방안을 고려해 보자. 그러지 않는다면 시스템이 아주 기어가게 될 것이다.

계산 결과 스왑 공간이 전혀 필요없다고 해도, 약간의 스왑을 잡아두는 것이 좋다. 리눅스는 메모리에 될 수 있는 대로 많은 여유공간을 확보하려 하는데, 이를 위해 스왑을 아주 적극적으로 사용한다. 즉, 실제 메모리에 여유가 많이 있다 하더라도, 사용되지 않고 있는 메모리 페이지가 있다면 그 부분은 스왑 영역으로 내려진다. 이처럼 디스크가 쉬고 있을 때 미리 스왑을 해두기 때문에, 스왑으로 인한 지연 시간을 많이 줄일 수 있다.

또한 스왑 공간은 여러개의 디스크에 나누어져 있을 수도 있는데, 이렇게 하면, 디스크의 속도와 그 액세스 방식에 따라서 스왑 성능이 향상되기도 한다. 그 밖에도 여러 방식이 있을 수 있으므로 그것을 시험해 보고 싶겠지만, 보통 그런 방식들은 제대로 시험해 보기가 쉽지 않다. 특히, `어떤 방식이 다른 것보다 훨씬 월등하다'는 식의 말은 절대로 믿지 마라. 그런 것들은 거의 언제나 사실이 아니다.


버퍼 캐쉬

디스크를 읽는 일은 (진짜) 메모리를 읽는 것보다 아주 느리다. [1] 더구나, 디스크의 동일한 영역을 짧은 시간 동안 반복해서 계속 읽는 일은 아주 빈번하다. 예를 들어, 누군가 e-mail 메시지를 읽고, 답장을 하기 위해 편집기로 불러들이고, 그걸 보내기 위해 메일프로그램에게 다시 읽게 하는 과정을 생각해 보자. 또한 ls 명령어 같은 것을 시스템의 모든 사용자들이 얼마나 자주 사용할지 생각해 보자. 따라서, 디스크로부터 한번 읽어들인 정보를 메모리에 상당시간 보관한다면, 첫번째로 읽을 때만 시간이 좀 걸릴 뿐 속도가 전반적으로 빨라질 것이다. 바로 이런 것을 가리켜 디스크 버퍼링(disk buffering)이라고 하며, 이런 목적으로 쓰이는 메모리를 버퍼 캐쉬(buffer cache)라고 부른다.

그러나 메모리는 아쉽게도 한정된, 아니, 아주 귀중한 자원이기 때문에, 버퍼 캐쉬는 보통 큰 크기를 가질 수 없다(즉, 우리에게 필요한 모든 데이터를 담아둘 수 있을 정도로 크지는 않다). 따라서, 캐쉬가 다 차게 되면 오랫동안 쓰이지 않은 데이터는 버려지며 그 빈 공간을 새로운 데이터가 메우게 된다.

이런 디스크 버퍼링은 쓰기에도 똑같이 적용된다. 보통, 데이터들은 쓰여지자 마자 또 곧바로 다시 읽어들여지므로(예를 들어, 소스 코드 파일은 일단 파일로 저장된 후, 컴파일러에 의해 다시 읽어들여진다), 이런 데이터들을 캐쉬에 넣어둔다면 확실히 효율적일 것이다. 또한, 쓰기 작업을 디스크에 즉시 하지 않고 캐쉬에 넣어두면, 프로그램들이 그만큼 출력을 빨리 끝낼 수 있기 때문에 전반적인 시스템 성능향상에도 도움이 된다.

대부분의 운영체제들이 버퍼 캐쉬를 갖고 있긴 하지만(좀 다른 이름으로 불릴 수도 있다), 모두가 위와 같은 원리로 동작하는 것은 아니다. 한가지 방법은 write-through라는 것인데, 이 방법은 쓰기를 할 때면 언제나 디스크에도 즉시 기록하는 것이다(물론 캐쉬에도 남겨둔다). 또 다른 방법은 write-back이라 불리는 것으로, 쓰기를 일단 캐쉬에 해 두었다가 나중에 한꺼번에 디스크에 기록하는 방식이다. 효율적이기는 write-back 방식이 뛰어나지만, 대신 약간의 에러가 발생할 소지가 있다. 즉, 시스템이 갑자기 멈춰버린다거나, 전원이 갑자기 나가버린다면, 또는 캐쉬 내용을 미처 써 넣기 전에 플로피를 빼 버린다면, 캐쉬에 담겨 있던 내용들은 고스란히 날아가 버리고 만다. 특히, 손실된 정보가 파일시스템 유지에 필요한 중요 데이터였다면, 자칫 전체 파일시스템을 망가뜨리고 마는 결과를 초래할 수도 있다.

이렇기 때문에, 컴퓨터를 끄기 전엔 반드시 적절한 셧다운 절차를 밟아야만 하는 것이고(Chapter 6 참조), 마운트한 플로피를 빼기 전엔 꼭 언마운트를 해야하는 것이다. 한편, 캐쉬를 디스크로 내보내기(flush) 위한 명령으로 sync가 있는데, 이 명령을 쓰면 아직 기록되지 않고 캐쉬에 남아있는 데이터들을 모두 디스크에 써넣게 되므로, 모든 내용이 안전하게 기록되었다는 점을 보장받을 수가 있다. 또한 전통적인 UNIX에는 update란 백그라운드 프로그램이 있어서, sync가 해주는 것과 같은 일을 30초에 한번씩 자동으로 해준다. 그러므로 사실 sync를 별로 사용할 필요는 없는 없는 셈이다. 특히, 리눅스에는 추가적인 데몬으로 bdflush란 것이 있는데, 이 것은 sync에 비해선 상당히 불충분하게flush 작업을 하지만 대신 좀더 자주 실행하도록 되어 있다. 이런 방식이 고안된 이유는, sync가 디스크 입출력을 순간적으로 과도하게 일으키면서 시스템이 멈춰버리는 현상이 종종 있어 왔기 때문이다.

리눅스에서는, update에 의해 bdflush가 구동된다. 보통 때는 이 데몬들에 별로 신경 쓸 필요가 없지만, 만일 bdflush가 어떤 이유로 죽어버린다면 커널이 이 사실을 바로 알려줄 것이다. 이럴 때는 수동으로 실행시켜 주면 된다(/sbin/update).

그런데, 사실 캐쉬는 파일을 버퍼링하는 것은 아니고, 실제로는 디스크 입출력의 가장 작은 단위인 블록을 버퍼링한다(리눅스에서는 보통 1KB 크기이다). 그렇기 때문에, 디렉토리라든가, 수퍼 블록들, 다른 파일시스템의 유지 데이터, 심지어 파일시스템이 없는 디스크까지도 캐쉬될 수가 있는 것이다.

캐쉬의 효율성은 기본적으로 그 크기에 좌우된다. 캐쉬의 크기가 너무 작으면, 다른 데이터를 캐쉬하기 위해서 캐쉬된 데이터를 계속 내보내야 하므로, 사실상 작은 캐쉬는 별 쓸모가 없는 셈이다. 캐쉬가 어느 정도 쓸모있기 위한 최소한의 크기는, 얼마나 많은 데이터가 읽고 씌여지는지와, 같은 데이터가 얼마나 자주 액세스되는지에 달려있는데, 이것을 알아보기 위한 단 하나의 방법은 그저 실험해보는 것 뿐이다.

만일 캐쉬의 크기가 고정되어 있다면, 그 크기가 너무 큰 것도 곤란한 일일 것이다. 캐쉬가 너무 크면 여유 메모리는 그만큼 줄어들 것이고, 많은 스와핑을 일으켜서 시스템은 느려지게 된다. 리눅스는 자동적으로 모든 RAM의 빈공간을 버퍼 캐쉬로 사용하여 메모리의 효율성을 높이려 하는데, 프로그램들이 많은 메모리를 필요로 할 때는 자동적으로 캐쉬를 크기를 줄여 준다.

그래서, 리눅스에서는 캐쉬를 사용하는 데 대해서 아무것도 신경쓸 필요가 없다. 완벽하게 자동적이기 때문이다. 다만, 셧다운 할 때와 플로피를 빼낼 때의 절차는 꼭 지켜 주어야 한다. 이것만 빼면, 걱정할 것은 하나도 없다.

Notes

[1]

RAM 디스크의 경우는 제외이다. 이것은 RAM에 만들어진 가상의 디스크이므로, 당연히 램만큼이나 속도가 빠르다.

'개발자 기본 소양' 카테고리의 다른 글

diff 로 두 디렉토리 파일 비교  (0) 2012.05.23
디스크와 파일 시스템  (0) 2012.05.08
SWAP  (0) 2012.04.30
오픈소스 라이센스 비교  (0) 2012.04.11
VIM을 사용하자  (0) 2011.03.16
메크로 포함한 gcc옵션 -E  (0) 2011.01.11

출처 : http://www.codeproject.com/info/Licenses.aspx

Licenses

Authors

When uploading an article you need to be aware of the risks and legal issues involved. We live in a litigious world so you need to protect yourself against those seeking damages against you for problems that may (or may not) have been caused by your article. Just saying "The code is free for use" is no longer enough. What does "free" mean? Are there any restrictions? What happens if your code breaks my system and costs me money?

Below are a list of licenses that we at The Code Project support for article contributions. The main points to think about are:

  1. What restrictions do I want to impose on my content?
  2. How much do I wish to protect myself and my readers (licenses go both ways)

Please review the licenses below when deciding which license to attach to your article.

Those downloading files and using Articles

Always ensure that the License attached to an article is suitable for your uses. If in doubt contact the author directly to seek clarification from the author.

The Licenses

The following is a rough guide to the current licenses supported on The Code Project. Please read them carefully by following the links to the license pages themselves because some categorisations (such as whether downloads can be used commercially, or whether extensions must be release to the public) depends on the situtation. This is merely a guide: it's up to you to read the actual license carefully before using downloads licensed by each license or assigned a license to a download you submit.

The Code Project Open License (CPOL)

The main points subject to the terms of the License are:

  • Source Code and Executable Files can be used in commercial applications;
  • Source Code and Executable Files can be redistributed; and
  • Source Code can be modified to create derivative works.
  • No claim of suitability, guarantee, or any warranty whatsoever is provided. The software is provided "as-is".
Provides copyright protection: True
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: False
Provides an explicit patent license: True
Can be used in proprietary (closed source) applications: True
Is a viral licence: False
Supported by The Code Project: True

The Common Development and Distribution License (CDDL)

Based on the Mozilla Public License (MPL) that makes it more applicable for use outside the Mozilla Foundation.

Provides copyright protection: True
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: True
Provides an explicit patent license: True
Can be used in proprietary (closed source) applications: True
Is a viral licence: False
Supported by The Code Project: True

The Microsoft Public License (Ms-PL)

Used by Microsoft. Compiled derived code can be distributed, for both commercial and non-commercial use. If the source code is to be redistributed then a complete copy of this license must be included in the redistribution.

Provides copyright protection: True
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: False
Provides an explicit patent license: True
Can be used in proprietary (closed source) applications: True
Is a viral licence: False
Supported by The Code Project: True

The Mozilla Public License 1.1 (MPL 1.1)

Used by Mozilla and Firefox, among others. The patent clauses are not acceptable to some.

Provides copyright protection: True
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: True
Provides an explicit patent license: True
Can be used in proprietary (closed source) applications: True
Is a viral licence: False
Supported by The Code Project: True

The Common Public License Version 1.0 (CPL)

Derived from the IBM Public License and influenced by the Mozilla Public License, and used by some Microsoft projects on SourceForge.

Provides copyright protection: True
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: True
Provides an explicit patent license: True
Can be used in proprietary (closed source) applications: True
Is a viral licence: False
Supported by The Code Project: True

The Eclipse Public License 1.0

A newer version of the Common Public License that is in some cases more acceptable to business.

Provides copyright protection: True
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: True
Provides an explicit patent license: True
Can be used in proprietary (closed source) applications: True
Is a viral licence: False
Supported by The Code Project: True

The MIT License

A very old license with essentially no restrictions on the use of the code. It also provides very little in the way of protection for authors or users. It is the same as the BSD license without the 'no endorsement' clause.

Provides copyright protection: True
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: False
Provides an explicit patent license: False
Can be used in proprietary (closed source) applications: True
Is a viral licence: False
Supported by The Code Project: True

The BSD License

A very old license with essentially no restrictions on the use of the code. It also provides very little in the way of protection for authors or users. It is the same as the MIT license except that it includes a clause preventing the use of the author's name for endorsement.

Provides copyright protection: True
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: False
Provides an explicit patent license: False
Can be used in proprietary (closed source) applications: True
Is a viral licence: False
Supported by The Code Project: True

The Apache License, Version 2.0

Slightly more restrictive (but still very open) version of the BSD or MIT license that adds patent clauses. Read carefully.

Provides copyright protection: True
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: False
Provides an explicit patent license: True
Can be used in proprietary (closed source) applications: True
Is a viral licence: False
Supported by The Code Project: True

The Creative Commons Attribution-ShareAlike 2.5 License

A license that requires a link be visible on works that use this license. "Share alike" is what it sounds like, you can share this work as long as that work has a license similar to this one.

It is recommended that this license not be used for software.

Provides copyright protection: True
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: False
Provides an explicit patent license: False
Can be used in proprietary (closed source) applications: False
Is a viral licence: True
Supported by The Code Project: False

The zlib/libpng License

A license with an emphasis on freedom of use and re-use, with a few restrictions.

Provides copyright protection: True
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: False
Provides an explicit patent license: False
Can be used in proprietary (closed source) applications: True
Is a viral licence: False
Supported by The Code Project: True

A Public Domain dedication

Not a license, but a dedication to the public domain. All rights are given up and anyone can do anything they wish with the code. Please note this is not a license and provides no guarantees for the user and no indemnities for the author.

Provides copyright protection: False
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: False
Provides an explicit patent license: False
Can be used in proprietary (closed source) applications: True
Is a viral licence: False
Supported by The Code Project: True

The Creative Commons Attribution 3.0 Unported License

This license lets others distribute, remix, tweak, and build upon your work, even commercially, as long as they credit you for the original creation. It is recommended that this license not be used for software.

Provides copyright protection: True
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: False
Provides an explicit patent license: False
Can be used in proprietary (closed source) applications: False
Is a viral licence: True
Supported by The Code Project: False

The Creative Commons Attribution-Share Alike 3.0 Unported License

A license that requires a link be visible on works that use this license. "Share alike" is what it sounds like; you can share this work as long as that work has a license similar to this one. It is recommended that this license not be used for software.

Provides copyright protection: True
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: False
Provides an explicit patent license: False
Can be used in proprietary (closed source) applications: False
Is a viral licence: True
Supported by The Code Project: True

The GNU Lesser General Public License (LGPLv3)

A derivative of the GPL that was intended to allow non-GPL code to work with, and call GPL code. The author of this license asks that you only use this license if you are licensing functionality already commonly available.

Provides copyright protection: True
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: True
Provides an explicit patent license: False
Can be used in proprietary (closed source) applications: True
Is a viral licence: True
Supported by The Code Project: True

Example usage in your code

(Replace 'Foobar' with the name of your product)
This file is part of Foobar.

Foobar is free software: you can redistribute it and/or modify
it under the terms of the GNU Lesser Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

Foobar is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Lesser Public License for more details.

You should have received a copy of the GNU Lesser Public License
along with Foobar. If not, see <http://www.gnu.org/licenses/>.

The GNU General Public License (GPLv3)

A common but misunderstood license. This allows developers to freely use the software as long as they use the same (or an even less restrictive) license for parts of the program that they wrote themselves. Viral in nature. Read carefully and make sure you understand the implications of using this license. Unacceptable to many.

You can write commercial software using software licensed with the GPL, but you cannot write proprietary software (meaning software for which the code is not freely available). You can sell GPL code, even if it's already being given away, or you can sell services attached to the code such as support contracts.

Any software written using GPL'd code must itself be licensed using the GPL (or less restrictive license) meaning it cannot be proprietary. This means that developers writing commercial software may not be able to use GPL code if they do not wish to provide the code.

One important note (thanks to René Pfeiffer): The GPL doesn't require you to publish the source to the world. Only the recipient of the software needs to have the source. If you have a customer, write GPLed software for a specific purpose and only give the binary to this customer, then only this customer must have access to the source code, not everybody and not the public; just the recipient of the (binary) code. This is in full agreement to the GPL. The main advantage is to play with open cards and not create a "blackmail" situation.

At the Code Project we prefer that developers allow other developers to use their freely given code in whatever way they wish - commercial, proprietary, or free for anyone. Our preference is that our authors do not use a GPL-like license.

Provides copyright protection: True
Can be used in commercial applications: True
Bug fixes / extensions must be released to the public domain: True
Provides an explicit patent license: False
Can be used in proprietary (closed source) applications: False
Is a viral licence: True
Supported by The Code Project: True

Example usage in your code

(Replace 'Foobar' with the name of your product)
This file is part of Foobar.

Foobar is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

Foobar is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with Foobar. If not, see <http://www.gnu.org/licenses/>.


출처 : http://nowhunt.tistory.com/2

오픈소스는 쉽게 말해 소스코드를 공개 하여 많은 개발자들이 참여하여 발전해나가자~ 뭐 이런 느낌입니다.

오픈소스라고 해서 무제한 사용이 가능한것이 아니라 지정된 라이센스에 따라서
저작권 보호도 되고 소스의 사용/복제/수정/배포의 제약이 있으므로 라이센스별 차이와 제한을 알고 사용해야할듯 합니다 ^^

개인적으로는 MIT 라이센스 완전편해요 >_<

The Code Project Open License (CPOL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오


The Common Development and Distribution License (CDDL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오


The Microsoft Public License (Ms-PL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오


The Mozilla Public License 1.1 (MPL 1.1)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오


The Common Public License Version 1.0 (CPL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오


The Eclipse Public License 1.0

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오


The MIT License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오


The BSD License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오


The Apache License, Version 2.0

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오


The Creative Commons Attribution-ShareAlike 2.5 License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 아니오**
* 라이센스 전파 여부: 예**


The zlib/libpng License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오


공개 커뮤니티에 대한 공헌 (라이센스 아님)

* 저작권 보호: 아니오**
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오


The GNU Lesser General Public License (LGPL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 아니오**

* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 예**


The GNU General Public License (GPL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 아니오**

* 라이센스 전파 여부: 예**


열심히 표만들고 정리하다가 보니 예전에 저장해뒀던 문서를 발견!!
번역자분 블로그는 찾아가봤지만 폐쇄된것같네요.





VIM을 사용하자

윤 상배

dreamyun@yahoo.co.kr

고친 과정
고침 0.9 2004년 3월 10일 17시
vim 모드와 관련된 부가내용 추가
고침 0.8 2003년 3월 1일 23시
최초 문서작성

1. vim 이란

vim 은 유닉스 계열에서 전통적으로 널리 사용도던 vi 의 improve 즉 undo, syntax coloring, split windows 등의 기능을 포함시킨 vi 의 보강된 프로그램이다.

이 문서는 vim 의 기본적인 사용법과, 프로그래밍을 위한 여러가지 팁을 담고 있다. vim 버젼은 6.0 을 기준으로 한다. vim(vi)에 대한 자세한 사용방법은 여기에서는 제시하지 않을것이다. 가장 기본적인 사항만 언급할것이며, 자세한 사용법은 vi 사용자그룹 사이트를 참고하기 바란다.


2. VIM의 기본사용법 익히기

이번장에서는 vim의 기본적인 사용법에 대해서 알아보도록 하겠다. 위에서 언급했듯이, 이문서는 VIM의 레퍼런스 가이드는 아니다. 기본적인 사용이 가능하도록 가장 기초적인 내용들만 다룰것이다.


2.1. vim 모드

다른 에디터를 사용하던 유저가 vim을 처음 접하면서 가장 난감해 하는 부분이 vim의 상태(mode)개념이다.vim은 다른 에디터들과 달리, 실행을 시켰다고 해서 즉시 입력이 이루어지지 않는다. 많은 vim을 처음 접하는 유저는 어떻게 글을 입력할지 몰라서 vim의 사용을 접게되는 경우가 발생하는데, 여기에 그 이유가 있다. vi 는 크게 세가지 상태로 나뉘어진다. 첫번째가 명령어 모드로 키입력이 바로 실행되는 상태이며, 다음은 상태모드로 실제 문서를 편집하는 모드 마지막이 ex 상태로 ex 명령을 실행시키는 상태이다.

vi 를 처음실행시키면 입력모드가 아닌 명령모드 상태에 놓이게 된다. 이 상태에서는 문자의 입력이 이루어지지 않으며, 찾기등과 같은 간단한 문서관련 명령을 실행할 수 있다. 이 명령모드 상태에서 ":" 키를 누르면 ex 상태로 a, i, o 키 등을 누르면 입력 상태로 넘어가게 된다. 일단 입력상태로 들어가게 되면 문서 편집을 할수 있게 되는데, 이때 ESC 키를 누르면 명령모드 상태로 넘어가게 된다.

표 1. vim의 상태(mode)

명령 상태 처음 vim을 실행했을때, 입력상태/명령상태에서 ESC입력시 간단한 찾기, 커서 이동, ex 상태로 넘어가기
ex 상태 명령 상태에서 (":") 각종 치환, 저장, 파일읽기, vim설정등과 같은 대부분의 작업들
입력 상태 명령 상태에서 (a,i,o 키 입력) 내용 입력


2.2. 명령어모드의 사용

우리는 명령모드에서 여러가지 명령을 입력함으로써, 복사, 붙이기, 삭제 문서입력, 문서저장, 문서불러오기, 커서이동 등의 작업을 할수 있다. 이번 장에서는 이러한 명령모드에서 사용되는 각종 명령어에 대해서 알아보도록 하겠다.


2.2.1. 커서 이동

기본적으로 vi 는 입력모드에서 방향키를 이용해서 커서 이동을 하지 못하도록 되어있다. 비록 최근의 vim 이 입력모드에서 방향키를 이용한 커서 이동을 지원하고 있기는 하지만, 명령모드에서의 키이동이 훨씬 빠르고 편하므로, 처음에는 좀 어색하더라도 명령모드에서의 키 이동을 익히도록 하자.

표 2. 커서 이동

k 커서를 위로 움직임
j 커서를 아래로 움직임
h 커서를 왼쪽으로 움직임
l 커서를 오른쪽으로 움직임
- 커서를 줄의 처음으로 옮김
e, E 다음단어의 끝으로, 문자단위 이동
w, W 다음단어의 처음으로, 문자단위 이동
$ 줄의 마지막으로
0 줄의 처음으로
^ 줄의 처음으로(공백이 아닌 처음시작되는 문자)
Shift+g 문서의 마지막으로 이동한다.
gg, 1g 문서의 처음으로 이동한다. 1대신 다른 숫자를 입력하면 해당 숫자의 라인으로 이동한다.
), ( 다음, 이전 문장의 처음으로
}, { 다음, 이전문단의 처음으로
]], [[ 다음, 이전 구절의 처음으로


2.2.2. 화면 스크롤

위의 커서명령 이동이 매우 편하기는 하지만, 만약 페이지가 한 2000라인 될경우, 위의 커서를 이용해서 한줄씩 이동하는데에는 너무 많은 시간이 걸릴것이다. 그래서 vi 에서는 화면 단위의 스크롤이 가능한 명령들을 제공한다. 아래의 화면 스크롤 명령어들을 익히면 빠른 위치이동을 위해 매우 유용하게 사용할수 있다. ^F 는 CTRL+F 를 의미한다.

표 3. 화면 스크롤

^F 한 화면 을 앞으로 스크롤
^B 한 화면 을 뒤로 스크롤
^D 반 화면 을 앞으로 스크롤
^U 반 화면 을 뒤로 스크롤
^E 한줄 앞으로 스크롤
^Y 한줄 뒤로 스크롤
Shift + h 화면의 맨 윗줄로
Shift + m 화면의 중간줄로
Shift + l 화면의 맨 아랫줄로


2.2.3. 마크 이동

일종의 책갈피 기능이라고 보면 된다. 자주 참조해야할 라인에 마크를 해놓고 필요할때 곧바로 마크된 영역으로 이동하기 위해서 사용한다. 마크는 mx 형식으로 사용할수 있다. x 는 (a~z)까지의 문자로 마크된 영역의 이름을 지정하기 위해서 사용한다. 마크된 영역으로 이동하기 위해서는 'x 와 `x 를 사용한다. 'x 는 마크된 라인의 가장 앞으로 이동하고, `x 는 마크된 라인의 정확한 위치로 이동한다.


2.2.4. 입력 명령

지금 vi 를 실행시켜보자. vi 는 기본적으로 명령모드로 실행되므로, 지금상태에서는 문서 작성을 할수 없을것이다. 우리는 다음과 같은 키입력을 통해서 입력모드 상태로 전환할수 있다.

표 4. 입력 명령

i 현재위치에서 삽입
I 현재줄의 처음위치에서 삽입
a 현재위치에서 한칸앞으로 이동해서 삽입
A 현재줄의 마지막위치에서 삽입
o 새로운 줄을 커서 아래에 연다
O 새로운 줄을 커서 위연다
s 현재 위치의 문자를 지우고 입력모드로 들어간다.
S 현재위치의 라인을 지우고 입력모드로 들어간다.


2.2.5. 편집명령

여기에서는 vi의 편집기능인 복사, 붙이기, 삭제에 대해서 알아 보도록 하겠다. 다른 에디터들은 보통 마우스를 이용해서 블럭을 지정해서 편집을 하는 반면, vi 는 명령어 모드에서 키보드 만을 이용해서 편집이 가능하므로, 매우 편리하고 빠르게 편집작업들이 가능하다. 또한 라인단위 블럭, 블럭단위 블럭등의 선택 모드를 지원함으로써, 문서에서 원하는 부분에 대한 작업을 좀더 쉽게 할수 있다.


2.2.5.1. 편집(none visual block 모드)

visual block 모드가 아닌 상태에서이 편집에 관한 내용이다.

표 5. 복사,삭제,붙이기

y 한줄 복사
yn 현재 라인에서부터 n라인만큼을 복사
p 복사된 내용 붙이기
dd 한줄삭제
dw 한단어 삭제
Shift+d, d$ 현재커서 위치에서 마지막까지 삭제
Shift+j 현재 행의 개행문자를 제거한다. 즉 아래라인을 현재라인에 덧붙인다.


2.2.5.2. Undo (되돌리기)

vim 은 다중의 undo 기능을 지원한다. 뒤로 되돌리고 싶다면 단지 'u'키만 입력하면 된다.


2.2.5.3. 블럭 지정

이번엔 블럭지정, 그중에서도 vim 에서 지원하는 visual 블럭 지정에 대해서 알아보겠다. vim visual 블럭 지정 기능을 사용할경우 지정범위가 반전되면서 눈에 보이기 때문에, 효과적인 블럭지정이 가능하도록 도와준다. 범위지정을 위해서 'hjkl', 'Shift+g,GG' 과 같은 이동명령 과 화면스크롤 명령을 사용해서 범위지정을 좀더 빠르게 할수 있다.

표 6. 블럭지정

v 단어단위로 블럭지정이 가능하다. 블럭범위는 이동명령인 'hjkl' 로 원하는 범위 만큼 지정할수 있다.
Shift+v 라인단위 블럭지정이다. 라인전체가 선택되며, 위아래 이동명령 'hj' 으로 범위 지정이 가능하다.
Ctrl+v 블럭단위 블럭지정이다. 4각형의 블럭지정이 가능하며 이동명령인 'hjkl' 로 원하는 범위를 지정할수 있다.
Shift+v 와 같이 블럭지정을 한후 Shift+G 를 입력하면 현재라인부터 마지막 라인까지가 블럭 지정이 될것이다.


2.2.5.4. 편집(visual block 모드)

일단 vim 의 visual 블럭 지정 기능을 이용해서 편집하기 원하는 블럭을 지정했다면, 각종 편집명령을 이용해서 복사, 붙이기, 삭제 작업이 가능하다. 블럭을 지정한 상태에서 아래의 명령을 이용해서 편집을 하면 된다. 명령어는 기본적으로 none visual block 모드의 편집 명령어과 같다.

표 7. 편집(복사, 삭제, 붙이기)

y 지정된 블럭을 복사한다.
p 복사된 블럭을 현재라인(커서) 아래에 붙인다.
d 지정된 블럭을 삭제한다.
dd 현재라인을 삭제한다.


2.3. ex 모드

2.3.1. 찾기/치환

vim 의 기능중 가장편리한 기능으리면 뭐니뭐니 해도, 정규표현식을 이용한 강력한 찾기기능과 치환기능이라고 할수 있을것이다. 물론 다른 대부분의 에디터들도 찾기기능과 치환기능을 제공하긴 하지만, vim 의 기능은 다른 에디터들에 비해서 정말로 독보적인 편리함과 강력함을 제공한다. vi 사용자가 다른 에디터로 넘어가기 힘든이유중 가장큰 이유가, 바로 "키를 이용한 방향입력" 과 "찾기 및 치환" 기능 때문이다.

사실 찾기 치환의 기능을 제대로 이해하고 사용하기 위해서는 정규표현식(regular expression) 에 대한 이해가 필요로 하는데, 이것은 다음의 사이트를 참조하기 바란다. 정규 표현식의 간략한 소개

먼저 찾기 기능에 대해서 알아보겠다. 찾기기능은 ':/패턴/' 를 이용 하면된다. 찾기 원하는 문자혹은 패턴을 입력하고 엔터키를 누르면 현재 커서위치에서 가장 가까운 곳에 위치한 문자열로 커서를 이동시킨다(문서 아래방향으로). 다음 문자열을 찾기를 원한다면 'n'키를 누르면 된다. 문서에서 가장 마지막에 이르르게 되면, 문서의 가장처음부터 다시 찾기 시작한다. 'Shift+n' 을 이력하면 반대 방향(문서의 위쪽으로)으로 찾기를 시작한다.

치환이야 말로 vim 의 꽃이라고 할수 있다. :[범위]s/[oldpattern]/[newpattern]/ 의 형식으로 사용하면 된다. 범위 지정은 visual block 을 이용할수도 있으며, 직접 범위를 입력할수도 있다. visual block 를 이용한 치환은 visual block 를 지정한다음 ':' 를 입력해서 ex 모드로 넘어가면 된다. 그리고나서 ':'<,'>s/[oldpattern]/[newpattern/' 과 같은 방법으로 치환하면 된다.

visual block 를 사용하지 않고 직접범위를 입력할수도 있다. :[시작],[마지막]s/[old]/[new]/ 식으로 범위를 지정하면 된다. 여기에는 몇가지 지정된 범위를 위한 특수 기호들이 있다. '%' 는 전체문서(처음부터 끝까지), '.' 은 현재, '$' 은 마지막 을 나타낸다. 숫자를 입력할경우 숫자는 라인을 나타낸다. 다음은 간단한 사용예이다.

# 문서 처음부터 마지막까지의 char 를 _char_ 로 치환한다. 
:%s/char/_&_/g

# 현재(커서위치)부터 마지막까지의 char 를 _char_ 로 치환한다.
:.,$s/char/_&_/g

# buf_.*[255], buf_in[255], buf_get[255] 와 같은 문자열을 hello 로 변경한다.  
:1,10s/buf_.*\[255\]/hello/g
				
마지막에 쓰인 'g' 는 global 이다. 즉 해당 라인 전체에 걸쳐서 검색후 치환한다. 'g' 를 사용하지 않을경우 라인에서 처음에 검색된 문자만 치환하고 다음 라인으로 넘어간다.


2.3.2. 파일 저장, 열기, 종료

파일열기의 경우 vi 를 실행시킬대 명령행 옵션으로 열기가 가능하다. 또한 vi 를 이미 실행 시킨후에도 명령모드에서 명령을 입력함으로 파일을 열수 있다. 열고자 하는 파일이 이미 존재할경우에는 존재하는 파일이 열리고, 열고자 하는 파일이 존재하지 않을경우 새로운 파일이 만들어진다.

표 8. 저장,열기,종료

:e [filename] filename 으로 파일열기
:q, :q!, :wq 종료, 강제종료, 저장후 종료
:w, :w [filename] 현재파일명으로 저장, filename 로 저장
:<범위>w [filename] 지정한 범위만 다른 파일로 저장
:e [filename] filename 을 편집하기 위해서 연다
ZZ 지금파일을 저장하고 vim 을 종료한다.
:f 현재 작업중인 파일의 이름과, 라인수를 출력한다

3. 개발자를 위한 vim 사용팁

3.1. 화면 나누기

vim 은 수평나누기와 수직나누기를 제공한다. 수평나누기는 ":split [파일이름]" 수직나누기는 "vs [파일이름]" 으로 나눌수 있다. 파일이름을 지정한 경우, 새로 만들어진 창에는 파일이름 을 가지는 파일이 열리고, 파일이름을 지정하지 않을경우 똑같은 파일이 열린다. 이 기능은 현재 파일의 다른 부분을 참조하고 싶을때 유용하게 사용할수 있다(참조하는 부분으로 이동하기 위해서 왔다갔다 하지 않아도 되므로). 또한 ":10split [파일이름]", "10vs [파일이름]" 등으로 창의 크기를 조절해 줄수도 있다. 창 나누기는 2개 이상 나누기도 가능하다.

이렇게 창을 분할시켜 놓으면 쏘쓰를 참조하기도 편하고, 무엇보다 편집(삭제,복사,붙이기)가 가능하므로 훨씬더 작업을 수월하게 할수 있다.


3.1.1. 화면 이동

명령 모드에서 CTRL+ww 를 입력하면 된다. 그러면 아래창으로 이동한다. 임의로 이동하기 위해서는 Ctrl+w 를 입력한 상태에서 이동명령[hjkl]를 이용하면 원하는 방향으로 창이동이 가능하다.


3.1.2. 파일 네비게이션

vim 6.0 부터는 파일네비게이션 기능이 존재합니다. 예를들어 vi 로 파일을 열때 파일을 디렉토리로 지정하면 해당디렉토리의 내용이 네비게이션 되고, 디렉토리 이동및 파일 선택이 가능하다.

	
vi ./   # 현재 디렉토리내용을 네비게이션 해준다. 
				


3.2. 파일 네비게이션 바 만들기

윈도우의 울트라 에디트와 같은 프로그램을 보면 왼쪽에 파일네비게이션이 있어서 원하는 파일을 바로 선택해서 편집하는 기능이 있다. vim 으로도 이러한 기능을 구현할수 있다. 이것은 vim 의 file navigation 기능과 창나누기 기능을 이용해서 구현하면 된다.

vi 가 실행되 상태에서 수직창 나누기 기능을 이용해서 ":20vs ./" 명령을 내려보자 그럼 그림과 같이 오른쪽에 파일 네비게이션 바가 생김을 알수 있다.

그림 1. 파일네비게이션을 만든 화면

이제 열기를 원하는 파일위치에 가서 shift+o 를 입력해보자, 그럼 옆의 편집창에 새로운 파일이 열리는것을 알수 잇을것이다. 여기에 더해서 편집장을 split 로 나누면, 여러개의 파일을 오가면서 편집이 가능해질 것이다. [vim 7에서는 shift+p로 단축키가 변경됐다]


3.3. 여러개의 파일 편집하기

위에서는 창나누기를 이용한 여러개의 파일편집에 대해서 알아봤는데, 또다른 방법이 있다. 처음에 vim 을 통하여 여러개의 파일을 open 하고 여러개의 열린 파일을 이동하면서 편집하는 방법이다. 먼저 vim을 다음과 같이 실행시킨다.

 
[yundream@localhost test]# vim file1.txt file2.txt ...
			
그러면 처음 화면은 file1.txt 편집화면일것이다. 2번째 파일인 file2.txt 편집화면으로 넘어가길 원한다면(앞에 있는 파일 편집)
:n
			
file2.txt 에서 file1.txt 를 편집하길 원한다면(뒤에 있는 파일편집)
:e#
			
split 를 이용해서 여러개의 파일을 편집할때와 마찬가지로, 각종 편집기능(복사,삭제,붙이기)이 서로 공유되므로 편하게 작업이 가능하다.


3.4. 잠시 쉘로 나가기

보통 vim상에서 쉘명령어를 실행시키기 위해서 :![명령어] 를 사용하는데, 이것 보다는 Ctrl+z 를 이용해서 쉘로 빠져나가서 작업하는게 더 편하다. shell 이 job control 기능을 이용한것으로, 쉘에서 원하는 작업을 수행하후 fg 명령을 이용해서 다시 vi 편집 상태로 되돌아 올수 있다. vim 사용자를 보면 가끔 쉘작업을 하기 위해서 vim 을 아예 종료 시켜서 쉘로 빠져나간 다음에 작업을 하고 vim 을 다시 실행시키는 경우가 있는데, 이제는 그럴필요가 없이 좀더 편하게 작업을 할수 있을것이다.


3.5. 선택된 block 를 다른 이름으로 저장하기

split 기능을 이용해서 창을 나누고, 원하는 블럭을 선택해서 복사한다음에, 새로만든창에 가져다 붙이기를 하면 된다.

그러나 이방법은 조금 복잡한 감이 없잖아 있다. 이럴때는 블럭을 선택해서 :'<,'>w [파일명] 하면 좀더 간단하게 원하는 작업을 수행할수 있다.


3.6. 빠른 괄호 이동

C나 C++ 을 사용하다보면 제어문이나 함수에서 많은 괄호('{','(')를 만나게 된다. 이때 괄호의 제일 마지막으로 이동하고 싶을때가 있을것이다. 이럴때는 ']}' 를 사용하면 된다. '[{' 를 사용하면 괄호의 처음으로 이동한다.


3.7. 위치 마크(mark)하기

일종의 북마크기능으로 자주참조할만한 라인을 마킹해두고 필요할때 간단히 해당 마킹지역으로 이동하기 위해서 사용한다. 마킹을 위해서는 명령모드에서 m키를 눌러서 마킹모드로 들어가면 된다. 그리고 영문 [a-zA-Z]키중 아무거나 눌러주면 된다. 만약 a를 눌러주었다면, 현재라인은 a이름으로 마킹된다. 이후 작업을하다가 a마킹라인으로 가고 싶다면 'a 해주면된다. 이 상태에서 원래 라인으로 되돌아가고 싶다면 ''를 눌려주면 된다.

물론 다중마킹도 허용한다. 마킹할수 있는 문자는 단일영문자이다. 마킹에 사용되는 영문자는 대소문자를 구분함으로 최대마킹가능한 수는 27*2가 될것이다.


3.8. 폴더(접기) 기능이용하기

vim 6.0 에 새로이 포함된 좋은 기능으로 코드의 특정영역을 접을수 있다. 그럼으로 코드를 분석할때 쓸데 없는 부분을 감춰줘서 좀더 편하게 분석이 가능합니다. visual block 를 이용해서 원하는 영역을 선택한다음 :zf 를 이용하면 해당영역이 접힌다. :zo 를 사용하면 접힌영영을 원상태로 복구할수 있고 :zc 를 사용하면 해당영역을 다시 접을수 있다. 또한 다중 접기를 허용해서 접근구역을 다시 접을수도 있다.


3.9. 간단한 man 페이지 참조

vim 을 이용 코딩중에 함수의 프로토 타입이 생각나지 않을때 주로 man page 를 참조하게 된다. 보통은 창을 하나따로 띄워서 그곳에서 man page 를 보는데, 코딩중에 간단하게 해당 함수에 대한 man page 를 볼수 있다. man page 를 원하는 함수 위로 커서를 옮긴다음 Shift + k 를 입력하면 함수의 man page 가 뜰것이다. 'q' 를 입력해서 man page 를 종료시키면 원래의 vim 화면으로 되돌아온다.


3.10. 함수/변수명 자동완성

코딩중에 가장 범하기 쉬운 잘못중의 하나가 변수명및 함수명 오타일것이다. 또 변수명이 기억이 잘 나지 않아서 처음 선언한곳을 다시 확인하는 작업역시 코딩을 매우 번거롭게 한다. 이때 함수 자동완성 기능을 이용하면 이러한 염려들을 줄일수 있다.

int client_sockfd 라고 변수 선언을 했다고 하자. 코딩중에 client_sockfd 를 쓸일이 있다면 cli^p 를 입력해보자. 그러면 변수 이름이 자동으로 완성되는것을 볼수 있을것이다. ^p는 Ctrl+p 이다.


3.11. ctags 를 이용한 쏘쓰 분석

쏘쓰를 분석하는데 있어서 가장 중요한 것은 역시 함수를 분석해서, 함수가 어떤일을 하는지 알아내는 것이다. ctags 를 이용하면 이러한 쏘쓰 분석작업을 좀더 수월하게 할수 있다. ctags 와 관련된문서는 ctags 를 이용한 쏘쓰 분석 을 참고하기 바란다.


3.12. 자동들여쓰기

프로그래밍 할때 indent 는 쏘쓰코드를 보기좋게 만들기 위한 필수 사항이다. 보통 tab 을 주로 쓰는데,

:set ai
			
명령을 이용하면 자동적으로 indent (auto indent) 를 적용시켜주므로, 좀더 코딩에만 집중할수 있도록 도와준다.
:set noai 
			
명령을 사용해서 auto indent 상태를 해제할수 있다.

요즘의 vim 은 기본적으로 auto indent 상태이므로, 별다른 설정없이 편하게 사용가능하다. 그러나 웹에서 가져다 붙이기를 할때 여기에 auto indent 가 적용되어서 걷잡을 수 없이 tab 이 들어가는 경우가 생길때도 있는데, 이럴때 set noai 를 이용해서 auto indent 를 해제하고 가져다 붙이기를 하면 된다.


3.13. 탭사이즈 조정하기

쏘쓰에서 indent 를 위해서 주로 탭을 사용하는데, 보통 이 탭 사이즈는 8로 되어 있다. 그런데 8이란 탭사이즈가 때로는 너무 커서, 쏘쓰가 화면밖으로 나가서 오히려 쏘쓰 보기를 어렵게 만들때도 있다. 이럴때 는 탭사이즈를 줄여야 하는데 다음과 같은 명령을 통해서 탭사이즈 변경이 가능하다.

:set ts=4
			


3.14. 라인 넘버링

코딩하다보면 라인넘버가 있으면 할때가 있다. 그럴때는

:set nu 
			
하면 된다.

그림 2. 라인 넘버링

라인넘버를 없애고 싶다면,
:set nonu
			
하면 된다.


3.15. 코드를 HTML로 저장하기

vim 은 또한 코드를 HTML 형태로 저장하는 기능을 가지고 있다. 이 기능을 이용하면 syntax highlight 된 상태 그대로 HTML로 변환이 가능하다. 쏘쓰코드의 예제를 만들어서 웹상에 올리고자 할때 유용하게 사용할수 있는 기능이다.

:so $VIMRUNTIME/syntax/2html.vim 
			


3.16. vim 설정파일 만들기

지금까지 우리는 다양한 설정을 통해서 vim 을 좀더 쉽게 사용하는 방법을 알아 보았다. 그런데, 탭사이즈를 적용하기 위해서 vim 을 실행시킬때 마다 ":set ts=4" 이런식으로 하면 작업이 매우 귀찮을것이다. 이럴때는 vim 을 위한 설정파일을 만들어서, vim 이 시작할때 설정파일을 읽어들여서 환경이 자동으로 설정되도록 하면된다.

자기의 계정(Home) 디렉토리에 보면, .vimrc 라는 파일이 존재 할것이다. (존재하지 않는다면 만들도록한다) 이것이 설정파일로 아래와 같은 방법으로 자기가 원하는 내용을 설정하면 된다.

set ts=4
set nu
		

[root@localhost] gcc -E -o hello.i hello.c

[root@localhost] ls

hello.i

 

결과로 hello.i 가 생긴다. 해당 파일을 에디터로 열어 보면,

hello.c의 첫번째 줄에 있는 #include를 처리한 결과가 보일 것이다.

[출처] gcc 옵션 03|작성자 ddrkcodz