반응형

출처 : http://git-scm.com/docs/git-log

이름

git-log - commit log를 보여줍니다.

요약

git log [<옵션들> [revision range] [[\--] <경로>...]

설명

commit log를 보여줍니다.

주어진 commit에서 부모(parent) 링크를 따라 도달할 수 있는 commit을 나열하지만 앞에 ^가 있는 commit에서 도달 가능한 commit은 제외합니다. 출력은 기본적으로 시간 역순으로 제공됩니다.

이것을 집합 연산으로 생각할 수 있습니다. 명령줄에 지정된 commit에서 도달할 수 있는 commit은 집합을 형성한 다음 앞에 ^가 표시된 커밋에서 도달할 수 있는 커밋을 해당 집합에서 뺍니다. 나머지 커밋은 명령의 출력으로 나오는 것입니다. 다양한 기타 옵션 및 경로 매개변수를 사용하여 결과를 추가로 제한할 수 있습니다.

다음 명령이 이 예시입니다.

$ git log foo bar ^baz

위 명령어는 "foo 또는 bar에서는 도달할 수 있지만 baz에서는 도달할 수 없는 모든 커밋을 나열"을 의미합니다.

특수 표기법 ".."는 "^ "의 약어로 사용할 수 있습니다. 예를 들어 다음 중 하나를 서로 바꿔서 사용할 수 있습니다.

$ git log A B --not $(git merge-base --all A B)
$ git log A...B

이 명령은 git-rev-list[1] 명령에 적용 가능한 옵션을 사용하여 표시되는 내용과 방법을 제어하고 git-diff[1] 명령에 적용 가능한 옵션을 사용하여 각 이 도입하는 변경 사항이 표시되는 방법을 제어합니다.

옵션

--follow

이름 변경을 포함하여 하나의 파일의 history(히스토리)를 조회합니다. (하나의 파일에 대해서만 작동합니다.)

예시)

[root@test test]#  git log --follow --oneline ab.txt
1f61b72 second commit      // a.txt ==이름변경==> ab.txt 
00f7289 test - initial commit // a.txt

--all

<commit>의 명령어에 대하여 refs/의 모든 the refs(참조들) 출력될 것입니다.

--no-decorate

--decorate[=short|full|no]

commit의 the ref(참조) 이름을 출력합니다. short이면 the ref(참조) 이름의 접두사 refs/heads/, refs/tags/, refs/remotes는 출력되지 않을 것입니다. full이면 the ref(접두어를 포함하여)의 전체 참조가 출력될 것입니다. 기본 값은 short입니다.

--graph

출력의 왼쪽 부분에 commit history(커밋 히스토리)를 텍스트 기반의 그래픽 표현으로 그립니다.

이는 그래프 history를 적절히 그리기 위해 commit들 사이에 부가적인 행(line)이 있을 수 있습니다.

--no-walk와 결합해서 사용할 수 없습니다.

이는 기본으로 --topo-order 옵션을 내포하지만, --date-order 옵션도 지정될 수 있습니다.

예시)

 [root@test test]# git log --all --graph --oneline --decorate
* 303c84e (HEAD, dev) test dev - 3
* e0de443 test dev - 2
* dd60246 (master) test master - 1
반응형
반응형

출처 : http://www.dalyong.com/2696673

저번주 토요일에 정전이 발생한다는 공지를 보고 전기가 들어올 때 자동으로 켜게 하도록 하는 방법을 웹서핑을 해서 찾은 내용입니다.

전기 신호를 감지해서 컴퓨터 전원을 켠다고 하고요.

설정은 바이오스에서 가능합니다.

Power Management 부분에서 Restore On AC Power LossOn으로 되어 있으면 정전이 된 후 다시 전원이 들어오면 컴퓨터가 자동으로 켜지게 됩니다.

저번 주 금요일날 위의 방법대로 BIOS를 세팅을 하여 재부팅을 하였습니다. 

토요일에 정전이 되고 전원이 들어온 후 원격접속을 하니 컴퓨터가 잘 켜져 있음을 확인하였습니다.

반응형
반응형

출처 : http://stackoverflow.com/questions/5658568/how-to-list-processes-attached-to-a-shared-memory-segment-in-linux

리눅스에 공유메모리에 접근한 프로세스의 목록을 아는 방법?

공유 메모리에 접근한 프로세스가 무엇인지 어떻게 알 수 있습니까?

awagner@tree:/home/awagner$ ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 0          root       777        102400     1                       
0x00000000 32769      root       774        96         1          dest         
0x00000000 98306      awagner    600        393216     2          dest         
0x00000000 131075     awagner    600        393216     2          dest    

