목차



  • make 소개
  • Makefile 기본편
    • 기본구조
    • Makefile.win (CYGWIN)
  • Makefile 응용편
    • Macro
    • Dependency
    • Command
    • Operation
  • 와이즈넛 build_system 소개


make 소개


make 정의(by man) : GNU make utility to maintain groups of programs. The purpose of the make utility is to determine automatically which pieces of a large program need to be recompiled, and issue the commands to recompile them.

make 명령시 참조 파일 : 현재 디렉토리 내의 GNUmakefile, Makefile, makefile. Makefile을 권장함

make -f <파일명> : 특정파일을 Makefile 처럼 인식하여 make 명령을 수행할 때 사용. 와이즈넛에서는 윈도우 빌드시 Makefile.win 을 읽기 위해 해당 명령을 사용.


Makefile 기본편 - 기본구조



<target>: <dependency>
      <command>

  • target : command 수행 결과를 담는 곳. 모드, 파일, 패턴, 변수 등 다양하게 올 수 있음. dependency 로 지정된 대상이 변화가 없으면 target은 수행되지 않는다.
  • dependency : target 수행시 의존성을 검사하는 대상 target. 다른 target, 파일등등 target처럼 다양하게 사용 가능. 값이 없어도 됨.
  • command : target에 대한 실제 수행 명령을 담는 부분. 반드시 tab 으로 구분되어야 함. bash 명령어 참조

여기서 잠깐 : mode

  • 표준 모드 : all , clean , install, test
    • all : 현제 디렉토리 내의 모든 것을 빌드. ( 모드를 입력으로 주지 않으면 all 부터 시작함 )
    • clean : 빌드 생성물을 모두 삭제.
      • tip : clean 으로 모든 생성물을 잘 제거했는지 확인 ( VCS로 확인 가능 : subversion / git 등 )
    • install : 빌드 생성물 중 설치 대상 파일들을 설치 디렉토리에 설치함.
    • test : 현 디랙토리 내의 테스트를 위한 빌드 (및 수행)를 진행함.

Makefile 기본편 - Makefile.win (CYGWIN)

  • 모든 경로는 (환경변수 포함) dos 경로로 지정되어야 함.
    • unix 경로( /cygdrive/d/home/user/program )는 오동작을 일으킴. dos 경로 ( "c:/cygwin64/home/user/program" ) 으로 지정되어야 함.
    • unix 경로를 dos 경로로 바꾸려면 cygpath.exe 를 이용함
      • 예 : cygpath -d $PWD
  • 컴파일 전 build_system/confs 아래 해당 빌드옵션.env 파일을 환경변수로 정의해야 한다.
    • 예 : 빌드 정보가 ia64-w64-msvc90-64 인 경우 컴파일 전 아래의 명령을 수행해야 함

$ source ia64-w64-msvc90-64.env





Makefile 응용편 - Macro


  • 명령어 수행 결과를 변수에 넣기 $(shell 명령어)

TEST_SRC = $(shell ls t_*.java)


  • internal macro
    • $* : 확장자 제거한 target 파일
    • $@ : 만들어질 파일 이름 (target)
    • $< : dependency 로 주어진 파일 중 변경된 파일명
    • $? : dependency 로 주어진 모든 파일 set

  • suffix replace macro
    • OBJS = ${SRCS: .c=.o} 
      • SRCS 의 모든 파일에 대한 .c 확장자를 .o로 대치하여 OBJS 에 저장

<Makefile>

SRCS = aaa.c bbb.c ccc.c
OBJS = ${SRCS: .c = .o}

all : xxx

xxx : $(SRCS)
    @echo "================== xxx ==================="
    @echo "target ===== $@"
    @echo "newer sources = q $?"
    @echo "newer sources = g $<"

%.c:
    @echo "target ==== $@"
    @echo "asterisk ==== $*"
<출력>

$ make
target ==== aaa.c
asterisk ==== aaa
target ==== bbb.c
asterisk ==== bbb
target ==== ccc.c
asterisk ==== ccc
================== xxx ===================
target ===== xxx
newer sources = q aaa.c bbb.c ccc.c
newer sources = g aaa.c
target ==== all.c
asterisk ==== all
cc    -c -o all.o all.c
cc: all.c: 그런 파일이나 디렉토리가 없음
cc: no input files
make: *** [all.o] 오류 1


Makefile 응용편 - dependency


