echo_server.py

echo_client.py

bash 쉘 기준 명령어들의 종류를 살펴보면

ssaemo 파일을 실행한다고 가정할 때

sh ./ssaemo

. ./ssaemo

source ./ssaemo

변수명=변수값 ./ssaemo

(./ssaemo)

와 같은 명령어들을 사용한다.

무슨 차이일까?

cat ssaemo.sh

#!/usr/bin/env sh

ps

[ssaemo@interface ~]$ . ./ssaemo

  PID TTY          TIME CMD

18217 pts/0    00:00:00 bash

18335 pts/0    00:00:00 ps

[ssaemo@interface ~]$ source ./ssaemo

  PID TTY          TIME CMD

18217 pts/0    00:00:00 bash

18336 pts/0    00:00:00 ps

[ssaemo@interface ~]$ sh ./ssaemo

  PID TTY          TIME CMD

18217 pts/0    00:00:00 bash

18337 pts/0    00:00:00 sh

18338 pts/0    00:00:00 ps

. ./ssaemo

source ./ssaemo

위 두 명령어는 '현재 쉘'에서 쉘 스크립트를 실행한다.

> sh ./ssaemo

child process(sh)를 생성하여 해당 쉘에서 쉘 스크립트를 실행한다.

위 녹색 음영 처리된 프로세스가 그 쉘이다.

> 어떨 때 그 차이가 체감될까?

쉘 스크립트로 export SSAEMO="BYE"를 줬을 때

위 명령어는 현재 쉘의 환경변수에 선언이 된다.

그러나, 아래 명령어는 현재 쉘의 환경변수에는 영향을 끼치지 않는다.

그래서 source(또는 .) 명령어는 현재 쉘에 설정 파일을 즉시 include 해줄 때 사용한다고 한다.

또한 source 명령어는 'bash 쉘' 내부 명령어이다. 그러므로 bash 쉘에서만 사용할 수 있다.

변수명=변수값 test도 확인해보자!

[ssaemo@interface ~]$ cat ssaemo.c

#include <stdio.h>

#include <stdlib.h>

int main()

{

printf("%s\n", getenv("SSAEMO"));

return 0;

}

[ssaemo@interface ~]$ gcc -o ssaemo ssaemo.c

[ssaemo@interface ~]$ SSAEMO="HELLO" ./ssaemo

HELLO

[ssaemo@interface ~]$ export | grep SSAEMO

[ssaemo@interface ~]$ 

./test 와의 차이는

child process에 환경변수 SSAEMO를 선언하고 ./test 바이너리 파일을 실행한다는 것임을 확인할 수 있다.

그리고 스크립트 파일의 경우 보통 파일 첫 줄에 다음 내용을 입력한다.

#!/bin/sh

#!/bin/bash

#!/usr/bin/python

#!/usr/bin/env sh

#!/usr/bin/env bash

#!/usr/bin/env python

앞에 "#!"가 있으면 "이 파일을 실행할 때 다음 프로그램(ex:/bin/sh)을 사용하라"는 의미이다.

그럼 /bin/sh와 /usr/bin/env sh의 차이는?

전자는 절대 경로로써 dependency(의존성)이 발생할 수가 있다.

위 파일을 만든 후, 다른 환경에서 해당 파일 실행 시 sh 파일이 /bin 디렉토리에 없을 수도 있다.

하지만, 후자는 sh 파일의 경로가 다르더라도, 그 경로를 찾아서 실행할 수 있기 때문에 그런 문제를 해결해준다.

쉘에 /usr/bin/env sh를 입력하면 /bin/sh와 같이 쉘이 실행되는 것을 확인할 수 있다.

일단 필자가 테스트해봤을 때, 누락되거나 잘못 입력해도 문제가 생기는 경우는 아직 발견하지 못했다.

그래도 의미는 알아두자!

#!/bin/sh 또는 #!/usr/bin/python 라인은

맨 위에 녹색 음영처리된 방식으로 파일을 실행할 때

영향을 미친다.

위 방법으로 실행할 때

chmod +x [binary]를 통해 파일에 실행권한을 줘야한다.

source ~~와 . ~~는 같다.

sh ~~와 ./~~는 다르다.

뭐가 다르냐? 미묘한 차이다.

sh는 자식 쉘을 만든 후, 프로그램을 실행한다.

./~~는 프로그램 실행과 동시에 자식 쉘이 만들어진다.

다시 말해 sh는 sh;./~~와 같다.

필자가 잘못 이해하고 있는 것일 수도 있다.

그런데 굳이.. 중요한 정보는 아니라서..

python2.7에서 pip install 오류가 날 경우 : http://ssaemo.tistory.com/40

1. 

우선, https://bootstrap.pypa.io/get-pip.py 에서 get-pip.py 파일을 다운로드 받습니다.

필자는 c:\ssaemo\ 디렉토리에 다운로드 받았습니다.

python c:\ssaemo\get-pip.py

c:\ssaemo 디렉토리에 get-pip.py를 다운받았다고 가정

위 명령어로 pip 7.1.2를 설치합니다.

pip는 python package manager입니다. centos의 yum이나 debian계열의 apt-get같은 겁니다.

2. 

pip install virtualenv

virtualenv 패키지(모듈)를 설치합니다. 이게 어디에 쓰이는 물건인고? 뒤 부분을 보시면 이해됩니다.

3. 가상 환경 만들기

cd c:\ssaemo

python -m venv django_venv1

dir

cd django_venv1

설명 : 

python -m venv : venv(virtualenv) 파이썬 모듈을 실행합니다.

django_venv1 : 가상 환경의 이름을 'django_venv1'로 지정합니다.

4. 

scripts\activate                #가상환경 실행. Linux : " . /bin/activate "

pip install django==1.8         #django 1.8버전을 설치