예시. 98305 공유메모리에 접근한 2개의 프로세스를 어떻게 알 수 있습니까?


5개의 답변 중 1개의 답변

표준 툴로는 이것을 알 수 없다고 생각합니다. 당신은 마지막으로 접근하거나 공유메모리와 분리된 프로세스의 ID를 ipcs -mp 를 사용하여 알 수 있지만 ipcs로 접근한 모든 프로세스를 아는 방법을 저는 모릅니다.

공유메모리에 접근한 두개의 프로세스가 현재도 공유메모리에 붙어있다고 가정하면 공유메모리를 생성한 PID cpid와 마지막에 접근한 PID lpid를 통하여 두개의 프로세스를 알 수는 있지만 그 이상으로 확장하여 알 수는 없기 때문에 유용함이 제한됩니다.

cat /proc/sysvipc/shm 방법은 비슷하게 제한적이지만 /proc 파일 시스템의 다른 부분으로 프로세스의 목록을 아는 방법이 있다고 믿습니다. 아래를 보시면,

모든 프로세스에 대응하는 procfs(파일시스템)에서 grep을 할 때, cpidlpid의 프로세스들을 포함하는 목록을 얻었습니다.

예를 들어, 다음 공유메모리를 ipcs -m 명령으로 얻었습니다.

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 123456     pax        600        1024       2          dest

그리고 주어진 공유메모리 id (123456)을 통해 ipcs -mpcpid는 3956 이고 lpid는 9999 라는 것을 알아내었습니다.

그리고 명령어 grep 123456 /proc/*/maps 을 통해 다음을 알 수 있습니다.

/proc/3956/maps: blah blah blah 123456 /SYSV000000 (deleted)
/proc/9999/maps: blah blah blah 123456 /SYSV000000 (deleted)

그래서 이것이 공유메모리에 접근한 프로세스 목록을 얻는 방법입니다. dest 상태와 (deleted) 표시가 마지막 분리가 발생했을 때 삭제를 위한 표시를 생성자가 했기 때문에 이미 그 공유메모리가 파괴된 것이 아님을 저는 매우 확신합니다.

/proc/*/maps 파일들을 검사함으로서, 당신은 주어진 공유메모리에 현재 접근하고 있는 PID들을 발견할 수 있습니다.


출처 : http://www.linuxforums.org/forum/red-hat-fedora-linux/168472-unable-remove-shared-memory.html

안 지워지는 공유메모리 삭제하는 방법

저 같은 경우에는 위의 방법으로 접근한 프로세스의 목록을 얻은 다음 해당 프로세스를 kill하여 문제를 해결하였습니다.

다음 내용은 위의 출처에서 답변만 번역 하였습니다.

man 페이지는 ipcrm -m 는 삭제를 위해 표시만을 한다고 쓰여 있습니다. ipcs -p는 공유메모리에 접근한 프로세스 id를 제공합니다. 해제하고자 하는 공유메모리에 접근하고 있는 프로세스를 kill하면 그 공유메모리가 사라진 것을 확인하실 수 있습니다.

반응형
반응형

expect

Expect는 스크립트에 따라서 다른 상호작용하는 프로그램과 대화하는 프로그램입니다. 번역된 언어는 대화를 하는 데 있어서 분기와 높은 수준의 제어 구조를 제공합니다. 게다가, 사용자는 스크립트로 원할 때 직접 상호작용하면서 제어를 할 수 있습니다.

Expect는 사용자 수준의 어떤 프로그램이나 작업에 대한 명령어로서 실행될 수 있습니다. Expect는 실제로 동시에 여러 프로그램과 대화할 수 있습니다.

사용예시

https://github.com/SDRLurker/shell

mssh.sh

mssh.sh 실행할서버 SSH포트 "명령"

shell 내의 sexecute() 함수가 있습니다. 

ssh로 서버에 접속하여 $PW를 보내 비밀번호를 자동으로 입력하는 기능을 합니다.

# 원격 서버에 접속하여 shell 명령을 수행합니다.
sexecute()
{

local IP=$1
local PORT=$2
local PW=$3
local MSG=$4 

if [ -z $PORT ]; then
    PORT=22
fi

echo "ssh -p$PORT $IP $MSG"
expect <<EOF
set timeout -1
spawn ssh -p$PORT $IP $MSG # SSH로 $IP와 $PORT로 접속해 $MSG명령을 실행하기 위해 접속
expect "password:"                    # SSH에서 password라는 글자를 받으면 다음 줄로 넘어간다.
send "$PW\r"                              # 비밀번호 $PW 문자열을 입력한다.
expect eof
EOF

}

 


