특정 사용자와 관련된 모든 프로세스를 죽이는 명령어 
 

% kill `ps -ef | grep 특정ID | awk '{print $2}'` 

 

kill -9 `ps -fu USERNAME | awk '{print $2}'`

 

kill다음에 나오는 `은 `와 ` 사이에서 실행되는 결과값을 되돌린다는 것을 의미하며 따라서 ps -ef(BSD계열에선 -aux)을 통해 grep으로 들어간 프로세스 테이블 리스트들은 특정ID에게 소유된 것만 걸러 지게 되고 awk를 통해 프로세스 리스트의 두번째 컬럼 부분의 프로세스 ID가 다시 걸러 지게 되며, 최종적으로 이 값이 kill에 전달된다. 



http://blog.naver.com/PostView.nhn?blogId=wawoo33&logNo=60146917607

'' 카테고리의 다른 글

VMWARE workstation 7.1.4 patch for kerenel 3.1  (0) 2013.06.28
NX Client 속도 향상  (0) 2013.04.27
[명령어] 특정유저 프로세스 강제 종료 명령어  (0) 2013.04.08
NX 단축키  (0) 2013.04.05
Eclipse 속도 향상 팁  (0) 2013.03.06
Posted by 라판

리눅스에서 작업을 하다 보면, 폴더를 옮겨가며 작업을 하는 데, 깊은 깊이의 폴더로 갔다가 상위 폴더로 

가려면 여러번의 폴더 이동을 하곤 했다. 그런데 cd - 명령은 바로 이전에 있었던 폴더로 바로 가게 해주어

편리하다. 커널에서 각 드라이버 폴더로 가서 작업 하다, 다시 돌아올 때 유용. 

 


http://www.lug.or.kr/home/bbs/board.php?bo_table=centos_book&wr_id=64&page=6#bbs


아마도 모르시는분들이 있을것 같아 이곳에 적어둡니다.

쉘작업하면서 이전 디렉토리로 가야할 경우가 간혹 있습니다.

이때에는 cd - 라고 입력하시면 됩니다.

[root@lug ~]# cd /usr/local/src
[root@lug src]# pwd
/usr/local/src
[root@lug src]# cd -
/root
[root@lug ~]# pwd
/root
[root@lug ~]#

간단하죠..

'리눅스 > 일반' 카테고리의 다른 글

cpu 갯수 확인하기  (0) 2012.10.16
screen 명령어  (0) 2012.10.16
리눅스에서 이전 폴더로 이동하기  (0) 2012.03.30
find 와 grep를 이용한 파일/문자열/디렉터리 찾기 및 치환  (0) 2012.02.02
ANSI color  (0) 2011.12.20
cron 사용법  (0) 2011.12.19
Posted by 라판

이전 글에서 journalling과 ReiserFS의 장점과 Linux 2.4 기반의 ReiserFS 시스템을 설치하는 방법을 설명하였다. 이번에는 색다른 주제를 다루려고 한다. 우선 가상 메모리 (VM) 파일시스템으로 알려져있는 tmpfs를 살펴 볼 것이다. tmpfs 는 아마도 Linux에서 사용 가능한 RAM disk와 같은 최상의 시스템일 것이다. 그리고 이것은 커널 2.4의 새로운 기능이다. 또한 그런다음 2.4의 새로운 또 하나의 기능인 "bind mounts"에 대해 살펴볼 것이다. 이것은 파일시스템을 마운트 (리마운트) 할 때 상당한 유연성을 발휘한다. 다음 회에는 devfs에 대해 집중적으로 살펴보고 ext3 파일시스템을 숙지할 것이다.

tmpfs

tmpfs를 한마디로 설명해야 한다면, ramdisk와 같으면서도 다르다고 말해야 할 것 같다. ramdisk와 비슷한 점은, tmpfs는 RAM을 사용할 수 있다는 것이고, 다른점은 저장을 위해 swap 디바이스들을 사용할 수 있다는 것이다. 기존의 ramdisk 는 블록(block) 디바이스이고, 실제로 그것을 사용하려면 mkfs 명령어가 필요하지만, 반면 tmpfs는 파일시스템이다. 블록(block) 디바이스가 아니다; 마운트하면 바로 존재하게 된다. 이러한 사실 때문에 tmpfs가 훌륭한 RAM 기반의 파일시스템이 될 수 있는 것이다.

tmpfs & VM

이제, 좀 더 재미있는 tmpfs의 기능들을 살펴보자. 앞서 언급했지만 tmpfs는 RAM과 swap 모두를 사용할 수 있다. 언뜻 듣기에는 약간 제멋대로라는 생각이 들지만 tmpfs가 "가상 메모리 파일시스템"이라는 점을 기억하라. 또한 여러분도 알고 있듯이, Linux 커널의 가상 메모리 리소스는 RAM과 swap 장치에서 나온다. 커널의 VM 서브시스템(subsystem)은 이러한 리소스들을 시스템의 다른 부분에 할당하고, 리소스들을 막후에서 관리한다. 종종 투명하게 RAM 페이지를 swap으로 또는 그 반대로 옮긴다.

tmpfs 파일시스템은 파일을 저장하기 위해서 VM 서브시스템에 페이지를 요청한다. tmpfs 자체로는 이러한 페이지가 swap 상에 있는지 또는 RAM에 있는지 알지 못한다; 그러한 결정을 하는것은 VM 서브시스템의 역할이다. tmpfs 파일시스템이 인식하고 있는 것은 이것이 특정 형식의 가상 메모리를 사용하고 있다는 것이다.

블록(block) 디바이스가 아니다!

tmpfs 파일시스템의 또 다른 재미있는 특징이 있다. ext3, ext2, XFS, JFS, ReiserFS 등의 "평범한" 파일시스템과는 달리 tmpfs는 블록 디바이스에 존재하지 않는다. tmpfs는 VM에 직접 설치되기 때문에 간단한 마운트 명령어로 tmpfs 파일시스템을 구현 할 수 있다:


# mount tmpfs /mnt/tmpfs -t tmpfs

이 명령어를 실행시키면 /mnt/tmpfs에 마운트 된 새로운 tmpfs 파일시스템을 갖게되는 것이다. mkfs.tmpfs를 실행시킬 필요가 없다는 것에 주목하라. 사실, 이것은 불가능하다. 그와 같은 명령어가 존재하지 않는다. mount 명령어로 파일시스템은 마운트 되어 사용할 수 있게 된다. 그리고 이것은 tmpfs 타입이다. 이것은 Linux ramdisk가 사용되는 방식과는 상당히 다르다; 표준 Linux ramdisk들은 블록 디바이스이다. 따라서 사용하기 전에 여러분이 선택한 파일시스템으로 포맷되어야 한다. 반면 tmpfs는 파일시스템이다. 따라서 마운트하여 실행시키면 된다.

tmpfs 장점

동적으로 변하는 파일시스템 사이즈

/mnt/tmpfs에 마운트 된 tmpfs 파일시스템 크기가 궁금할 것이다. /mnt/tmpfs는 처음에는 매우 작은 용량이다. 하지만 파일이 복사되고 생성되면서 tmpfs 파일시스템 드라이버는 좀 더 많은 VM을 할당하고 필요한 만큼 파일시스템 용량을 동적으로 늘린다. 그리고, 파일들이 /mnt/tmpfs에서 제거되면 tmpfs 파일시스템 드라이버는 파일시스템의 크기와 VM 리소스를 줄인다. 이렇게 VM이 동적으로 존재하면서 필요할 때마다 시스템의 다른 부분에 의해 사용될 수 있다. VM은 소중한 리소스이기 때문에 실제 필요한 것보다 더 많은 VM을 요구하는 어떤 것도 원하지 않을 것이다. tmpfs의 또 하나의 멋진 기능은 이 모든 것이 자동으로 수행된다는 것이다. 참고자료 참조.

속도

tmpfs의 장점 중 하나는 놀라운 속도이다. 일반적인 tmpfs 파일시스템은 RAM에 존재하기 때문에, 읽기 및 쓰기는 거의 동시에 이루어 질 수 있다. 비록 어느 정도의 swap이 사용되더라도, 성능은 여전히 우수하고 더 많은 VM 리소스를 사용할 수 있을 때 tmpfs 파일시스템의 일부는 RAM으로 옮겨질 것이다. VM 서브시스템이 tmpfs 파일시스템의 일부를 swap으로 자동적으로 옮기는 것은 실제로 성능에 좋은 영향을 미친다. 왜냐하면 VM 서브시스템은 이것을 필요로하는 프로세스를 위해 RAM을 남겨둘 수 있기 때문이다. 이것은 동적 크기조절 기능과 함께 전체 OS 퍼포먼스와 유연성에 기여할 수 있게 된다. 기존의 RAM 디스크를 사용하는 것보다 훨씬 낫다.

지속성이 없다!

제목 자체의 뉘앙스로는 장점을 이야기하는 것 같지 않지만 tmpfs 데이터는 재부팅 중에는 보존되지 않는다. 가상 메모리라는 것이 본질적으로 휘발성이 있기 때문이다. 여러분도 지금 tmpfs가 어떤 의미에서 "tmpfs" 로 불리게 되었는지를 생각하고 있을 것이다. 하지만 실제로 이것은 매우 좋은 것이다. 임시 파일(/tmp)과 /var 파일시스템 트리와 같은 저장하고 싶지 않은 데이터를 보존하기에는 더없이 훌륭한 파일시스템이다.

tmpfs 사용하기

tmpfs를 사용하기 위해서는 "가상 메모리 파일시스템 지원 (이전의 shm fs)"이 가능한 2.4 시리즈 커널이 필요하다; 이 옵션은 kernel 설정의 "File systems" 섹션에 존재한다. 사실상 tmpfs의 사용 여부와 관계없이 2.4 커널에 tmpfs가 지원된다는 것은 좋은 일이다. 왜냐하면 POSIX 공유 메모리를 사용하기 위해서 커널이 tmpfs를 지원해야 하기 때문이다. System V 공유 메모리는 커널에 tmpfs가 없이도 작동할 것이다. POSIX 공유 메모리를 작동시키기 위해서 tmpfs 파일시스템을 마운트하지 않아도 된다는 것에 주목하라. 커널에 지원되는 것으로 충분하다. POSIX 공유 메모리는 많이 사용되지 않는다.

low VM 문제 방지

tmpfs가 필요한 만큼 동적으로 늘어나고 줄어든다는 사실에 한가지 의문점이 생긴다: 만일 tmpfs 파일시스템이 모든 가상 메모리를 소진 할 지점까지 이르면 어떻게 하겠는가? 그리고 남아있는 RAM이나 swap도 없다면? 재미없는 상황이다. 2.4.4 커널과 같은 경우 커널이 즉시 잠긴다. 2.4.6 커널은 VM 서브시스템은 여러 방법으로 픽스된다. VM을 소진하는 것은 훌륭한 경험은 아니지만 그렇다고 해서 그것이 완전히 잘못된 것은 아니다. 2.4.6 커널이 더이상 VM을 할당할 수 없더라도 분명히 tmpfs 파일시스템에 새로운 데이터를 작성할 수 없다. 또한 시스템 상의 다른 프로세스들에 많은 메모리를 할당할 수 없을 것이다; 일반적으로 이것은 시스템이 극도로 느려지고 반응도 느려진다는 것을 의미한다. 따라서 이러한 low-VM 컨디션을 완화시키기 위해서 필요한 조치를 취하는 것이 시간 낭비일 뿐이다.

게다가, 커널은 더 이상 어떤 것도 가능하지 않을 때 메모리를 없애는 "last-ditch" 시스템이다; VM 리소스를 요구하고 있는 프로세스를 찾으면 죽인다. 불행하게도 이러한 "프로세스를 죽이는" 솔루션은 tmpfs의 증가가 VM 소진에 지대한 영향을 끼칠 때는 역작용을 한다. 여기 그 이유가 있다. tmpfs 스스로는 죽을 수가 없다. (죽어서도 안된다) 왜냐하면 이것은 커널의 일부이지 유저 프로세서가 아니기 때문이다. 그리고 커널이 어떤 프로세스가 tmpfs 파일시스템을 차지하고 있는지 알아내는 것도 쉬운 일은 아니다. 그래서 커널이 실수로 가장 큰 VM-hog 프로세스를 찾아서 공격했다면 이것은 일반적으로 X server 이다. X server가 죽으면 root는 low-VM (tmpfs)을 유발한다.

Low VM: 솔루션

다행스럽게도, tmpfs 파일시스템이 마운트 또는 리마운트 될 때 파일시스템의 최대 사이즈를 지정할 수 있다. 실제로 2.4.6 커널과 util-linux-2.11g 에서는 마운트하면서 이러한 파라미터를 설정할 수 있다. 리마운트 시에는 되지 않는다. 리마운트 할 때에도 설정할 수 있기를 기대해 본다. 최대 tmpfs 사이즈 세팅은 리소스와 Linux의 사용 패턴에 따라 다르다; 이렇게 차이를 두는 이유는 전체 tmpfs 파일시스템이 모든 가상 메모리를 다써버리지 않도록 하며, 앞서 언급한 반갑지 않은 low-VM 유발 방지를 위해서이다. 알맞은 tmpfs의 최대 한계를 찾는 좋은 방법은 'peak time' 동안에 시스템의 swap 사용을 감시하는 것이다. 그런다음 'peak time' 동안 남아있는 swap과 RAM을 합한 것 보다 근소하게 작은 tmpfs 사이즈 한계를 지정한다.

최대 크기의 tmpfs 파일시스템을 만드는 것은 쉽다. 32 MB의 새로운 tmpfs 파일시스템을 만들어보자:

이번에는 /mnt/tmpfs에 새로운 tmpfs 파일시스템을 마운트시키는 대신 /dev/shm에 마운트했다. 이것은 tmpfs 파일시스템을 위한 "공식적인" 마운트포인트가 될 수 있다. devfs를 사용 할 경우 이 디렉토리가 이미 설정되있다는 것을 알게 될 것이다.

또한 파일시스템 크기를 512 KB 또는 1 GB로 제한하고 싶다면 size=512k와 size=1g 로 각각 지정하면 된다. 사이즈 뿐만 아니라 inode (파일시스템 객체)의 수도 제한 할 수 있다. nr_inodes=x 파라미터를 지정하면 된다. nr_inodes를 사용할 경우, x 자리에 간단한 정수가 올 수 있고, 수 천, 수 백만, 수십억개(!)의 inode를 지정하고 싶다면 x 자리에 각각 kmg 가 오도록 한다.

mount tmpfs 명렁어에 해당하는 것을 여러분의 /etc/fstab 에 추가하려면 다음과 같이 한다:


tmpfs	/dev/shm	tmpfs	size=32m	0	0

기존 마운트포인트(mountpoint)에 마운트하기

2.2 커널과 같은 경우, 어떤 것이 이미 설치되어있는 마운트포인트에 마운트를 시도할 때 에러가 나타난다. 하지만, 커널 마운팅 코드가 다시 작성되었기 때문에 마운트포인트를 여러번 사용하는 것은 이제 문제가 아니다. 다음과 같은 시나리오를 설정해 보자; /tmp에 파일시스템이 마운트가 되어있다. 하지만 tmpfs를 사용하기로 결정했다. 옛날에는 /tmp 를 언마운트 하고 새로운 tmpfs /tmp 파일시스템을 그 자리에 리마운트(remount) 하는 방법 밖에 없었다:


#  umount /tmp
#  mount tmpfs /tmp -t tmpfs -o size=64m

하지만 이러한 솔루션은 아무 소용이 없다. /tmp에 'open file'을 가지고 있는 많은 실행 프로세가 있을 수도 있다; 만일 그렇다면, /tmp를 언마운트 하려고 할 때 다음과 같은 에러가 나온다:


umount: /tmp: device is busy

하지만 최근의 2.4 커널에서는, "device is busy" 에러 없이 새로운 /tmp 파일시스템을 마운트 할 수 있다:


# mount tmpfs /tmp -t tmpfs -o size=64m

단일 명령어를 사용하여 이미 마운트 된 파티션인 /tmp의 탑(top)에 새로운 tmpfs /tmp 파일시스템이 마운트된다. 여기에는 더이상 직접적으로 액세스 되지 않는다. 하지만 원래의 /tmp에 액세스 할 수 없더라도, 원래의 파일시스템상에 있었던 모든 프로세스는 지속적으로 액세스 할 수 있다. 그리고 만일 tmpfs 기반의 /tmp를 umount 하면 원래 마운트 된 /tmp 파일시스템은 다시 나타날 것이다. 사실, 같은 마운트포인트에 여러개의 파일시스템을 마운트 할 수 있다. 그리고 그러한 마운트포인트는 스택(stack)처럼 작용할 것이다; 현재의 파일시스템을 언마운트하면 최근 마운트 된 바로 밑에 있는 파일시스템이 다시 나타날 것이다.

bind mount

bind 마운트를 사용하면, 모든 것을 마운트 하거나, 이미 마운트 된 파일시스템의 일부를 다른 장소에 마운트 할 수 있고 동시에 양 마운트포인트에 파일시스템을 액세스 할 수 있다. 예를 들어, 기존의 root 파일시스템을 /home/drobbins/nifty에 마운트하기 위해서 bind 마운트를 사용해 보자:


#  mount --bind / /home/drobbins/nifty

/home/drobbins/nifty를 자세히 살펴보면, root 파일시스템(/home/drobbins/nifty/etc, /home/drobbins/nifty/opt)을 볼 수 있을 것이다. root 파일시스템 상에서 파일을 수정한다면, /home/drobbins/nifty 에서도 수정이 된다는 것을 알 수 있다. 왜냐하면 그들은 하나이고 같은 파일시스템이기 때문이다. 커널은 두 개의 다른 마운트포인트에 파일시스템을 매핑(mapping)한다. 다른 장소에 파일시스템을 마운트 할 때, bind-mounted 파일시스템 내부에 있는 마운트포인트에 마운트 된 모든 파일시스템들은 함께 움직이지 않는다. 다시 말해서, 각 파일시스템에 /usr이 있다면, 앞서 수행한 bind mount는 /home/drobbins/nifty/usr를 빈 공간으로 남겨둘 것이다. 추가적인 bind 마운트 명령어를 사용하여 /home/drobbins/nifty/usr에 있는 /usr 의 내용을 검색할 수 있다:


#  mount --bind /usr /home/drobbins/nifty/usr

파일시스템의 bind mounting

Bind mounting에는 더욱 멋진 기능이 있다. /dev/shm에 마운트 된 tmpfs 파일시스템이 있다고 하자. 현재 root 파일시스템에 있는 /tmp의 tmpfs를 사용하기로 결정했다. 새로운 tmpfs 파일시스템을 /tmp에 마운트 하지 않고 현재 마운트 된 /dev/shm 파일시스템을공유하기 위해서 새로운 /tmp를 사용하기로 결정했다. /dev/shm을 /tmp에 bind mount 할 수 있지만, /dev/shm 에는 /tmp에 나타나지 않기를 바라던 몇 개의 디렉토리가 포함되어 있다. 그렇다면 어떻게 하겠는가? 다음과 같은 방법을 보자:


# mkdir /dev/shm/tmp

# chmod 1777 /dev/shm/tmp

# mount --bind /dev/shm/tmp /tmp

예제를 보면, 우선 /dev/shm/tmp 디렉토리를 만들고, 그 다음 여기에 1777 perms를 주었다. 이것은 /tmp에 적절한 권한이다. 디렉토리가 준비되었다면 /tmp에 /dev/shm/tmp와 /dev/shm/tmp를 마운트 할 수 있다. /tmp/foo 가 /dev/shm/tmp/foo로 매핑되는 동안 /tmp에서 /dev/shm/bar 파일로 액세스 할 방법이 없다.

bind mounts는 매우 강력하고 파일시스템 레이아웃을 쉽게 수정할 수 있다. 다음에는 devfs에 대해서 살펴보도록 하자.


출저 : http://www.ibm.com/developerworks/kr/library/l-fs3.html
Posted by 라판
Ctags는 특정 함수의 정의를 찾아가는 것에 편리한 도구이지만, call stack을 지원하지는 않는다. 여기 CScope는 이러한 ctgas의 기능을 확장한 도구이다. 

Vim/Cscope 강좌

Cscope 는 그 자체로도 아주 편리한 도구지만, 가장 즐겨 쓰는 에디터(이를테면 Vim)의 안락함에서 벗어나지 않을 수 있다면 더욱 좋다. 다행히 Vim 은 Cscope 지원이 들어가 있다.

이 강좌는 Vim 내장 Cscope 지원과 검색을 더 편리하게 해주는 맵을 소개한다.

vi 형식의 에디터에 대한 기본에 대해 알고 있다고 가정하지만 Vim 에 특화된 지식은 필요치 않다. (다중 창 등과 같은 Vim 고유의 기능이 사용되며, 이러한 기능의 사용법은 간략한 소개하겠다.) Cscope 에 대해서는 아무것도 몰라도 되며, 기초적인 것들을 소개하며 진행한다.

간단히 말해서, Vim 의 Cscope 지원은 Vim 의 ctags 기능과 매우 유사하다. 그러나 Cscope 는 ctags 보다 더 많은 검색 기능이 있기 때문에 몇 가지 차이점이 있다.

이것은 손수 따라올 수 있는 강좌이니 쉘을 열고 다음 단계들을 따라하라.

  1. 아직 Cscope 이 당신의 기계에 설치되어 있지 않다면 받아서 깔아라. Vim 6.x 가 이상적이지만 Vim 5 의 후기 버전으로 대부분의 기능이 가능하다. (세로 분리는 안 되겠지만 파일 주석에 나온 대로 맵을 수정하면 가로분리는 동작할 것이다.) 

    <!> 주의: Vim 이 --enable-cscope 로 컴파일되지 않았다면 그 플래그를 주어 Vim 을 다시 설정해서 컴파일해야 한다. 리눅스에 따라오는 대부분의 Vim 바이너리는 Cscope 플러그을 쓸 수 있게 되어 있다. 

  2. [http]cscope_maps.vim 파일을 내려받아서 Vim 이 시작할 때 읽힐 수 있도록 하라. Vim 6.x 를 쓴다면 $HOME/.vim/plugin 디렉토리 (혹은 runtimepath 의 plugin 하위 디렉토리 등) 에다 붙여 넣는다. Vim 5.x 를 사용한다면 $HOME/.vimrc 에 cscope_map 파일의 내용을 통째로 붙여넣든가, 따로 저장한 후 .vimrc 에 "source cscope_maps.vim" 라고 써 넣으면 된다. 

  3. C 코드가 있는 디렉토리로 가서 'cscope -R' 을 실행한다. ('-R' 은 Cscope 가 현재 디렉토리 뿐 아니라 모든 하위 디렉토리에 대해 구문 분석을 하도록 한다.) '-b' 플래그(데이터베이스만 생성하고 빠져나가게 한다)를 주지 않았으므로 Cscope 의 curses 기반의 GUI 로 들어오게 될 것이다. 검색을 몇 개 해 보라. (요령: 방향키로 검색 종류를 고르고 탭으로 검색 종류와 검색 결과 사이를 이동한다.) 검색 결과의 가장 왼쪽에 있는 숫자를 입력하면 Cscope 는 해당 위치로 Vim 을 열어 줄 것이다. (EDITOR 환경변수를 Vim 이 아닌 다른 것으로 설정하지 않은 이상 말이다.) Vim 을 나가면 다시 바로 직전의 Cscope GUI 로 돌아올 것이다. 멋지게도. 

    아, 그런데 Cscope 인터페이스는 큰 문제가 있다. 새로 검색을 할 때마다 Vim 을 빠져나가야 한다. 그래서 Vim 플러그인이 나온 것이다. CTRL-D 로 Cscope 를 빠져나가라. 

  4. Vim 을 시작하라. 원한다면 C 이름으로 (보기: 'vim -t main') 시작할 수 있으며, 그러면 그 이름이 정의된 곳으로 바로 갈 수 있다. 

  5. 커서를 C 이름이 있는 여러 군데 놓고 "CTRL-\ s" (컨트롤-역슬래시, 그리고 그냥 s) 를 빠르게 이어 치면 바로 그것을 사용하는 곳으로 갈 것이다. ctags 에서처럼 "CTRL-t" 를 누르면 원래의 검색 전의 원래 위치로 돌아갈 것이다. (그리고 여러 겹으로 검색해 들어갔다면 CTRL-t 를 누를 때마다 하나씩 되돌아 올 것이다.) 

    기억하기: '\' 는 ctags 검색에 쓰는 ']' 바로 옆에 있다. 

  6. 같은 검색을 이번에는 "CTRL-spacebar s" 로 해보라. 이번에는 두 개의 Vim 창이 가로로 갈라져서 Cscope 검색 결과가 새 창에 나오게 될 것이다. [ Vim에서 여러 개의 창을 한번도 써본 적이 없다면 다음과 같이 하라. "CTRL-W w" (또는 CTRL-W 방향키, 또는 CTRL-W h/j/k/l 로 왼쪽/위/아래/오른쪽) 로 창을 옮기고, 'CTRL-W c' (또는 아름다운 옛 시절의 ':q') 로 창을 닫고, 'CTRL-W s' 로 (또는 'CTRL-W v'로 세로로) 창을 나누고, ':split filename' 으로 파일을 새 창에서 연다. ] 

    기억하기: 큰 spacebar 처럼 생긴 가로막대가 스크린 가운데 나타나 Vim 창을 나눈다. 

  7. 이번엔 같은 검색을 "CTRL-spacebar CTRL-spacebar s" (그냥 CTRL 을 누른 채로 spacebar 를 두 번 치라) 로 해 보라. 만일 작동하기에 충분할 만큼 빠른 속도로 치는 것이 버겁다면 cscpoe_maps.vim 스크립트에서 Vim 타임아웃 설정을 [ 사실 나는 Vim 타임아웃 설정을 끄는 것을 대개의 경우 추천한다. ] 이제 두 개로 Vim 창이 세로로 나뉠 것이다. (주의: Vim 5.x 에는 동작하지 않는다. 세로 분리는 Vim 6.0에서 새로 나왔다.) 

  8. 지금까지는 cscope_maps.vim 의 키 맵만을 써서 Vim 에서 커서 바로 아래 있는 단어에 대한 검색만을 했다. 전통적인 방법으로 (Vim 의 내장 Cscope 지원을 통해) Cscope 검색을 하려면, ":cscope find symbol foo" (또는 간단히 ":cs f s foo") 라고 입력한다. 가로 분리된 창으로 검색하려면 ":scscope" (또는 그냥 ":scs") 라고 입력한다. (Vim 6.x 에서만 가능). 맵을 사용하는 것이 커서 아래에 있는 단어를 검색하기는 더 쉽지만, 명령줄 인터페이스는 쳐 넣는 어떤 이름으로든지 찾아갈 수 있으므로 가끔씩 쓸 있을 분명 있을 것이다. 

  9. 지금까지 's' 를 이용한 'X 라는 단어의 모든 쓰임새'를 찾는 한 가지 종류의 검색만을 살펴보았다. 다른 글자로 다른 종류의 Cscope 검색을 해보라. 'g' 는 전역으로 정의된 이름들을, 'c' 는 함수 호출을, 'f' 는 커서가 놓은 파일 이름을 (주의: Cscope 는 기본적으로 /usr/include 아래 헤더 파일을 모두 구문 분석하므로, 이 방법을 통해 대부분의 표준 인클루드 파일들을 열 수 있다.) 이들이 내가 가장 자주 사용하는 것들이지만, 다른 종류들도 있다. (cscope_maps.vim 와 Cscope 맨페이지를 중 하나 또는 두 곳 모두에서 찾아보라.) 

  10. Cscope 는 본래 C 코드에 쓸 목적이었지만, 매우 유연한 도구이기 때문에 C++ 이나 Java 와 같은 언어에 대해서도 잘 동작한다. 이것은 함수 호출이나 변수 정의와 같은 몇 가지 구조를 추가로 인식할 수 있는 일반적인 'grep' 데이터베이스라고 볼 수 있다. 기본적으로 Cscope 는 C, lex, yacc 파일만을 (.c, .h, .l, .y) 현재 디렉토리에 대해서 (하위 디렉토리는 '-R' 플래그를 줄 때) 구문 분석하며, 현재로서는 구문 분석 대상 확장자 목록을 바꿀 방법이 없다. 그래서 대신에 구문분석하고자 하는 파일 목록을 'cscope.files' 라는 이름의 ㅇ파일을 만든다. (다른 이름을 붙이고 'cscope -i foofile' 이라고 해도 된다.) 파일 목록을 만드는 쉬운 (그리고 유연한) 방법은 믿음직한 다음과 같이 유닉스 'find' 유틸리티를 쓰는 것이다.
     find . -name '*.java' > cscope.files 
    이제 cscope -b 로 데이터베이스를 다시 만들면 ('-b' 는 데이터메이스를 만들기만 하고 Cscope GUI 를 시작하지 않는다.) 모든 Java 파일에 대한 이름들을 탐색할 수 있게 된다. 큰 규모의 문서 파일들을 탐색하고 편집하는 데 cscope 를 쓰는 친구들이 있다는 이야기도 있을 정도로 Cscope 구문 분석기는 유연하다. 

    더 큰 프로젝트에는 추가로 '-q' 플래그나 더 복잡한 'find' 명령어를 쓸 필요가 있을지 모른다. 더 많은 정보를 얻으려면 [http]큰 프로젝트에서 Cscope 사용에 대한 강좌를 보라. 

  11. $CSCOPE_DB 환경변수를 만들어진 Cscope 데이터베이스를 가리키게 해보라. 그러면 매번 Vim 을 똑같은 디렉토리로 찾아가 띄울 필요가 없다. 이것은 특히 프로젝트가 여러 개의 하위 디렉토리로 나뉘어 있을 때 유용하다. <!> 주의: 이것이 동작하기 위해서는 데이터베이스를 다음과 같이 절대 경로로 생성해야 한다.
     find /my/project/dir -name '*.c' -o -name '*.h' > /foo/cscope.files 
    그리고 Cscope 를 cscope.files 가 있는 디렉토리로 가서 실행하고 (또는 'cscope -i /foo/cscope.files'), $CSCOPE_DB 변수를 cscope.out 결과 파일을 가리키도록 다음과 같이 설정하고 export 하라.
     cd /foo cscope -b CSCOPE_DB=/foo/cscope.out; export CSCOPE_DB    
    (마지막 명령은 Bourne/Korn/Bash 쉘을 위한 것이다. 나는 csh 기반 쉘을 전염병 피하듯 하기 때문에 거기서는 어떻게 export 하는지 잊어버렸다.) 

    이제 기계의 어떤 디렉토리에서든지 'vim -t foo' 라고 실행하면 'foo' 가 정의된 곳으로 바로 이동한다. 나는 프로젝트별로 작은 쉘 스크립트를 만들어 (CSCOPE_DB 를 설정하고 export 하기만 하도록) 'source projectA' 라는 명령으로 프로젝트간에 작업 전환할 때마다 실행하곤 한다. 

    벌레: Cscope 15.4 이전의 판에는, 데이터베이스 이름을 기본설정인 'cscope.out' 이외에 다른 것으로 하지 않으면 Vim 이 멈춰버릴 수도 있는 바보 같은 벌레가 있다. Cscope 를 부를 때 '-f foo' 로 데이터베이스 이름을 'foo.out' 로 대체하면 괜찮다. 

  12. 이게 끝이다. 궁금한 것이 있다면 ":help cscope" (Vim에서) 와 "man cscope" (쉘에서) 중 하나 또는 두 개 다 해보아서 세세한 점들을 찾아보라. 
출저: KLDP wiki http://wiki.kldp.org/wiki.php/VimCscopeTutorial    
참고:  cscope 튜토리얼 http://cscope.sourceforge.net/cscope_vim_tutorial.html

' > 개발' 카테고리의 다른 글

Vim 명령어 리눅스/안드로이드  (0) 2011.12.09
Make  (0) 2011.09.29
VIM 환경설정 파일  (0) 2011.09.01
taglist - vim용 코드 브라우저  (0) 2011.09.01
VI 가이드 문서  (0) 2011.08.30
CScope - 함수 및 변수 호출 검색  (0) 2011.08.30
Posted by 라판
리눅스 커널 맵. 

 커널의 System Call을 기능별, 레벨별로 정리 해 놓았으며 시스템콜 간의 상관관계를 
지도로 표현 해 놓았다. 맵에서 특정 시스템콜을 클릭하면 해당되는 시스템콜의
레퍼런스로 이동되도록 되어 있다.

 출저 - http://www.makelinux.net/kernel_map/
Posted by 라판