find ./ -name '.svn' | xargs rm -rf
find /home -name error_log -exec rm -f {} \;
find ./ -name '.svn' | xargs rm -rf
find /home -name error_log -exec rm -f {} \;
make는 사실 과도하게 복잡합니다.
생성될 타겟에 의존적인 파일들을 자동으로 찾아주는 것도 아니고, 빌드 옵션을 자동으로 생성해주는 것도 없고 거의 모든 것을 직접 작성해야합니다.
사실 너무나 오래전에 만들어진 툴이다보니 편의성면에서는 많이 부족한게 사실입니다.
이런 단점들을 극복하고자 make을 자동으로 생성해주는 툴이 많이 나오고 있습니다.
리눅스/유닉스 환경에서는 autotools가 가장 많이 쓰인다고 하지만 autotools자체도 make보다 많이 편리하지는 않고 배우는 것조차 일입니다.
최근에는 autotools의 대안으로 파이썬기반의 SCons나 Waf도 많이 사용되고 있고, 멀티플랫폼을 지원하며 KDE에서 사용되는 것으로 유명해진 cmake도 많이 사용되고 있습니다.
이번 장에서는 configure나 make는 전혀 사용하지 않고 cmake만으로 빌드하고 테스트를 실행해보겠습니다.
cmake를 사용하기 위해서는 CMakeLists.txt라는 파일을 만들어서 cmake에게 명령을 내려야합니다.
우리가 빌드할 파일은 크게 라이브러리 파일과 유닛테스트 파일로 나눌 수 있으므로
CMakeLists.txt src/CMakeLists.txt test/CMakeLists.txt 등으로 3개의 CMakeLists.txt파일을 만들겠습니다.
cmake는 기본적으로 변수를 설정하고 cmake가 제공하는 함수에 설정된 변수를 전달하는 형태가 많이 사용됩니다.
라이브러리에 들어갈 소스 파일들의 이름을 변수에 저장하고 라이브러리를 빌드하는 함수에 이 변수를 전달하면, 자동으로 해당 파일들을 찾아서 라이브러리로 빌드합니다.
실행 파일을 만들 때도 실행 파일에 들어갈 소스 파일 이름과 실행 파일의 이름을 빌드 함수에 전달하면 실행 파일을 빌드합니다.
기본적인 사용법은 아주 간단하므로 예제 파일을 보면서 자세한 설명을 하겠습니다.
가장 먼저 만들 파일은 소스에서 최상위 디렉토리에 있는 CMakeLists.txt입니다.
이 파일은 다른 모든 빌드 과정에서 사용될 변수들을 설정하고 하위 디렉토리에있는 CMakeLists.txt파일을 읽어오는 일을 합니다.
CMAKE_MINIMUM_REQUIRED (VERSION 2.6)
cmake 버전을 2.6이상만 사용합니다. 제가 테스트한 버전은 2.8입니다.
PROJECT (calib_project)
프로젝트 이름입니다. 원하는 이름 아무거나 할 수 있습니다.
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET 함수는 변수를 만들거나 변수의 값을 설정하는 일을 합니다.
cmake로 빌드를 하면 기본적으로 컴파일 명령이 출력되지 않고 빌드가 완료되었는지만 알려줍니다.
그래서 CMAKE_VERBOSE_MAKEFILE 변수를 ON으로 설정해서 어떤 옵션으로 컴파일되고 있는지 확인할 수 있게합니다.
if ("${build}" MATCHES "debug")
SET (CMAKE_BUILD_TYPE "debug")
else ("${build}" MATCHES "debug")
SET (CMAKE_BUILD_TYPE "release")
endif ("${build}" MATCHES "debug")
cmake를 실행할 때 -D옵션으로 cmake에게 변수 값을 전달할 수 있습니다.
cmake -D build=debug 형태로 cmake를 실행하면 build라는 이름의 변수를 만들어서 cmake에게 전달할 수 있습니다.
CMAKE_BUILD_TYPE 변수는 cmake에 내장된 변수입니다.
cmake는 이 변수의 값을 확인해서 디버그 모드로 빌드할 것인지 릴리즈 모드로 빌드할 것인지를 판단합니다.
if가 처음 사용되었으므로 간단하게 설명하겠습니다.
cmake에서는 문자열의 비교를 MATCHES로 처리합니다.
그리고 else와 endif에 if에서 사용된 표현식을 다시한번 써줍니다.
그 외에는 기본적인 if-else와 같습니다.
ADD_DEFINITIONS(-DCALIB_CFG_BUILD_MODE="${CMAKE_BUILD_TYPE}")
컴파일 옵션에 추가될 매크로 정의는 ADD_DEFINITIONS함수로 지정합니다.
src/build_info.c에 CALIB_CFG_BUILD_MODE값이 필요하므로 매크로 상수를 만들었습니다.
if ("${bit}" MATCHES "32")
ADD_DEFINITIONS(-DCALIB_CFG_COMPILE_BIT=32 -m32)
SET (CMAKE_EXE_LINKER_FLAGS -m32)
else ("${bit}" MATCHES "32")
ADD_DEFINITIONS(-DCALIB_CFG_COMPILE_BIT=64 -m64)
SET (CMAKE_EXE_LINKER_FLAGS -m64)
endif ("${bit}" MATCHES "32")
빌드 비트를 확인하는 부분입니다.
빌드 모드와 마찬가지로 cmake의 실행 옵션으로 bit변수에 값을 설정합니다.
이 값에 따라 컴파일 비트와 링크 비트를 설정합니다.
ADD_DEFINITIONS 함수는 원래 매크로 상수를 추가하는 함수인데 편의상 컴파일 옵션도 이 함수를 이용해서 추가했습니다.
CMAKE_EXE_LINKER_FLAGS는 실행 파일을 만들 때 링커가 사용할 옵션이 저장된 변수입니다.
SET 함수를 사용해서 -m32나 -m64 옵션을 추가합니다.
ADD_DEFINITIONS(-Wall -DCALIB_CFG_OS="${CMAKE_SYSTEM_NAME}" -DCALIB_CFG_CPU="${CMAKE_SYSTEM_PROCESSOR}")
CMAKE_SYSTEM_NAME과 CMAKE_SYS_PROCESSORS은 각각 운영체제 이름과 프로세서 정보를 가지고있는 내장 변수입니다.
configure를 사용하지 않는 대신에 cmake가 가진 정보를 사용합니다.
ADD_SUBDIRECTORY(src)
src/CMakeLists.txt를 처리합니다.
ADD_SUBDIRECTORY(test)
test/CMakeLists.txt를 처리합니다.
이제 소스를 빌드해서 라이브러리를 만드는 src/CMakeListst.txt를 분석하겠습니다.
SET (LIBRARY_OUTPUT_PATH ../lib)
빌드된 라이브러리가 저장될 디렉토리입니다.
INCLUDE_DIRECTORIES (../include)
소스 빌드에 필요한 헤더 파일이 저장된 디렉토리입니다.
SET (LIBSRCS sys_info.c build_info.c)
소스 파일의 리스트입니다.
CMAKE_MINIMUM_REQUIRED (VERSION 2.6)
PROJECT (calib_project)
# set dir to store library
SET (LIBRARY_OUTPUT_PATH ../lib)
# set dir for header
INCLUDE_DIRECTORIES (../include)
# sources
SET (LIBSRCS sys_info.c build_info.c)
# build libcalib.a with LIBSRCS sources
ADD_LIBRARY (calib STATIC ${LIBSRCS})
라이브러리를 빌드하는 함수 ADD_LIBRARY를 호출합니다. c
alib은 라이브러리의 이름이고 STATIC은 정적 라이브러리로 빌드하라는 의미입니다.
SHARED로 지정하면 공유라이브러리를 빌드합니다.
다음은 유닛테스트를 빌드하는 test/CMakeLists.txt입니다.
ENABLE_TESTING ()
cmake는 유닛테스트를 위해 ctest라는 독립적인 툴을 가지고있습니다.
cmake로 실행파일을 빌드하면 ctest로 실행과 각종 테스트를 진행하게됩니다.
ctest를 사용하겠다는 의미로 ENABLE_TESTING 함수를 호출합니다.
INCLUDE_DIRECTORIES (../include)
헤더 파일의 디렉토리 설정입니다.
ADD_EXECUTABLE (test_build_info test_build_info.c)
ADD_EXECUTABLE은 어떤 소스를 가지고 어떤 실행 파일을 만들지를 지정합니다. test_build_info.c를 가지고 test_build_info 실행파일을 빌드합니다.
TARGET_LINK_LIBRARIES (test_build_info calib)
test_build_info를 빌드할 때 calib라이브러리를 링크합니다.
ADD_EXECUTABLE (test_build_info test_build_info.c)
TARGET_LINK_LIBRARIES (test_build_info calib)
test_build_info의 빌드와 동일합니다.
test_sys_info.c 소스와 calib 라이브러리를 가지고 test_sys_info라는 실행 파일을 빌드합니다.
ADD_TEST (unittest1 test_build_info)
ADD_TEST (unittest2 test_sys_info)
ADD_TEST함수는 ctest가 실행할 유닛테스트 파일을 지정합니다.
첫번째 인자는 테스트의 이름이고 두번째 인자는 실행 파일입니다.
모든 CMakeLists.txt파일을 작성했으면 다음 명령을 실행해서 Makefile을 만들고 빌드를 실행합니다.
$ cmake -D build=debug -D bit=64 CMakeLists.txt
$ make
유닛테스트를 실행하기 위해서는 cmake test 명령을 내리거나 ctest를 실행하면 됩니다.
$ cmake test
$ ctest
cmake test를 실행하면 유닛테스트가 정상적으로 실행되었다는 메시지만 출력됩니다.
유닛테스트에서 출력한 메시지를 확인하고 싶다면 ctest -V나 ctest --debug 명령을 실행하면 됩니다.
ctest는 실행 파일의 최종 반환값이 0이면 테스트 성공으로 인식하고 그 외의 값을 반환하면 실패로 인식합니다.
CMakeLists.txt를 다시 만들었을때는 CMakeCache.txt를 지우고 cmake를 다시 실행합니다.
$ rm CMakeCache.txt
# gzip -dc abc.tar.gz | tar -tvf -
# sudo su
# apt-get install mysql-server mysql-client
# apt-get install lighttpd
# apt-get install php5-fpm php5-cgi php5-mysql php5
# vim /etc/php5/fpm/php.ini
;주석 해제cgi.fix_pathinfo=1 |
# vim /etc/lighttpd/conf-available/15-fastcgi-php.conf
fastcgi.server += ( ".php" => (( "socket" => "/var/run/php5-fpm.sock", "broken-scriptfilename" => "enable" )) ) |
# lighttpd-enable-mod fastcgi
# lighttpd-enable-mod fastcgi-php
# /etc/init.d/lighttpd force-reload
# vim /etc/php5/fpm/pool.d/www.conf
;주석해제 listen.owner = www-data listen.group = www-data listen.mode = 0660 |
# service php5-fpm restart
vi는 BSD의 C shell을 개발한 빌 조이가 1976년에 ed의 기능을 확장시킨 ex(Extended editer)편집기를 개발 하고 이를 확장 시켜서 만들었다. <<유닉스.리눅스 프로그래밍 필수 유틸리티>>
※vi는 Visual editer의 줄임이다.
즉 ex모드에서 입력모드로 가기위해서는 명령모드를 거쳐서 가야한다. 모드라고해서 거창한것은 없다. 단지 "ESC" 키 를 한번 누르는것이 전부다.
잘라내기를 이해하기위해서는 vi의 레지스터를 알아야 한다. vi는 총 17개의 레지스터를 가지고 있다. 일단 삭제명령으로 지운 글자들은 순서대로 레지스터로 이동한다. 그러므로 p를 눌러주면 삭제된 글자들이 붙여넣기가 된다.
윈도우에서 말하는 클립보드와 같은것이다.
vim은 정말 알면 알수록 재미있고 신기한 에디터인것 같다. 소개할 window split기능은 여러가지로 재미있게 이용할 수 있을것이다. 아래에서 부터는 ^는 "ctrl 키와 함께 누름" 을 의미한다.
:sp filename
커서를 파일 이름위에 대고 ^wf
:set mouse=a
:TOhtml
:!ls
쉘에서 ls를 친것과 같은 기능을 한다.
:r filename
이런방법도 있음
:r !ls
windows 에서 vim 사용시 초기화 파일은 자기 홈디렉토리에 "_vimrc" 파일을 생성하여 넣어놓으면 된다. 즉 나의 경우는
"C:\Documents and Settings\김성환" 폴더에 "_vimrc"파일을 넣어두었다.
그렇지 않으면 vim이 설치된 폴더 c:\Program Files\Vim\ 에다가 넣어도 된다.
_vimrc 파일을 설정하는법은 쉽다.
-----------------------_vimrc 파일의 내용-------------------------
set nu
set autoindent
set backspace=indent,eol,start
set ruler
syntax on
set incsearch
------------------------------------------------------------------
이렇게 넣어두었다.
set nu 는 라인의 번호를 출력하라는 명령이고
set autoindent 는 자동 들여쓰기기능
set backspace=indent,eol,start 는 처음에 vim을 설치했을때 backspace를 눌러도 글자가 지워지지 않고 커서만 이동했는데 이 명령후에는 일반 윈도우의 메모장이나 한글프로그램처럼 동일하게 작동한다.
set ruler 는 우측하단에 현재 커서의 위치를 표시해주게된다.
syntax on 은 자동으로 파일을 인식하여 색을 입혀주는 기능이 활성화 되는기능이다.
가. c:\Program Files\vim\_vimrc 파일을 연다.
나. 아래와 같이 입력
------------------ _vimrc --------------------
: colorscheme torte
----------------------------------------------
가. c:\Program Files\vim\_vimrc 파일을 연다.
나. 아래와 같이 입력
------------------ _vimrc --------------------
set guifont = 나눔고딕코딩:h14:cHANGEUL
----------------------------------------------
" ---- language-env DON'T MODIFY THIS LINE!
""" ========================================================
""" 기본적인 설정들
""" ========================================================
set nocompatible " Vim 디폴트 기능들을 사용함
set backspace=2 " 삽입 모드에서 백스페이스를 계속 허용
"set autoindent " 자동 들여쓰기
set cindent " C 언어 자동 들여쓰기
set smartindent " 역시 자동 들여쓰기
"set textwidth=76 " 76번째 칸을 넘어가면 자동으로 줄 바꿈
set nowrapscan " 찾기에서 파일의 맨 끝에 이르면 계속하여 찾지 않음
"set nobackup " 백업파일을 만들지 않음
set novisualbell " 비주얼벨 기능을 사용하지 않음
set nojoinspaces " J 명령어로 줄을 붙일 때 마침표 뒤에 한칸만 띔
set ruler " 상태표시줄에 커서 위치를 보여줌
set tabstop=4 " 간격
set shiftwidth=4 " 자동 들여쓰기 간격
"set keywordprg=edic " K를 눌렀을 때 실행할 명령어
set showcmd " (부분적인) 명령어를 상태라인에 보여줌
set showmatch " 매치되는 괄호의 반대쪽을 보여줌
set ignorecase " 찾기에서 대/소문자를 구별하지 않음
set incsearch " 점진적으로 찾기
set autowrite " :next 나 :make 같은 명령를 입력하면 자동으로 저장
set title " 타이틀바에 현재 편집중인 파일을 표시
""" ========================================================
""" 파일 인코딩을 한국어로 설정
""" ========================================================
if $LANG[0] == 'k' && $LANG[1] == 'o'
set fileencoding=korea
endif
""" ========================================================
""" 터미널에 따른 설정 : Xterm이면 16컬러 사용
""" ========================================================
if &term =~ "xterm-debian" || &term =~ "xterm-xfree86"
set t_Co=16
set t_Sf=^[[3%dm
set t_Sb=^[[4%dm
set t_kb=?
fixdel
endif
""" ========================================================
""" 문법 강조기능 사용
""" ========================================================
if has("syntax")
"syntax on
syntax off
endif
""" ========================================================
""" GUI 모드로 실행할 경우
""" ========================================================
if has("gui_running")
set visualbell " 비주얼벨 기능 사용
set hlsearch " 찾는 단어를 하이라이팅
set guifontset=-*-fixed-medium-r-normal--14-*-75-75-*-70-iso8859-1,
-*-gulim-medium-r-normal--14-140-75-75-*-140-ksc5601.1987-0
endif
screen 은 한 터미널로 한번만 로그인 한후에 여러 쉘과 프로그램을 사용할 수 있습니다.
또한 세션관리 기능도 지원 한답니다.
그래서 screen 을 종료하고 심지어 터미널까지 로그아웃하고 종료 하여도 세션이 유지 되고 있습니다.
다음에 다시 터미널로 로그인후 screen으로 세션을 불러와서 다시 이전 작업을 이어서 할 수 있습니다.
(nohup가 필요없으려나...?)
그럼 screen 명령에 대한 설명을 시작 합니다.
1. 쉘모드 명령어
screen
: screen 을 시작 하는 기본 명령입니다.
: 기본 세션명으로 시작합니다.
screen -S 세션명
: -S 다음에 주는 세션명으로 시작합니다.
screen -list
: -list 옵션을 주고 실행하면 이전에 작업했었던 screen 리스트가 있으면 세션명과 함께 리스트를 보여줍니다.
screen -R 세션명
: 이전에 세션이 있을 경우 -R 다음에 오는 세션명으로 이전 작업을 불러옵니다.
: -R 다음에 세션명을 주지 않았을 경우에는 이전 세션이 한개만 있을 경우 그 작업을 불러옵니다.
: 이전 작업이 여러개 있을 경우에는 이전 작업 리스트를 보여줍니다.
: 이 경우에는 원하는 세션명을 주고 시작 하면 되겠죠. ^__^
2. screen 실행후 명령어
screen 실행후의 명령어는 Ctrl-a로 시작합니다:
Ctrl-a, c : (create) 새로운 쉘이 생기면서 그 쉘로 이동
Ctrl-a, a : 바로 전 창으로 이동
Ctrl-a, n : (next) 다음 창으로 이동
Ctrl-a, p : (previous) 이전 창으로 이동
Ctrl-a, 숫자 : 숫자에 해당하는 창으로 이동
Ctrl-a, ' : 창번호 또는 창이름으로 이동 ( ' => 싱글 쿼테이션 )
Ctrl-a, " : 창번호를 보여준다. ( " => 더블 쿼테이션 )
Ctrl-a, A : 현재 창의 title을 수정
Ctrl-a, w : 창 리스트 보여주기
Ctrl-a, esc : Copy 모드로 전환. Copy 모드에서는 vi의 이동키로 이동을 할 수 있다.
Crtl-a, [ 커서 이동을 할 수 있고 특정 블럭을 복사하는 기능으로 사용한다.
먼저 시작 위치에서 space 바를 누르고 끝 위치에서 space 바를 누르면 해당 부분이 buffer로 복사된다.
Ctrl-a, ] : buffer의 내용을 stdin으로 쏟아 넣는다.
이 기능은 vi의 입력모드에서 사용하면 유용하다.
Ctrl-a, :(콜론) : 명령행 모드로 전환
Ctrl-a, d : (detach) 현재 작업을 유지하면서 screen 세션에서 빠져나옴
세션이 종료 되지 않습니다.
Ctrl-a, x : lock screen
아래 부분은 창을 나눠서 사용하는 명령입니다.
Ctrl-a, S : (split) 창을 나눔 (region)
Ctrl-a, Tab : 다른 region으로 이동
Ctrl-a, Q : 현재 region을 제외한 나머지 숨기기
그리고 마지막 명령으로 세션을 완전히 빠져 나오는 명령입니다.
exit : screen 의 쉘상에서 exit 를 치고 엔터를 하면 세션이 완전히 종료 됩니다.
참 고
screen 화면을 2, 3 개정도 띄우고 사용하는게 가장 적당하다고 합니다.
일단 제 주 환경은 Ubuntu Server (Vim)와 Mac(MacVim, Vim) 입니다. Windows 환경에서 작업하지 않은지 몇년이 되어서, Windows에서 이하 내용이 정확히 돌아가는 가에 대한 확신이 없습니다. 참고해주세요. 요즘 매우 유용하게 쓰고 있어서 추천 안할수가 없네요. 카테고리는 마땅치 않아 강좌로 세팅합니다.
Vim을 사용하면서 최근 몇년 사이에 인상깊은 발전을 보고 정리겸 공유하고 싶어서 입니다. 그럼 시작합니다.
vim 명령을 내리면 펼쳐지는 심심한 화면 때문에 잘 인지할 수 없지만, 요 몇년간 Vim 은 다른 에디터 처럼 꾸준히 발전해 왔습니다. 버전 숫자 하나가 올라갈때 마다 수많은 버그와 개선이 이루어지곤 했죠. 특히 2006년에 메이저 버전이 업그레이드 되면서 등장한 Vim 7.x 부터 내부 스크립트에서 자료형을 지원하면서, 외부 스크립트에 의존하지 않고 Vim 의 스크립팅만으로 괜찮은 플러그인을 만들수 있는 환경이 갖추어졌습니다. (그래요.. 그전에는 emacs를 조금이라도 흉내내려면, 외부 스크립의 도움을 받아야 했습니다.)
그리고 2010년에 이르러 Rails 커뮤니티 맴버들이 Vim의 플러그인 생태계에 가담하면서 재미있는 프로젝트가 생겼는데, 그게 Plugin manager 로 발전하였습니다. 전 바로 이 플러그인 메니저들 중 가장 멋진 작품이 되어 가고 있는 vundle 을 소개하려 합니다.
개개인의 Vim 플러그인은 다음의 구조를 가집니다.
~/.vim ├── after ├── autoload ├── backups ├── colors ├── doc ├── ftdetect ├── ftplugin ├── indent ├── lib ├── plugin ├── syntax └── undos
각각의 폴더는 vim이 실행되면서 이루어지는 일종의 콜백 위치라고 생각하면 됩니다. 따라서, 멋진 플러그인일 수록 각 콜백에 적합한 위치에 여러 소스가 퍼지는 형태로 제작됩니다. 이를 배포하기 위해서, Vim 커뮤니티의 Charles E. Campbell, Jr.는 Vimball Archiver(이하 vba) 라는 방식을 제시합니다. 언제 통합되었는지는 모르겠지만, vba 는 Vim 플러그인 인스톨러 포맷 같은겁니다. Vim 플러그인은 모두 텍스트로 구성되어 있기 때문에, 각 파일들을 저장할 위치를 명시해서 하나의 파일에 통합해서 배포하는 것이죠.
자세한 내용은 Vim 에서 볼수 있습니다.
:help vba
그래서 vim online 에서 스크립트를 찾으면 vba 파일을 종종 볼수 있습니다. 이 파일은 vim 내에서 실행하는 것만으로 설치가 가능합니다. 그런데 아무리 vba로 플러그인을 편하게 설치해도, 배포 환경이 불러오는 문제는 해결되지 않습니다. 일단 소스가 여러 디렉토리로 퍼저서 플러그인 단위로 버전 관리하기가 힘듭니다. 자동 업그레이드는 따위는 생각하기 힘들죠. 그리고 vba 패키징이 생각보다 귀찮아요.
그런데 Rails 커뮤니티의 인원들이 TextMate에서 적극적으로 vim으로 이주(?)하기 시작하면서, 그 중 일부가 재미있는 일을 시작합니다. 처음에는 단순히 Rake (Ruby계의 Make)를 이용해서 자신이 좋아하는 플러그인을 자동 설치해주는 시스템이 등장합니다. 이런 플러그인 공유가 등장한후 얼마 지나지 않아서, Rails 세상의 라이브러리 패키징 방식(주1)과 Bundler라는 라이브러리의 아이디어를 vim으로 가지고 와서 불편한 플러그인 배포 환경을 개선합니다.
배포 환경 개선의 포인트는 각각의 플러그인별로 ~/.vim 내에 디렉토리로 격리 시켜 버리는 겁니다. 이런 식으로 말이죠.
~/.vim ├── after ├── autoload ├── backups ├── bundle │ ├── Align │ │ ├── autoload │ │ ├── doc │ │ └── plugin │ ├── FuzzyFinder │ │ ├── autoload │ │ │ └── fuf │ │ ├── doc │ │ └── plugin │ ├── The-NERD-Commenter │ │ ├── doc │ │ └── plugin │ ├── The-NERD-tree │ │ ├── doc │ │ ├── nerdtree_plugin │ │ └── plugin --------(생략)--------------- ├── colors ├── doc ├── ftdetect ├── ftplugin ├── indent ├── lib ├── plugin ├── syntax └── undos
이렇게 구성해놓고 vim 을 정상 동작하도록 하는 녀석이 바로 pathogen.vim(: manage your runtimepath) 입니다. Vim 의 런타임 패스를 조작하는 방식이죠. (참고로 이 플러그인의 개발자인 tpope's Profile - GitHub 를 보시면 정말 굉장합니다. 특히, Rails 개발자에게 이 아저씨가 만든 vim-rails 는 예술입니다.)
자 이렇게 만드는 것만으로, Vim 플러그인 개발과 공유는 매우 쉽게 되었습니다. 이게 2010년 입니다. 더불어서 이때가 github 이 등장하면서 이 위에서 오픈소스로 vim 플러그인 개발이 매우 용이해 졌습니다. 그냥 ~/.vim/bundle 밑에 git clone 하는 것으로 플러그인을 설치하고 개발할 수 있거든요. 최근 Vim 플러그인에 관심을 가진 분이라면 pathogen.vim 이 심심치 않게 등장하는 걸 볼수 있을 겁니다. 여기까지만 써도 기존 플러그인 보다 정말 혁신적인 환경을 사용할 수 있습니다.
그런데 개선은 여기에서 멈추지 않습니다.
이 시기에 github 가 폭풍처럼 인기를 끌기 시작합니다. (현재 github의 커밋 숫자는 sf, google code를 합친 숫자를 훨씬 뛰어 넘습니다.)
우선 위에 잠깐 등장한 등장한 Ruby 세상의 Bundler 라이브러리의 역할을 조금 자세히 소개해야 겠습니다. 이 녀석은 지정된 라이브러리를 공용 저장소 서버에서 가지고 와서 설치히고 패키징도 하는 역할을 합니다. 그런데 이 저장소를 정해진 서버가 아니라 라이브러리 단위로 git으로 노출된 서버를 지정할 수 있는 강력한 특징이 있습니다. 즉, 네트웍이 연결된 git 저장소에서 소스를 들고와서 이를 라이브러리로 패키징 하는 개념이죠. 주소 변경 만으로 개발 버전과 제품 버전을 바꾸어서 패키징하는 등 많은 이점이 있습니다.
git을 배포 저장소로 하는 이득이 너무 커서, Rails 세상에서는 소스 서버 대상을 아예 git으로 타케팅 해버리는게 일상화 되어 버립니다.
이런 git을 통해서 배포하는 Bundler의 아이디어와 Vim 의 런타임 패스를 조작해서 플러그인 배포 환경을 개선한 pathogen 에서 영감을 얻어 만들어진 'Vim Plugin Manager'가 바로 마지막에 소개하는 vundle.vim 입니다.
즉, vundle.vim 은 모든 플러그인을 특정 웹사이트( http://vim-scripts.org ) 에 담긴 인덱스와 git 저장소 정보를 바탕으로 마치 애플의 앱스토어 처럼 플러그인을 설치하는 통합 환경을 Vim에 제공합니다. 그리고 플러그인 단위로 다른 git 저장소를 지정해서 설치할 수도 있습니다. 아래 활용의 스크린샷을 참고하세요.
Vim Scripts에서 vundle.vim 과 이와 동일 역할을 하는 다른 도구들을 찾을 수 있습니다.
vundle의 설치 단계는 다음 문서를 참고하세요.
vundle 은 플러그인 자체를 관리하는 플러그인 입니다. 설치 방법은 위에 잘나와 있으니 생략하고 간단히 제가 사용하는 과정을 첨부합니다.
만약 제가 새로운 vim 플러그인을 설치하려면 일단 Google이나 scripts : vim을 검색합니다. 그리고 이름을 알아내죠.
이번에 저는 Align 라는 녀석을 설치하려 해요. 일단 vundle 이 지원하는지 확인합니다.
:BundleSearch
그러면 vundle 을 이용해서 설치할수 있는 리스트가 나옵니다. 이 리스트는 Vim Scripts 의 인덱스를 기본으로 합니다. 참고로 해당 사이트는 여전히 개선 중입니다. (아직 추천이나 검색이 없습니다.)
여기에서 검색! Align가 있네요. 오호! 제 vim 설정 파일을 엽니다.
:vs $MYVIMRC
이제 왼쪽에서 찾은 플러그인 한줄을 오른쪽의 제 $MYVIMRC 에 복사합니다. (리스트에서 I를 누르면 그냥 설치는 됩니다. 문제는 관리를 위해서 리스트에 추가시켜 주는 겁니다.)
그리고 나서
:BundleInstall
이러면, 네트웍을 통해서 소스를 가지고와서 설치하고 도움말을 위한 인덱스 생성까지 깔끔하게 마무리 해줍니다.
BundleSearch -> $MYVIMRC 에 원하는 라인 복사 -> BundleInstall
어때요 사용 방법이 참 쉽죠(?)
(과거를 생각해 보세요. 일단 찾아서 웹사이트에서 다운을 받은후 이게 text인지, zip인지 vba인지 파악한 후, 터미널 열어서 zip이면 cp로 적절한 위치에 복사하고 vba면 실행하고, vim help 뒤져서 플러그인의 도움말을 위한 tag를 만들주는 명령을 실행하면 완료입니다. 헉헉..)
Vim Scripts 측은 기존의 scripts : vim 를 모두 github 에 미러링 해두어서 대부분의 플러그인은 무리 없이 찾을수 있습니다. 스크린샷 오른쪽의 16라인을 보시면 저런식으로 각 플러그인의 소스 저장소를 git으로 직접 명시할 수도 있습니다.
그리고 플러그인이 마음에 들지 않는다면 $MYVIMRC (.vimrc) 에서 해당 플러그인 라인을 제거하고 다음을 실행합니다.
:BundleClean
이 명령어는 위 스크린샷 오른쪽 편에 Bundle "plugin-name" 으로 기술되지 않은 플러그인을 일괄 삭제합니다. (역시 과거를 생각해 보세요. find, grep rm 신공을 이용해서 손수 찾아서 삭제해야 합니다.)
좀 더 자세한 건 도움말을 참고하세요.
:help vundle
저는 Client, Server 에서 여러 곳에서 동일 개발 환경을 유지하기 위해서 개인 정보를 제외한 모든 개발 환경 정보를 소스 저장소를 통해 관리합니다. (예전에는 Google code, 지금은 github 입니다. 악성 사용자일까요? ) 소스를 체크 아웃하고 필요한 것만 심볼릭 링크 걸어서 쓰는 방법을 즐깁니다. (체크 아웃 빼고는 모두 자동화 되어있습니다. )
그런데 vundle 을 사용하기 전에는 vim 의 모든 플러그인을 함께 넣어 두었습니다. 여기
~/.bash_settings/ ├── .bashrc ├── .bashrc_mac ├── .ctags ├── .gemrc ├── .git --------(생략)---------- ├── .irbrc ├── .screenrc ├── .scripts ├── .vim <- 여기에 모든 플러그인 파일을 담아 두었습니다. ├── .vimrc --------(생략)---------- └── setup.rb
vundle 적용후 대부분의 큰 플러그인들은 vundle을 통해 일괄 설치하고, 자작이나 커스텀 플러그인만 넣어두고 관리합니다. vundle의 사용을 알면 이제 .vimrc 파일 하나만 들고 다녀도 동일 플러그인 환경을 언제든 구성할 수 있게 됩니다.
Got Xcode?
You're gonna need it. Open the App Store and download Xcode. Yeah, it's 1.6+ GB, and yeah, it's going to take a couple hours. Once you've installed it, make sure to install the command-line tools. Open Xcode, then go to Preferences -->Downloads and install the "Command Line Tools." It'll download and install another 100+ MB of stuff, but it's necessary. Once that's done, you're ready to continue.
Install Homebrew
In case you haven't already, install Homebrew by following the instructions at the bottom of this page.
Homebrew's most legit PHP "tap" (package source) is by Jose Gonzalez. Make sure to install it:
$ brew tap josegonzalez/homebrew-php
We also need a tap for a PHP 5.4 dependency, zlib:
$ brew tap homebrew/dupes
Install MySQL
$ brew install mysql
It'll chew on that for a few minutes, then we need to get it to run as our user account:
$ unset TMPDIR
$ mysql_install_db --verbose --user=`whoami` --basedir="$(brew --prefix mysql)" --datadir=/usr/local/var/mysql --tmpdir=/tmp
I got a "Warning" during this operation, and while I don't think it's critical, I did this and things have seemed to work fine... if you got a warning during the last step, then you could do this:
$ sudo mv /usr/local/opt/mysql/my-new.cnf /usr/local/opt/mysql/my.cnf
Then, to launch MySQL at startup:
$ cp `brew --prefix mysql`/homebrew.mxcl.mysql.plist ~/Library/LaunchAgents/
$ launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist
Done! Next: the web server.
Install nginx
$ brew install nginx
Let that stew, then run these commands to have nginx run as root at startup (so we can listen on port 80, the default, instead of 8080 which is less convenient for development):
$ sudo cp `brew --prefix nginx`/homebrew.mxcl.nginx.plist /Library/LaunchDaemons/
$ sudo sed -i -e 's/`whoami`/root/g' `brew --prefix nginx`/homebrew.mxcl.nginx.plist
(Okay, to be honest, this didn't work for me to load nginx right away on start; I had to edit the /Library/LaunchDaemons/homebrew.mxcl.nginx.plist file and remove the two lines that specify the UserName key and value (one line specifies the key, the other the value). Then it worked.)
Then create a log file... this allows us to view server logs in the Mac Console, which is really convenient, but isn't required:
$ sudo mkdir /var/log/nginx/
(Don't forget to tell nginx to put the log file there in nginx.conf: error_log /var/log/nginx/error.log;)
Done! Next up: PHP.
Install PHP
$ brew install --without-apache --with-fpm --with-mysql php54
Make sure to change "php54" to whatever version you want. At time of writing, PHP 5.4 is the latest stable, but PHP 5.5 is in alpha. I assume 5.5 would be php55, etc. Be sure to adjust any following commands with the proper version number.
Quick note: Yes, OS X does come with PHP pre-installed. But we don't want to use that. We need an install we can use with nginx and FastCGI Process Manager (fpm). Plus, we want the latest version, and I'm just not that into compiling from source.
To run php-fpm at startup:
$ sudo cp `brew --prefix php54`/homebrew-php.josegonzalez.php54.plist /Library/LaunchAgents/
$ sudo launchctl load -w /Library/LaunchAgents/homebrew-php.josegonzalez.php54.plist
Done! Next up: configuration.
Finishing up
I want all php commands to be using the latest version, not the default PHP binary. So I use this little trick to create a symlink from the default PHP binary to the new one... I do this for both php and php-fpm. If you're confused about which versions are where, use the "whereis" command, like: "whereis php".
$ php-fpm -v
$ sudo mv /usr/sbin/php-fpm /usr/sbin/php-fpm.bak
$ sudo ln -s /usr/local/Cellar/php54/5.4.11/sbin/php-fpm /usr/sbin/php-fpm
$ php-fpm -v
Notice that the version went from 5.3 to 5.4 (in my case). Now for the php binary:
$ php -v
$ sudo mv /usr/bin/php /usr/bin/php.bak
$ sudo ln -s /usr/local/bin/php /usr/bin/php
$ php -v
I also added /usr/local/sbin to the PATH by adding that directory to the /etc/paths file, then restarting Terminal. You can see your current PATH by typing echo $PATH.
Important config files:
/usr/local/etc/nginx/nginx.conf
/usr/local/etc/php/5.4/php.ini
/usr/local/etc/nginx/fastcgi_params
You'll probably want to change these for your
The nice thing about Homebrew installations is that you generally don't need sudo to use or manage these services, since they're in /usr/local.
Alright. Well that did it for me. Enjoy your new dev environment!
You can stop nginx with nginx -s stop, and start it again with just nginx. You can also just reload the conf file withnginx -s reload.
I installed MySQL Workbench and was able to make a connection to the localhost MySQL server by adding a connection to host "localhost" with no password. The only thing I typed was that hostname and everything worked like a charm.
I did use my nginx.conf file from my previous install; you can view a sample conf file if you need it, in my other post about using Macports to do this (link at top of this post).
서버버전을 사용하여 소스코드 checkout 및 commit은 많이 하는데 왠지 branch를 만들거나 merge하려니 이거 좀 복잡한 생각이 들때가 있고 메뉴얼을 읽어 봐도 북잡하기만 하다.
그러나 Branch의 기능은 전제 Team의 개발에 영향을 주지 않고 혼자서 (또는 소규모 팀별로) 프로그램을 고치고 테스트 하고 잘 될때 head로 보낼때 아주 유용하게 사용할 수 있다. 서버버전을 사용하면 그 방법도 간단하다.
우선 Checkout 부터 한번 해보자. (Subversion 저장소-
https://coolproj.googlecode.com/
)
svn co
https://coolproj.googlecode.com/
coolproj
cd colproj
[작업]
svn ci -m"작업 잘 했음. 무엇 무엇 고쳤음. 무슨무슨 버그 잡았음"
이렇게 하는 것이 보통 그냥 branch같은거 사용하지 않고 하는 작업인데 여기서 branch만들기는 너무 간단하다.
svn copy coolproj
https://coolproj.googlecode.com/
이렇게 하면 끝이난다.
그런다음 이 새로운 branch 를 checkout 해서 작업을 하면 된다.
svn co
https://coolproj.googlecode.com/
coolproj-branch
그냥 이전의 coolproj 라는 workspace를 사용하고 싶으면 살짝 'switch' 해주면 된다.
cd dupbug/
svn switch
https://coolproj.googlecode.com/
[작업]
svn ci -m"작업 잘 했음. 무엇 무엇 고쳤음. 무슨무슨 버그 잡았음"
이렇게 checkin 된 코드는 이전에 생성된 branch에 남아 있게 된다.
여러번 작업을 한다음 이 branch가 충분히 훌륭한 관계로 trunk에 보내고 싶다면 merge하면 된다. 우선 바로 merge하기 전에 (trunk가 변했을수도 있으므로) 몇가지 확인 해보자. 우선 --dry-run (예행연습)
svn merge --dry-run
https://coolproj.googlecode.com/
https://coolproj.googlecode.com/
그러면 무엇이 바뀌는 것인지 보여 준다.
구체적으로 무엇이 달라졌는지 line-by-line으로 보고 싶으면 diff를 사용한다. (주의 URL의 순서가 merge때와 다르게 바뀌었다)
svn diff
https://coolproj.googlecode.com/
\
https://coolproj.googlecode.com/
마지막으로 모든것이 좋아 보여 merge를 하려면 앞에서 dry-run을 하면 된다.
svn merge --dry-run
https://coolproj.googlecode.com/
https://coolproj.googlecode.com/
branch와 merge는 작은 단위의 commit이 많이 필요할때는 불필요하게 다른 사람들이 나의 commit을 보이고 싶지 않을때 요긴하게 사용되는 기능이다. 한번만 사용해보면 쉽게 사용할 수 있다.
FreeTDS란?
FreeTDS is a set of libraries for Unix and Linux that allows your programs to natively talk to SQL Server and Sybase databases.
다운로드 주소
ftp://ftp.astron.com/pub/freetds/stable/freetds-stable.tgz
freetds.conf 설정
[global]
tds version = 8.0 # Option 아래 설정만으로 커넥션이 안될경우 이 줄도 추가해보자.
[MyServer]
host = My Server IP
port = 1433
tds version = 8.0
Python Sample(SQL Server)
import pymssql
conn = pymssql.connect(host="MyServer", user="", password="", database="")
cur = conn.cursor()
qry = "SELECT * FROM test"
rows = cur.fetchall()
cur.close()
conn.close()
print str(rows)
Copyright © 2015-2025 Socialdev. All Rights Reserved.