출처

http://linux.die.net/man/1/expect

반응형
반응형

출처 : http://bitflop.com/tutorials/how-to-create-a-new-and-empty-branch-in-git.html

Git에서 새롭고 비어 있는 branch를 만드는 방법

많은 코딩 프로젝트에서 코드는 하나의 저장소에 있고 문서는 다른 저장소에 있습니다.

만약 프로젝트가 데이터베이스를 backend로 사용하는 웹 어플리케이션이면 SQL의 백업은 다른 저장소에 있을 것입니다.

Git에서는 하나의 저장소에 모든 것을 가지고 있을 수 있고 branch로 이것들을 분리할 수 있습니다.

보통 branch들은 디렉터리에서 파일을 공유하지만 Git에서는 빈 branch들을 만들 수 있습니다.

당신은 다음처럼 빈 branch를 만들 수 있습니다.

$ git checkout --orphan NEWBRANCH

--orphan 은 새로운 branch를 만드는 데 어떤 commit도 없이 시작합니다. 위의 명령을 실행하면 당신은 새로 만든 "NEWBRANCH" branch에서 작업중에 있는 상태가 됩니다. 이 상태에서 첫 번째 commit을 생성하면 조상이 없는 새로운 history로 시작하게 됩니다.

--orphan 명령은 원래 branch와 비슷한 새로운 history 트리를 생성하는 데 편리하도록 하기 위해 인덱스와 working tree 파일들이 영향을 받지 않도록 합니다.

당신은 원래 branch에서 아무 것도 하지 않은 새롭고 비어 있는 branch를 생성하기를 원하기 때문에, 새로운 작업 디렉터리에서 모든 파일을 삭제할 수 있습니다.

$ git rm -rf .

이제 당신은 파일들을 추가하기 시작하고 commit함으로써 자체 branch에 있을 수 있게 합니다. 만약 commit 로그를 본다면, 원래 log와 분리된 commit log를 보게 될 것입니다.

checkout 명령을 사용하여 원래 branch로 돌아가거나 다른 branch로 이동이 가능합니다.

$ git checkout master ( master branch로 돌아가기 )

$ git checkout NEWBRANCH ( 새롭게 분리된 branch로 돌아가기 )

당신은 --orphan 옵션을 사용하려면 git 1.7.2 이상의 버젼이 필요합니다.

궁금하신 점이나 수정사항이 있으시면 댓글을 남겨 주세요.


반응형
반응형

출처 

http://unix.stackexchange.com/questions/163352/what-does-dev-null-21-mean-in-this-article-of-crontab-basics

http://blogger.pe.kr/369

crontab에 관한 글에서 '>/dev/null 2>&1'의 뜻이 무엇인가요?

crontab에 관한 글을 읽고 있습니다.

다음은 자동으로 이메일 보내는 것을 불가능하게 하는 방법에 대한 내용입니다.

8.  이멩일 불가능하게 하기 

기본으로 cronjob을 실행하는 사용자 계정으로 이메일을 보냅니다. 이것이 필요하지 않으면 shell 명령어 끝에 다음 명령을 붙이세요.

>/dev/null 2>&1

2> & ,  1 의 자세한 뜻이 무엇입니까? cronjob 파일의 마지막에 이메일 보내는 것을 끄기 위해 왜 이걸 붙어야 합니까?

-------------

6개의 답변 중 1개의 답변만 추려냄.

>  리다이렉트(redirect)를 위한 것입니다. 

역자 설명) 화면에 출력된 내용(stdout)을 오른쪽에 나올 파일(여기서는 /dev/null)로 결과를 보내라는 뜻입니다.

/dev/null 은 어떤 데이터를 보내든 블랙홀로써 전부 버려질 것입니다.

2 는 표준 에러를 뜻하는 파일 디스크립터(file descriptor) 입니다.

>  리다이렉트(redirect)를 위한 것입니다. 

& 파일 디스크립터를 뜻하는 심볼입니다. (이 기호가 없으면 다음 1 은 파일이름으로 간주될 것입니다.)

1 은 표준 출력을 뜻하는 파일 디스크립터(file descriptor) 입니다.

그러므로 >/dev/null 2>&1 는 프로그램의 출력을 /dev/null로 보냅니다(redirect). 보낼 때 표준에러 와 표준출력이 포함됩니다.

더 많은 정보를 원하시면 리눅스 문서화 프로젝트 페이지 I/O Redirection 에서 확인 가능합니다.