pip list                        #installed package list 출력

Django가 설치된 것을 확인할 수 있습니다.

5.

가상 환경 밖에서 

pip list

엥? Django 패키지가 보이지 않습니다.

그리고 가상 환경에서는 안 보이던 패키지들(ex:virtualenv)도 보이네요.

이제 가상 환경이 무엇인지 이해가 되시나요.

가상 환경은, 말 그대로 가상 환경을 구성합니다.

외부의 영향을 받지 않는, 외부로부터 독립된 환경을 구성합니다.

더 구체적으로 말하면 위와 같이 가상 환경마다 패키지를 따로 구성할 수 있습니다.

다른 특징들도 있지만, 현재 체감되는 것은 이 뿐입니다. 

패키지를 따로 구성할 수 있을 때의 장점은

패키지 버전을 업그레이드할 때, 기존의 프로젝트들이 버전업에 대한

호환성을 고려할 필요가 없다는 겁니다.

VMware랑 비슷하다 생각하시면 됩니다.

pip : python install package. 즉, python package manager이다.

easy_install도 패키지 매니저지만, pip를 권장하는 듯?

> python2.7에서 pip를 설치할 떄 오류가 나는 이유

Windows에서 User Directory 이름이 '한글'일 때 python2.7에서 UnicodeEncodeError가 발생합니다.

즉, 경로 상에 한글이 포함되어 있을 경우 python2.7에서 에러가 발생합니다.

python3.5는 경로 상에 한글이 포함되어 있어도 상관없습니다. python3부터 문자열을 unicode로 처리하니까요.

필자는 python2.7에서 진행하기 위해 사용자 이름이 영문인 사용자 계정을 하나 더 만들고(해당 계정에 권한도 주었음)

해당 계정에서 진행하서 python2.7로도 pip를 잘 인스톨 할 수 있었습니다.

(get-pip.py 내부 코드가 멀티바이트(한글)도 처리할 수 있도록 수정하는 방법도 있습니다만.. 이게 더 쉽습니다)

요약 : pip 설치 시 python2.7 쓰려면 경로에 한글 없어야함. python3.5는 상관없음.

> Qt Creator needs a compiler set up to build. Configure a compiler in the kit options

sudo apt-get install g++ 

sudo apt-get install libgl1-mesa-dev libglu1-mesa-dev

QT Rerun and Qmake+Build !

Reference : 

http://stackoverflow.com/questions/14700965/qt-creator-needs-a-compiler-set-up-to-build-configure-a-compiler-in-the-kit-opt

앞에는 명령어들만 나열

설명은 아래에

어차피 필자 본인 말고는 읽어도 이해가 잘 안될듯.

환경 : ubuntu linux

<command>

 - 환경 설정

sudo apt-get install git : git 설치

git config --global user.email "id@example.com"

git config --global user.name "ssaemo"

 - 저장소repository 설정 (Local)

<repository 만들기>

git init : local repository 생성

git status : 상태 확인

git add -A : ALL option

(git status)

git commit -m "first commit" : message option

(git status)

local repository를 삭제하고싶은 경우 : rm -rf ./.git

<repository 가져오기>

git clone URL

ex) git clone https://github.com/ssaemo/ubuntu_src.git

 - 저장소repository 설정 (Remote)

git remote (-v) : 해당 local repository에 등록된 remote repository 확인

git remote add 별명 URL : 아래에서 별명 origin, URL 설명

git push origin master : origin에 master branch push

username, password 입력

완료!

<설명>

git config --global : ~/.gitconfig 파일 수정. 해당 유저의 설정.

git config --system: /etc/gitconfig 파일 수정. 시스템 내 모든 사용자의 설정.

git config : ./.git/config 파일 수정. 해당 repository(저장소)의 설정.

origin : 별명 중 특별한 것으로, repository를 init이 아닌 clone 해왔을 경우, clone해온 remote repository가 자동으로 origin으로 등록된다.

remote repository URL : github.com를 예로 들면 repository를 만들고 들어가보면 우측에서 HTTPS clone URL을 확인할 수 있다. ex) https://github.com/ssaemo/ubuntu_src.git

master : repositry의 기본 branch. 필요에 따라 더 만들 수 있다. master 뿐이라면 master는 곧 repositry인 것이다.

<file 상태>

     파일 수정 -> Modified -> Staged -> Committed -> 파일 수정 -> 

working                                staging         local

directory                                area        repository

이후부터는 local repository에는 수정 전 상태가,

            working directory에는 수정 후 상태가 저장되어있다.

<구조>

working directory

staging area(index) : 가상 공간

local repository(HEAD) : 가상 공간

remote repository : ex)github

branch

<명령어 간단 이해>

commit을 snapshot이라고 생각하자.

staging(add)는 snapshot의 준비과정일 뿐이다.

push는 remote repository에 commit하는 것이다.

---

<그외 커맨드들>

git diff

 - 변경사항(changes)들을 stage(add) 하기전에 확인해보는 커맨드

 - 즉, stage되지 않은 changes를 출력

git reset [--soft | --mixed | --hard]

 - stage(add)된 변경사항들을 reset

 - ex) git reset --soft HEAD^

git submodule update --remote

 - submodule들을 latest version으로 update (github 등의 remote server로부터)

Reference : 

LPSTR, LPCSTR, LPTSTR, LPCTSTR , LPWSTR, LPCWSTR 의 의미

http://egloos.zum.com/pelican7/v/1768951

자료형의 크기

http://dev.likejazz.com/post/69840022906/long과 int는 크기가 같은데 왜 존재하나요?

위 출처를 중심으로 구글링하여 아래 요약했다.

C Data Types

그리고 마지막!

#include <windows.h>

DWORD = unsigned long;

QWORD는 거의 안쓰임.