target 및 dependency 에서 자주 사용하는 패턴
  • %.o : *.o 파일을 의미함.  "t_%: t_%.o" 등으로 패턴적용 응용 사용 가능
    • 예) %.o : %.cpp


Makefile 응용편 - command

아래의 command 는 bash 명령어에 기반한 내용이다. bash의 다양한 명령어를 사용하여 Makefile 을 구축할 수 있다.

(참고) Makefile 내에서 명령어 앞에 @를 사용하는 경우 명령어가 출력되지 않음.


  • 하위 디렉토리 순회

DIRS = aaa bbb ccc ddd

all:
    @for dir in $(DIRS); do \
        echo "===> $(PWD)/$$dir"; \
        (cd $$dir && $(MAKE) -f $(MAKE_FILE) $@) || exit 1; \
        echo "<=== $(PWD)/$$dir"; \
    done



Makefile 응용편 - operation


  • 특정 변수에 대한 확인 : origin
    • 문법 : $(origin variable)
    • return 값
      • undefined : 정의되지 않음
      • default : default 값이 있는경우
      • environment : 환경변수로 정의됨 ( -e 등의 복잡한 부분은 이곳 참조 : http://www.viper.pe.kr/docs/make-ko/make-ko_8.html )
      • file : makefile 에서 정의되었음
      • command line : 명령행에서 정의되었음
      • 등등
    • 보통 ifeq 과 함께 사용

ifeq ( $(origin SF1_SRC), undefined )
$(error no environment variable SF1_SRC)
else
 ...
endif


  • 정렬 및 중복제거 : sort
    • 문법 : $(sort list)

SORT = $(sort foo bar lose bar2 lose)

all:
    @echo "sort === $(SORT)"
sort === bar bar2 foo lose


  • wildcard 실제 텍스트 변환 : wildcard
    • 문법 : $(wildcard text)
      • 예: $(wildcard *.cpp)
    • OBJ = *.o 를 하게 되면 OBJ 는 *.o 라는 문자열을 가지게 된다. 만약 현재 경로에 o 파일이 아무것도 없어도 OBJ 는 *.o를 갖게 되어 알수없다는 컴파일 에러를 내게 될 것이다. 그래서 *.o 보다는 wildcard 와 문자열 치환 함수를 통하여 구현하는 것을 권고한다.


  • 일괄치환 : patsubst
    • 문법  : $(patsubst 원본패턴, 대치할패턴, 텍스트)
    • 보통 wildcard 와 함께 사용하며 특정 경로의 모든 패턴의 파일 리스트에 대한 확장자 변경을 할때 사용한다.

DIRS = ./module1 ./module2 ./module3
OBJS = $(patsubst %.cpp, %.o, $(foreach dir, $(DIRS), $(wildcard $(dir)/*.cpp)))



  • 다른 Makefile 내용 포함 : include
    • 보통 Makefile.win 에서 Makefile 과 그 내용이 동일할때(java compile 등) 사용함.

<$(SF1_SRC)/src/isc/qp/qpapi/java/Makefile.win 내용>

include $(SF1_SRC)/src/isc/qp/qpapi/java/Makefile







References


How to change encoding type

  • Press ⌘ + i in the iTerm window.
  • Click ‘Terminal’ tab.
  • Select what you want in the ‘Character Encoding’ field.


1. Error when “yo angular”

  • "npm cache clean" and re-run the command “yo angular”

 

 

Master

 

Error Message

Solution

  1. Master와 Slave 간의 방화벽 체크를 한다.
  2. Master와 Slave의 hadoop 데이터가 기록되는 디렉터리의 권한이 유효한지 확인한다.
  3. Slave가 두 hadoop 버전의 Master와 연결된 경우  문제가 발생할 수 있다. slave쪽의 datanode 쪽을 모두 삭제하고 새로 시작한다.


분산 처리 관련 업무 중 HDFS 관련 조사가 필요하여 관련 분석 내용을 참고차 기록한다.

 

  • HDFS supports following read/write policies
    • read
      • random read
      • sequential read
    • write
      • sequential write
  • Block size, the number of replica can be set for each file.



  • .gitignore 에 아래의 항목을 추가해야 svn의 시스템 파일들이 포함되지 않는다.

*.svn*


  • .svn 밑의 파일들이 git에 포함된 경우 실제파일은 지우지 않고 git내의 색인대상에서만 삭제하는 명령어 ( removing svn system files in git index data instead of doing real data )

$ find . -name "*.svn*" -type f -exec git rm --cached {} \;



XXX is already under version control

분명히 현 repository의 새로운 녀석인데 버전컨트롤대상이라고 한다.

이는 그 디렉토리 밑에 .svn 까지 복사 되었기 때문이다.

따라서 .svn 을 지우고 svn add 를 수행하면 된다.

Tag 생성하기

$ svn copy [source] [target] -m "Message"
   (ex) svn copy http://svn.example.com/project/trunk http://svn.example.com/project/tags/RELEASE-110214 -m "Tag : Release 110214"



참고 사항

  • 특정 태그 이름으로 받은 repository는 해당 tag가 업데이트 하는 내용만 받고 trunk 쪽의 업데이트 내용은 받아오지 않는다. 







간단하게 비교하는거니 
다른 방법으로도 가능하다는 것을 증명하기 위해 성내지 말고
주인장이 이곳에 잘 반영할 수 있게
친절히 커맨트하시기 바랍니다.

  • 마지막 commit 이후 변경된 파일 목록 보기
    • git : git status
    • svn : svn status
    • cvs : cvs diff --brief
  • commit 간 diff 보기
    • git : git diff <commit id>..<commit id> 또는 git diff <commit id>...<commit id>
    • svn : svn diff -r 이전리비전번호:비교할리비전번호

git와는 다르게 svn에서 반복적인 ignore 를 하는 방법은 아래와 같다.

  1. 각 디렉토리마다 ignore pattern을 property로 등록. (Don't forget the last dot)
    • command : svn -R propset svn:ignore [pattern] .
      $ svn -R svn:ignore *.obj .

  2. svn configuration파일에 global-ignores 패턴 등록

svn의 또다른 어메이징한 것은 global ignores로 지정하지 않을 경우 새로운 디렉토리가 생길때마다 저 패턴을 등록해줘야 한다는 것이다. 

어떤 것을 선택하든 번거롭고 깔끔하지 못하다.

역시 svn 은 cvs가 git로 가는 도중의 중간산출물 같다.

결론 : git가 좋다.
  1. 명현 2011.01.25 09:05 신고

    ㅋㅋㅋ git svn 찾다가 이게 나오네요

  1. apr 및 apr-util 컴파일 및 설치http://archive.apache.org/dist/apr/
    • apr configure 설정(default설정 이용)
      $ ./configure
    • apr-util configure 설정(설치경로 : /usr/local/apr-util) :
      $ ./configure --with-apr=/usr/local/apr --prefix=/usr/local/apr-util

  2. neon 컴파일 및 설치http://www.webdav.org/neon/
    • neon configure 설정 (설치경로 : /usr/local/neon) :
      $ ./configure --prefix=/usr/local/neon

  3. subversion 컴파일 및 설치http://subversion.tigris.org/
    • subversion configure 설정
      $ ./configure --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr-util --with-neon=/usr/local/neon
Source code

  • 왜 생성자가 protected 일까? 
    • 클래스 상속시 sub-class의 기본생성자는 자동으로 super-class의 기본생성자를 호출한다. 이때 super-class의 protected인자들은 sub-class가 호출할 수 있지만 private로 생성하는 경우 접근할 수 없다. 한마디로 super class의 기본 생성자를 private으로 하는 경우 sub-class는 기본생성자를 만들 수 없다.
Windows XP 에서 Windows key + 1~9 로 

Quick Lunch bar 에 있는 프로그램을 실행할 수 있는 방법이 없을까 하다 발견한 프로그램. 

스크립트도 되고 이거 매우 강력하다. 

하지만 강력한 툴에 존재하는 필수조건 :  manual 정독요

http://www.autohotkey.com/

자주 사용되는 키

  • Alt : !
  • Ctrl : ^
  • Shift : +
  • Windows key : #
  • 한/영 전환키 : {vk15sc138}



  • 특정범위의 양수 음수에 대한 각각의 합계를 내고 싶은 경우 ( how to sum only positive values or only negative ones. )
    • 원형 : sumif ( 범위 , 조건 )
    • example : =sumif(D3:AA3,">0")
  • 순위를 매기고 싶은 경우 ( how to rank )
    • 원형 : rank( 순위를 매기고 싶은 값 , 순위 매기는 데이터 범위 , 오름차순(0) / 내림차순(1) )
    • example : =Rank(C3,C3:C100,0)
공식 사이트 : http://ctags.sourceforge.net/

대부분의 linux package 에서는 ctags 가 기본으로 깔려있다고 하는데,
혹 설치가 안되있다면 위의 사이트에서 다운로드 받길 바란다.

함수의 선언부로 이동하는 visual studio의 강력한 툴 기능을
잘만 활용한다면 강력한 코드 리뷰용 툴이 된다.


기본 사용법

  1. tag 파일 생성하기

    기본적으로 현재 경로에 대해서만 tag정보를 수집한다. ctags 뒤에 타겟 파일명을 입력해주면 된다. (*, *.cpp, etc) 이 경우 파일명은 tags이다.

    $ ctags *.hpp *.cpp

    하위 폴더의 내용까지 생성하고자 하는경우 -R을, 특정 파일명으로 tag 정보를 저장하고 싶으면 -f [파일명] 을 이용한다.

    $ ctags -R -f local_tags


  2. vi에서 tag 파일 설정하기

    :set tags 를 입력하게 되면 현재 vi 에서 이용하는 기본 태그 파일명을 이용하게 된다. 무조건 여기에 지정된 파일명만 tag 용도로 활용하게 된다.


  3. vi에서 ctag 기능 활용하기

     : ta [keyword] [keyword]가 정의된 곳으로 이동 
     Ctrl + ]  해당 커서에 있는 keyword가 정의된 곳으로 이동
     visual 선택후 Ctrl + ]  선택한 keyword가 정의된 곳으로 이동
     Ctrl + t  이동하기 바로 전 페이지로 이동
     Ctrl + n  자동완성





Errors


  • git clone 시 fatal: remote end hung up 발생한 경우 : remote end hung up에는 여러가지 요인이 있을 수 있다. 대부분 remote server의 ssh 포트(20)로의 접근이 불가능 하거나 서버에 public_key를 제대로 등록하지 않아서 발생한 이슈들이 대부분이다. 하지만 본인의 경우에는 scp, ssh 로 remote server로 접속하는데 아무런 문제가 없었다. 오랜시간동안의 사투끝에, 윈도우용 git (msysgit) 를 설치하고, cygwin 패키지를 설치할때도 git 를 설치하였는데 그 둘이 충돌이 나는 거였다. 윈도우용 git를 uninstall 하고 나서 문제가 간단히 해결되었다. 
  • clear 가 먹지 않는 경우, Ctrl + L 을 이용해보라.
  • script File의 경우 file type 이 맞지 않아 실행되지 않는 경우가 있다. 이런경우 vi 로 파일을 열어 set fileformat=unix 를 지정하고 저장하면 파일이 POSIX 타입으로 바뀐다.

오역이나 오탈자에 대한 것은 덧글활용을 부탁드리며, 내용수정은 허락하지 않습니다.


각자 나름대로 git의 branch을 개성있게 사용하고 있겠지만, 아래 링크된 곳에서는 저자가 여러 프로젝트를 진행하면서 사용했던 브렌치들을  하나의 모델로 정형화하여 잘 설명하고 있다. 그 중에 branch활용방안에 대한 내용들을 번역 및 요약해본다. 







  • The main branches

    • master
      • 기본적으로 git에서 생성되는 branch.
      • 운용 기준
        • HEAD부분은 제품으로 나갈만큼 안정화되어 있어야 한다.

    • develop
      • 개발시 이용하는 branch
      • 운용 기준
        • 최근 개발 현황이 HEAD에 담겨야 한다.
        • 다음 release를 위한 기능 추가가 이루어 진다.
        • auto build 및 test 대상이 된다.
        • 안정화가 끝나면 master 와 merging되고 release tag 번호가 부여된다.
  • Supporting branches : 수시로 생성과 삭제가 반복되는 branch

    • feature
      • 새로운 기능을 추가할때마다 생성하는 branch
      • Naming : master, develop, release-*, hotfix-* 을 제외한 어떠한 이름도 허용가능
      • 운용 기준
        • develop 에서 branching 하며 완성되고 나면 다시 develop branch로 merging 한다.
        • 새로 추가한 기능이 이점을 줄 수 있을때에만 develop branch로 merging한다.
        • merging을 완료하고 나서 생성된 feature branch를 삭제한다.
        • merging 시 "--no-ff" 옵션을 사용한다. 이 옵션은 merging할때 fast-forward와 함께진행될 때에도 항상 새로운 commit을 생성한다. 이로 인해 feature branch에서 저장했던 예전 작업들에 대한 정보들에 대한 손실을 막을 수 있다. 아래의 그림을 보면 그 차이가 드러난다. 오른쪽의 일반적인 merging은 feature에서 merging된 commit들이 기존에 develop에 있던 commit들과 구분이 안된다.



    • release
      • 새로운 release를 내기위해 준비하는 branch
      • Naming : release-* (*는 니 맘대로 문자열을 의미한다.)
      • 운용 방안
        • develop branch로 부터 가져오고 develop와 master로 merging을 실시한다.
        • release branch 생성후 먼저 버전 올려주는 것을 잊지 말자.
        • minor bugs나 meta-data(버전정보, 빌드날짜 등등) 추가는 허용된다.
        • 해당 번호 release시에 목표했던 feature들이 추가되어 만족할만한 기능이 나올때(develop branch가 다음release를 준비할 만한 상태일 때에...)에 release branch를 생성한다. 다음 릴리즈에서 포함되어야 되는 기능들은 절대로 포함시켜서는 안된다. 네이밍을 할때는 next-release같은 것은 피해야 한다. 그 대신 0.5, 1.2.3 같은 구체적인 수치와 그에 해당하는 기준들을 마련한다.
        • 작업이 완료되면 master로 merging한다.merging 후에는 release정보로 바로 tagging한다. master로의 작업이 완료된 후에는 반드시 develop에도 merging을 실시 한다. merging시에 발생하는 conflict는 해결후 commit 한다.
        • merging이 완료되면 해당 release branch를 삭제한다.

    • hotfix
      • 출시된 제품에서 오류가 발견되어 즉시 해결해야 하는경우 이용하는 branch
      • Naming : hotfix-*
      • 운용 방안
        • master의 해당 태그로부터 가져오고 develop과 master로 merging을 실시한다.
        • hotfix branch생성후 먼저 버전 올려주는 것을 잊지 말자.
        • 완료된 후에는 master 적용후 develop에도 적용해야 한다. 이때, release branch가 있는 경우 develop에 merging 하지 말고 release에 한다. 왜냐하면 release시에 테스트가 수반되고, release작업이 완료된 경우 release branch가 다시 develop에 적용되기 때문이다.
        • merging이 완료되면 해당 hotfix branch를 삭제한다.

set tabstop=4
또는
set ts=4


linux 의 경우 ~/.vimrc 에서 수정하면 되고
윈도우의 경우 gvim 을 열어서 메뉴 -> 편집 -> Startup Settings를 누르면 열리는 파일을 수정하면 된다.
#!/bin/bash

for dir in /home/dualistmage/git/*; do
    cd $dir
    printf "%-15s : " "${dir/\/home\/dualistmage\/git\//}"
    git log --pretty=oneline -n1
done

GIT 에서 Binary 파일을 자동으로 인식하는데, 가끔 text file로 오동작을 한다. 이는 나중에 merging 시 line process를 할 수 있기 때문에 위험성이 존재한다.

.gitignore 처럼 binary 인식시 .gitattributes 라는 파일안에 특정 파일형식을 등록하게 되면 해당하는 모든 파일들은 모두 binary 로 인식하게 된다. (사실 이 기능은 .gitattributes 파일의 여러 기능중의 하나이므로 다른 기능들을 알아보고 싶은분은 git manual 을 참조 바란다. )

.gitattribute :  http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html 

만약 모든 pdf 파일을 binary 로 인식하게 하고 싶으면, repository 의 적용할 최상단 directory 에 .gitattributes 파일을 만들고 아래와 같이 집어 넣는다.
*.pdf -crlf -diff -merge
<옵션 설명>

-crlf : *.pdf가 carriage return 과 line feed 이 없는 파일이라는 것을 기술한 것이다.
-diff : *.pdf에 대해서는 diff를 binary file differ로 이용하겠다는 것이다. ( text diff 를 unset 했다고 이해하면 됨)
-merge : *.pdf 에서 merging 시 conflict 가 발생한 경우 현재 branch 에 있는 녀석을 취하고 conflict 메시지를 발생시킨다는 것.

한 변수에 여러 definition 을 집어 넣고 이 변수만을 이용하고 싶을때는 아래와 같이 리스트로 집어넣어야 한다.
SET( VAR_NAME "-D[SOMETHING1" "-D[SOMETHING2" ... )
ADD_DEFINITIONS( ${VAR_NAME} )
(ex)
SET( COMPILE_DEFINITION "-DDEBUG" "-DDEBUG_LEVEL=2" )
ADD_DEFINITIONS( ${COMPILE_DEFINITION} )


마우스 드래그만으로 화면내 텍스트 copy가 되고 
창크기도 조절 가능
환경설정을 통해 색생을 조절할 수 있는 만능 도구

cmd 를 띄우고 나서 화면에 뿌리는 텍스트를 관리해주는거 같은데
가끔 창이 2개 뜬다

http://d.hatena.ne.jp/hideden/20071115/1195229532
! LaTeX Error : Cannot determine size of graphic in XXX.png (no BoundingBox).

LaTeX 사용중에 귀찮게 하는 에러중에 하나. 에러 발생하지 않으려면, 파일의 이미지 사이즈를 알아낸 후 includegraphics 에서 boundary box 영역를 제대로 잡아주면 된다.

\begin{figure}[htb]
   \centering
   \includegraphics[scale=0.5,bb=0 0 385 567]{figuras/picture.png}
   \caption{Some description about the picture}
   \label{picture-label}
\end{figure}

  • remote 서버 등록하기

    git remote add [이름] [실주소]
    (ex) $ git remote add TestRemote 192.168.0.1:/git/TestRemote.git

  • 현재 branch 의 remote 서버를 redirect하기

    현재 repository 의 최상단으로 이동하면 .git/config 라는 파일이 있다. 이 파일을 연다. 내가 현재 있는 branch 이름을 "MyBranch", 연결할 Remote branch 를 TestRemote 라고 하면 아래와 같이 되어 있을수도(설정값이 다를수도 있다. 그냥 있다는데에 의의를 두자.) 있고 아얘 없을 수도 있다.

    [branch "MyBranch"]
            remote = origin
            merge = refs/heads/MyBranch

    이것을 아래와 같이 변경한다.

    [branch "MyBranch"]
            remote = TestRemote
            merge = refs/heads/MyBranch




프로그램을 짜다 보면 딱 한번만 실행해야 하는 함수들이 있을수 있다.

그런경우 아래와 같이 static bool 변수같은걸 두고 그 값에 따라서 수행하기도 하는데



이 함수가 multi thread 접근을 하는경우 초기화가 다중으로 될 수 있는 위험이 있다.

다행히 boost에서 thread 에 안전한 함수를 제공한다. 

  • boost::call_once() 는 연결된 함수포인터를보고 단 한번만 수행한다. 두번째로 받는 파라미터는 boost::once_flag 형이다. thread safe 하다.

  • boost::once_flag 는 매크로 BOOST_ONCE_INIT 으로 초기화 한다. 초기화 역시 thread safe 하다.

플래그를 전역변수가 아닌 함수 내부 static 변수로 둘경우 아래와 같이 구성할수 있다.


주의해야 할 점은 이 함수들을 클래스의 멤버함수로 구현하는 경우, 초기화의 실제 동작 부분인 initOnlyOnceCore() 는 private 으로 가려져야 이 함수가 직접 호출되는 것을 막을 수 있다.
  1. Favicon of http://warmz.tistory.com BlogIcon 음주코딩 2013.04.12 10:05 신고

    좋은 정보 감사합니다. 퍼갈게요.

$ git diff --cached

add 가 적용된 상태를 staged 라고 하는데, --cached 는 add한 파일들에 대해서 비교한다.

--cached 뒤에  commit 을 주지 않으면 기본적으로 HEAD 와 비교한다.
사용 방법은 <textarea name="code" class="Alias">
Ctrl + s 는 현재 내가 이용하고 있는 shell을 suspend mode로 전환하는 단축키이며
아마 대부분 모르고 눌렀거나 알고 눌렀어도 해결책을 몰라 창을 그냥 닫기 쉽다.

Ctrl + q 를 누르면 간단히 정상복구 시킬 수 있다.
대소문자 반전 : (영역 선택 후) ~
대문자로 변환 : (영역 선택 후) U 또는 gU
소문자로 변환 : (영역 선택 후) u 또는 gu
  1. Favicon of http://sourkent.tistory.com BlogIcon 신키위 2009.12.03 11:29 신고

    오 ~ 이거는 몰랐는데. ㅋㅋㅋㅋ
    근데 영역선택후에 g 없이 u/U로도 되는 것 같던데요.

+ Recent posts

티스토리 툴바