cron 은 job의 출력이 있을 때만 이메일을 당신에게 보낼 것입니다. null로 redirect되는 모든 것에 대해 출력이 없기 때문에 cron은 당신에게 이메일을 보내지 않을 것입니다.



반응형
반응형

1. CLang-LLVM 설치


1. 리눅스 설치
위 사이트 설명에 맞춰서 설치하였습니다.
Clang 3.7 개발+디버그 버젼이라 빌드하는데 오랜 시간이 소모가 됩니다.
빌드는 64비트 컴퓨터의 CentOS 6.6에서 작업하였습니다.

1. LLVM checkout
llvm을 설치하고 싶은 디렉터리로 이동합니다.
$(HOME) 디렉터리 그대로 사용하였습니다.
svn으로 checkout하여 LLVM의 소스를 다운로드 받습니다.

  • svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
2. Clang checkout
  • cd llvm/tools
  • svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
  • cd ../..
3. 추가적인 Clang 툴들 checkout(옵션)
  • cd llvm/tools/clang/tools
  • svn co http://llvm.org/svn/llvm-project/clang-tools-extra/trunk extra
  • cd ../../../..
4. Compiler-RT checkout
  • cd llvm/projects
  • svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt
  • cd ../..
5. LLVM과 Clang을 빌드
Clang 3.7 개발+디버그 버젼을 설치하기 위해서는 gcc 4.7 이상 python 2.7이상의 프로그램이 필요합니다.
※ 다음 과정은 모두 root 계정으로 진행하였습니다.

5.1. CentOS 6에서 gcc 4.8로 업그레이드 방법
cd /etc/yum.repos.d
wget people.centos.org/tru/devtools-2/devtools-2.repo

yum install devtoolset-2-gcc
yum install devtoolset-2-binutils
yum install devtoolset-2-gcc-gfortran
yum install devtoolset-2-gcc-c++

scl enable devtoolset-2 bash

ln -s /opt/rh/devtoolset-2/root/usr/bin/* /usr/local/bin/
hash -r

5.2. python 2.7 이상으로 업그레이드.
cd /opt
wget --no-check-certificate https://www.python.org/ftp/python/2.7.6/Python-2.7.6.tar.xz
tar xf Python-2.7.6.tar.xz
./configure --prefix=/usr/local
make && make altinstall
$PATH /usr/local/bin이 있는지 확인.
ln -s /usr/local/bin/python2.7 /usr/local/bin/python

5.3 LLVM과 Clang 빌드
$(HOME) 디렉터리에서 다음 작업을 수행합니다.
  • mkdir build (원본 디렉터리를 오염시키지 않고 빌드하기 위해서)
  • cd build
  • ../llvm/configure
  • make
  • make install
윈도우 설치
위의 페이지에서 Download LLVM 3.6.0의 Pre-build Binaries에서 Clang for Windows를 클릭하여 프로그램을 다운로드 받습니다.




반응형
반응형

출처 : http://stackoverflow.com/questions/305035/how-to-use-ssh-to-run-shell-script-on-a-remote-machine

ssh를 사용하여 원격 컴퓨터의 shell script를 실행하는 방법?

저는 원격 컴퓨터에서 로컬 shell script(윈도우즈/리눅스)를 실행해야 합니다.

A 컴퓨터와 B컴퓨터 모두에서 설정된 ssh가 있습니다. 저의 스크립트는 B컴퓨터에서 수행할 내용이 A컴퓨터에 있습니다.

로컬과 원격 컴퓨터는 윈도우즈나 유닉스 기반의 시스템일 수 있습니다.

plink/ssh를 사용하여 이를 실행할 수 있는 방법이 있을까요?


20개의 답변 중 1개의 답변

만약 A 컴퓨터가 Windows box라면 -m 파라미터와 함께 Plink(PuTTY의 일부)를 사용하실 수 있고 원격 서버에 로컬(내 컴퓨터의) 스크립트를 실행할 것입니다.

plink root@MachineB -m local_script.sh

만약 A컴퓨터가 유닉스를 기반으로한 시스템이면 다음처럼 사용할 수 있습니다.

ssh root@MachineB 'bash -s' < local_script.sh

이를 수행하기 위해 스크립트를 원격 컴퓨터로 복사하실 필요가 없습니다.


(번역과 관련없는) 추가내용

ssh 뿐만이 아니라 rsh도 똑같은 방법으로 실행이 가능합니다.

ssh root@MachineB 'bash -s' < local_script.sh

ssh 계정명@원격호스트(IP) 수행할명령어 < 로컬_스크립트.sh

만약 원격 컴퓨터의 프로그램이 수행이 되지 않는다면

로컬_스크립트.sh에서 export LD_LIBRARY_PATH를 원격컴퓨터에 맞게 설정하셔야 됩니다.

예) export LD_LIBRARY_PATH=/usr/lib:/usr/local/lib

반응형

'리눅스 shell' 카테고리의 다른 글

expect  (0) 2015.08.09
리눅스 쉘에서 '>/dev/null 2>&1'의 뜻이 무엇인가요?  (2) 2015.07.10
rsync  (0) 2015.02.17
왜 쉘 명령어가 \(백슬래시)로 시작하나요?  (0) 2014.07.08
fg  (0) 2011.08.03
반응형

출처 : http://stackoverflow.com/questions/1282639/switch-git-branch-without-files-checkout

Git: 파일 checkout 없이 git branch 변경하기

= working area 변경 없이 git branch 변경하기

git에서 모든 파일을 checkout하지 않고 다른 브랜치로 변경하는 것이 가능한가요? 저는 branch를 변경한 후 모든 파일을 삭제하고 재 생성한뒤 commit하고 원래 branch를 다시 되돌렸습니다. 그리고 파일을 checkout하는데 시간이 너무 많이 걸립니다. (14000개 정도 파일이 있고 오래 걸립니다.)

분명히 하기 위해:

저는 github에 문서를 업로드 하였습니다.

저는 gh-pages branch를 가진 보관소(repository)가 있습니다. 저는 로컬 컴퓨터에서 문서를 재생성하여 그 파일들을 보관소 디렉터리에 복사하고 commit하고 github에 push하였습니다. 하지만 저는 로컬 컴퓨터에 문서의 복사본이 2개가 있기 때문에 내키지는 않습니다. 그리고 저는 'empty' branch를 만들기로 하고 'empty' 브랜치로 이동한 뒤 파일을 모두 삭제하였습니다. 하지만 원래 branch로 되돌아 오는데 오래 걸립니다. 그래서 이 질문을 합니다.

저는 gh-pages branch는 남기고 파일을 지울 수 있는 방법을 알고 싶지만 dirty working tree들을 남기고 싶지는 않습니다.

----

7 개의 답변 중 1개의 답변만 추려냄.

옙. 다음처럼 하시면 됩니다.

git symbolic-ref HEAD refs/heads/otherbranch
역자 주 : otherbranch는 변경하고자 하는 branch명입니다.

만약 이 branch로 commit할 필요가 있다면 해당 index를 리셋하길 원하시면 다음처럼 하시면 됩니다. 그렇지 않으면 마지막에 checkout된 branch를 기반으로 commit하여 마무리하시면 됩니다.
git reset


반응형

'Git' 카테고리의 다른 글

git log  (0) 2015.08.31
Git에서 새롭고 비어 있는 branch를 만드는 방법  (0) 2015.07.17
잃어버린 commit들 복구하기.  (0) 2015.01.22
Git: branch 포인터를 특정 commit으로 이동하게 하기.  (0) 2015.01.14
git config  (2) 2014.11.14
반응형

rsync

rsync는 두 컴퓨터 시스템을 똑같은 파일의 복사본으로 유지하는데 널리 사용되는 유틸리티입니다.

유닉스와 같은 시스템과 파일 동기화와 전송 2가지 모두 기능하는데 널리 사용됩니다.

rsync 알고리즘은 델타 인코딩 형태로 네트워크 사용량을 최소화합니다.

zlib은 추가적인 압축을 하는데 사용될 수 있고 데이터 보안을 위해 SSH나 stunnel이 사용될 수 있습니다.


사용예시

rsync -avz rsync://rsync.iana.org/tz/data/ ~/data/dst

rsync.iana.org/tz/data/의 디렉터리 안의 파일들을 $HOME/data/dst 디렉터리로 동기화 복사를 수행한다.


옵션

-a, --archive : archive mode

디렉터리까지 동기화 복사(-r, --recursive)를 하며, 심볼릭 링크(-l, --link), 파일권한(-p, --perm), 사용자 및 그룹 소유자(-g & -o), 수정시간(-t, --times) 도 유지하며 동기화 복사를 한다.

-v : verbose, 자세한 정보 출력)

-z : 압축전송.


출처

http://en.wikipedia.org/wiki/Rsync

http://linux.die.net/man/1/rsync

http://www.tecmint.com/rsync-local-remote-file-synchronization-commands/



반응형

+ Recent posts