웃는 모습 보기 좋구나

[SIP 개요]

[SIP 특성]

[SIP 기반 네트워크]

- SIP 단말 : 전화기, 이종 망에 대한 게이트웨이(SS7 지원하는 VoIP GW, SSW)

- SIP 서버 : 필요한 부분에 대해서만 SIP 서버를 사용하며 전적으로 SIP 서버를 의존하지 않는다.

SIP 단말은 수신자의 정확한 주소 정보가 없어도 오로지 invite 메시지만으로 호 설정 가능(sip 서버 사용)

SIP 서버는 필요 시 수신자의 다른 단말로 경로 변경 가능(FORKING),

[SIP 기본 특징]

- 주소 지정 방식 : URI, URL 모두 사용, Email 형식, E.164 형식

- 사용자 등록 : 단말은 원활한 호 설정을 위해 서버에 등록된다. 한 사용자가 여러 PC에서 동일한 서비스 사용 가능.

전화망에서처럼 교환기에 의해 미리 설정된 경로를 통해서만 서비스가 이루어지는 것과 대조적

- 보안

- 수신 대체(Redirect) : SIP 서버는 단말의 서비스 요청을 다른 서버에 대체할 수 있다. 지능망(AIN)의 해당 기능과 유사

- Proxy : SIP Proxy Server 는 특정 서비스를 요청하는 경우 해당 서비스를 제공 할 수 있는 다른 서버로 그 요청을 전달

- Forking : 등록 단말이 여럿인 경우 요청을 상대방의 여러 단말로 동시에 전달

- 상태정보와 랑데부(Rendezvous) : 랑데부의 동적 형태는 필요한 서비스를 제공할 수 있는 서버나 단말로 호 설정을

직접 요청하는 것으로 구성된다. 반면 수동 형태에서는 상태정보로 구성된다. 즉 단말에서 어떠한 서비스를 필요로

한다는 것을 상태정보 등록을 통해 상대방이 알도록 한다.

- 이동성 : 다양한 통신 단말과 다양한 망 사용(IP망, 전화망, 이동통신망, Wibro망, WiMAX 등)

- 사용자 취향(User Preferences) : 발신자는 자신의 요청이 서버나 망에서 어떻게 처리될지를 정할 수 있다.

통화 가능은 물론 원치않는 상대방 그룹을 미리 지정할 수 있고, 상대방이 통화중이거나 자동응답기이면 아예

연결되지 않도록 설정할 수도 있다. 수신자 입장에서도 발신자가 누구인지, 어디에서건 전화인지, 통화 시간대,

단말 종류 등 다양한 기준에 따라 수신 여부를 능동적으로 결정할 수 있다.

- 경로 제어 : SIP 메시지의 전달 경로 또한 제어되거나 저장할 수 있다.

=> 이런 대부분의 기능들이 지능망(AIN)이나 웹, 이메일에서 사용되지만 기존 전화망에서는 제공되지 않는 SIP만의

기능들이다.

* 랑데부(클라이언트와 서버, 서버와 서버간 메시지 전달 프로토콜, RVP라고 함. draft-calsyn-rvp.txt 참고)

[표준 제정 과정의 투명성]

- 개방성 : 열린 개발 과정 표준화 제안, 방대한 표준 문서

- 자발적 기여

- 넘쳐나는 창의성

- 실행 코드에 근거한 SIP 표준화 : 표준 확정 되기전에 기능 구현을 통해 검증

[SIP 범위]

SIP는 양방향 세션의 시작, 수정, 종료에 관한 프로토콜이다. SIP는 장치 제어나 원격 프로시저 호출(RPC)를 위한

프로토콜은 아니다. 그렇다고 전송 프로토콜도 아니다. 메시지가 첨부되기도 하지만 대용량 데이터나 스트림 전송에

사용할 수는 없다. SIP 메시지가 설정한 전송 경로가 뒤에 따라오는 미디어의 전송 경로를 보장하는 것은 아니기 때문에

자원 예약(RSVP) 프로토콜도 아니다. SIP는 PSTN을 대체하는 프로토콜도 아니다. SIP의 틀은 전화의 시그널링 프로토콜

이나 통화 모델과 근본적으로 다르다. 물론 GW를 통해서 PSTN과 상호 연동할 수 있지만 그렇다고 SIP의 기본 역활이라

할 수 없다. SIP는 세션 관리 프로토콜이 아니라 세션 설정 프로토콜이다.

SIP는 VoIP 프로토콜도 아니다. VoIP는 SIP 네트워크에서 제공 될 수 있는 여러 서비스 가운데 하나일 뿐이다. SIP는

오로지 시그널링 프로토콜로써 미디어에 관한 사항, 즉 미디어 타입, 종류, 서비스 등에 대해서는 전혀 규정하지 않는다.

반면 H323은 그 이전의 ISDN 처럼 시그널링은 물론 미디어, 호 기능, 서비스, 세션 제어 등 모든 사항이 포함되어 있다.

[SIP 소개]

http와 smtp 를 바탕, 기본 목적은 세션 설정(Initiation)이다. 메시징 presence 기능 제공도 포함.

SIP는 P2P 프로토콜로써 세션에 참여하는 상대는 서로 대등한 관계지만 http 처럼 서버-클라이언트 트랜잭션 모델을

사용한다. SIP 클라이언트는 SIP Request 를 요청하고, SIP 서버는 응답 메시지를 통해 클라이언트의 요청에 응답한다.

SIP 메소드 : invite, ack, bye, cancel, register, options, info, prack, update, refer, subscribe, notify, message, publish

SIP 응답 코드 : 1xx, 2xx, 3xx, 4xx, 5xx, 6xx

------------SIP 메시지의 행별 설명------------

[SIP 네트워크 구성 요소]

유저 에이전트 : SIP UA는 http 와 달리 SIP UA가 서버도 되고 클라이언트도 된다.

서버(RFC3261) : Proxy, Redirect, Registrar

- Outbound Proxy : UAC가 invite를 보낼 때 경유하는 Proxy 서버

- Incoming Proxy : SIP URI에 포함된 domain 주소로부터 해당 domain 의 Proxy 서버 IP가 추출된다.

이 경우 Proxy 서버는 걸려오는 호를 해당 도메인으로 유도하는 데 사용되기 때문에 Incoming Proxy 로 불린다.

SIP Registrar 서버는 UA에 수동 설정하거나 IP 멀티캐스팅을 통해 접근 될 수 있다.

또 UA는 자신의 1차 Proxy 서버에 등록 메시지를 보낼 수 있는데, Proxy 서버가 등록 요청을 Registrar 서버로 전달한다.

위치지정 서비스(Location Service)는 곧 DB라 할 수 있다. DB에는 URI, IP주소, Script, 사용자 취향 등 사용자 정보,

SIP 네트워크 라우팅 정보도 포함 된다.

[SIP 기능들]

주소 결정, 세션 관련 기능들, 호 중간 시그널링, 호 제어, QoS 호 설정, 세션 외 기능

[주소 결정]

Addrss Resolution 은 SIP 의 중요 기능. SIP주소 결정은 보통 URI로 시작하여 IP주소와 사용자명을 파악 하는 것.

주소 결정은 UA, Server 모두 수행 가능.

주소 결정 과정 절차

- DNS NAPTR 문의 : RFC 3263에 의거, 전송 프로토콜을(TCP, UDP, SCTP) 결정

- DNS SRV 문의 : RFC 3263에 의거, 서버 호스트 이름과 포트 번호를 결정

- DNS 문의 : 호스트의 IP 주소를 결정

- ENUM 문의 : 전화번호라면 그 번호를 찾음

- 위치지정 서비스 문의 : 주소 문의가 Proxy 서버로 미뤄질 때에는 RFC 3261 에 의거, 위치지정 서비스를 참조

주소 결정 과정의 request 메시지는 UA나 Proxy 의 Hop 별로 DNS나 라우팅 테이블에 문의하여 목적지 까지 전달된다.

반면 response 는 역으로 보내기 때문에(Via 헤더 기록 참고) 주소 결정 과정이 필요 없다.

SIP의 주소 결정 절차는 dynamic 하다. Proxy 는 request 메시지 내의 여러 정보와 다양한 헤더를 경로 설정에 할용

(timestamp 시간정보, From 헤더, 자동 호 분배 ACD 나 부하 분산을 위한 여러 헤더)

이런 주소 결정 과정은 세션 시작 시점에 단 한번만 수행된다. 한번 파악된 주소들은 저장되어 이후 메시지 전송 시 사용.

[* IP의 SIP 메시지 전송]

IP-TCP(TLS SSL), UDP(Datagram TLS-DTLS, 일반), SCTP 를 통해 전달.

SIP는 자체 신뢰 보장 체계를 가지고 있어서 UDP 처럼 보장 체계가 없는 'best effort' 전송 프로토콜도 사용 가능.

하나의 SIP 메시지가 여러 hop 으로 전달 되는 경우 각각의 홉 구간은 UDP or TCP가 될 수 있다. 사용된 전송 프로토콜은

메시지 IP 주소 및 Port 번호와 함께 Via 헤더에 기록된다.

UDP는 SIP 전화기 처럼 간단한 User Agent 가 주로 사용

TCP는 Proxy 서버 간, 또는 장시간 연결이 필요한 경우 주로 사용

SCTP 는 대용량의 트래픽 처리와 낮은 지연시간을 요하는 대용량 PSTN GW와 Proxy 간 연결 설정의 위해 주로 사용.

[세션 관련 기능들]

[세션 설정]

UAC는 세션을 시작하면서 (To,From,Call-ID) 헤더를 설정하는데, 이 3가지 정보를 "dialog" 라고 부르며 하나 세션 구분.

한 세션 동안 변경 되지 않는다. 이 정보와 기타 미디어 정보를 추가한 것을 '호 상태' 라고 하며 UAC는 반드시 이 호 상태

를 기억하고 있어야 한다. ( UAS는 UAC의 Call-ID, UAC의 To 값을=>From, UCA의 From 값을=>To 사용한다 )

인터넷 철학이 그러하듯 SIP 호 상태는 네트워크 내부가 아닌 SIP 단말에서 유지된다. 물론 SIP Proxy 서버도 세션 설정

과정을 기록 할 수 있지만 SIP 호 상태를 단말이 기억하게 함으로써 호 설정을 망에 독립적으로 관리할 수 있다.

성공 : INVITE/200/ACK

실패 : INVITE/4xx, 5xx 또는 6XX/ACK

INVITE는 ACK를 동반하는 유일한 메시지. 나머지 요청의 메시지들은 Request/200, Request/4xx, 5xx , 6xx 로 응답 한다.

설정과정에서 100, 180 진행 응답(1xx, provisional message)메시지가 있을 수 있다.

호 성립 되면 더 이상의 SIP signal 메시지 없이 미디어 세션이 진행된다. 그러나 'SIP Session Timer' 를 사용하면

일정 시간 이후 미디어 세션의 종료, 즉 통화시간을 제한할 수 있다. 세션 성립 과정 중에 forking 기능 가능

[미디어 협상]

SIP 자체로 media 협상 지원 하지 않기 때문에 협상은 SDP 를 통해 이루어진다.

INVITE(with SDP)/200ok(응답) or INVITE/200ok(SDP)/ACK(응답) -> RFC 4317(SDP 제안/응답 모델)

추가적인 media 협상은 re-INVITE 메시지를 통해 가능.

하지만 SDP를 이용한 media 협상은 다소 제한적일 수 밖에 없어 SDPng 로 불리는 SDP 보안할 새로운 표준 검토 중

------------SDP 제안 예------------

------------SDP 응답 예------------

[세션 변경]

세션은 INVITE/200/ACK 과정을 통해 설정. 세션 변경은 re-INVITE/200/ACk 과정으로 이루어 진다.

세션 당사자 어느 쪽에서든 요청될 수 있다. 이전 INVITE와 동일한 To, From, Call-ID 를 사용한다.

re-INVITE가 거절되어도 기존 미디어 세션에는 아무런 영향을 끼치기 않는다.

re-INVITE가 수락되면 기존 미디어 세션은 새로운 미디어 세션으로 대체된다.(새로운 SDP의 내용 수정 가능)

[세션 종료BYE 및 취소CANCEL]

CANCEL 은 INVITE 후 최종 응답 메시지(2xx,3xx,4xx,5xx,6xx)를 받기 전에 CANCEL 메시지를 보내는 경우.

Forking 과정에서 Proxy 가 여러 수신 단말에 동시에 CANCEL 을 보내 호 취소를 한다.

INVITE와 BYE는 단말 대 단말 메소드인 반면 CANCEL은 홉 단위 메소드이다. CANCEL을 받은 Proxy 는

200ok 응답을 보내고, 해당 INVITE를 보냈던 원래 목적지에 CANCEL 메시지를 전달.

CANCEL 을 받은 UA는 해당 INVITE에 대한 최종 응답 메시지를 아직 보내지 않았다면 200ok 를 보내고

이어서 486 Request Cancelled 로 정상 호 취소 상태가 된다

하지만 이미 INVITE에 대한 응답 메시지를 보낸 후라면 481 Transaction Unknown 메시지로 응답한다.

[통화중 시그널링]

통화중 시그널링(Mid-call signaling)이란 두 UA 사이에 설정된 현재 세션 파라미터를 변경하지 않는 시그널링 메시지의

교환을 의미. 만약 현재 세션 파라미터를 변경한다면 re-INVITE를 사용한다. 그 외의 경우 SIP INFO 메소드가 사용.

즉 교환 정보는 INFO 의 메시지의 본문으로 전달된다. ISUP(ISDN User Part)망의 경우, ISDN USR(User to User Message)

에 포함된 통화중 시그널링 정보는 INFO 메소드를 통해 전송된다.

[호 제어]

SIP는 BYE는 단대단으로 이루어 진다. 하지만 두 UA간 호 제어 및 관리를 제3자가 하면 훨씬 다양한 서비스 가능.

제3자가 호 제어 구현 방법 2가지. 첫번째 제어기가 발신자의 SIP INVITE 요청에 중간에 직접 응답하고 원래 수신자를

제3자로 INVITE 하는 방식이다. 제어기는 발신자와 제 3자간 시그널링의 중간에 위치하며 SDP를 중계하는 등

드러나지 않게 호를 제어할 수 있다.(결국, MiTM 같은 원리 인가 보다) 두번째는 REFER 메소드를 사용하는 방법.

A와 B가 세션을 설정하고, REFER 요청을 통해 B로 하여금 C와 호를 맺도록 하는 예.

REFER를 이용한 호 제어 예

아래는 Originator<-->Recipient 통화 중 Originator 이 콜 트랜스퍼 해서 Recipient<-->Final-recipient 통화

또는 Click to call 에서 활용

user1@sip 계정 권한을 가진 유저가 웹(또는 프로그램에서)에서 user2@sip 로 전화 걸게 되면

Web Server 가 Invite 를 자신의 user1@sip 로 보내어 전화를 걸게 됩니다. 이후 REFER 를 보내어

user1@sip 이 user2@sip 와 통신을 하게끔 합니다. 이후 Web Server 가 BYE를 보내게 되고

user1@sip 는 user2@sip 로 전화를 걸게 됩니다.

http://level7systems.co.uk/en/blog/Click+to+Call+with+PHP-SIP

REFER 의 메시지의 Refer-TO 헤더는 A가 호를 설정해야 할 상대방의 URI를 나타내고 Referred-By 헤더는 호 설정을

요청하는 제3자인 자신을 나타낸다. Referred-By 헤더는 B의 INVITE 메시지에도 포함되어 C로 하여금 호를 요청한

주체가 누구인지 알 수 있게 한다.

[호 설정 전제 조건]

SIP 확장 부분에서 QoS 알아보자. re-INVITE 를 이용할 수 있다. 먼저 'best-effort' 철학에 근거하여 세션을 설정 한 후,

조건에 만족되지 않으면 re-INVITE를 통해 세션을 변경하는 것이다. 하지만 SIP 메세지는 미디어로 부터 독립적이므로

새로운 세션의 설정은 기본 세션이 실패하였을 경우, 즉 미디어 전송에 필요한 대역폭의 절대부족으로 세션이 중단되는

경유에 가능하다. 따라서 re-INVITE 방식으로는 원하는 QoS 를 항상 보장할 수 없다. 다른 방법은 PSTN 방식을 따라하는

것으로 수신측에서 판단하기에 세센에 필요한 충분한 대역폭이 준비되어있지 않으면 아예 벨을 울리지 않도록 하는

것이다. 이 방식은 Voice over Cable Modem 프로젝트를 목적으로 하는 PacketCable 컨소시움에서 개발되었있다.

Prack, Update 를 사용하는 Call Flow 로 설명 진행 <- 아쉽게 그림이 없음 --;

세 가지 SIP 확장

1. Early Media 로써 183 Session Progress 진행 메시지에 SDP를 실을 수 있게 확장한 것이다.

이를 통해 두 UA는 호 요청이 응답되기 전에 QoS 관련 협의를 SDP를 통해 서로 주고받을 수 있다.

2. 신뢰성있는 진행 메시지(Reliable Provisional Response)로의 확장으로써 183 응답과 같은 진행메시지가 제대로

전송되지 않았을 경우 이를 발견하여 재전송하도록 한 것이다. 183 응답의 수신을 확인하는 메시지가 바로

PRACK(Provisional Response ACKnowledgement)이다.

3. COMET(preCOnditions MET) 메소드이다. UAS 는 COMET 을 받고 나서 QoS 협의가 수락되었음을 알고 벨을 울린다.

이후는 이랍ㄴ 호 처리과정과 동일하다. 현재는 COMET 대신에 동일한 의미로써 UPDATE 메소드가 사용된다.

위 3가지 확장은 첫 INVITE 메시지의 SDP의 마지막 줄의 qos:mandatory 항목에 의해 유발된다.

a=qos:mandatory

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

[SIP의 메시지 재전송]

SIP는 request, response 가 분실되었을 경우 거의 대부분 자동으로 재전송 한다. 발신측이 메시지 전송과 동시에

타이머를 작동시킨다. 이 첫 번째 타이머를 T1이라 하며 초기 설정값은 보통 500ms 이다. 이 시간동안 응답 메시지가

전혀 오지 않으면 원래 요청 메시지를 재전송하고, 타이머 시간내에 진행 메시지(1xx)가 오면 발신측은 보다 긴 타이머인

T2(초기값은 4초)를 작동시킨다. 만약 발신측의 요청 메시지 자체가 분실되었다면 수신측은 요청 메시지를 받지 못할

것이고 응답 메시지 또한 생성하지 않을 것이다. 이 경우에는 수신측 T1 타이머의 시간이 다하게 되고 발신측은 요청

메시지를 재전송한다. 재전송된 요청 메시지를 받은 수신측은 자신이 보낸 응답 메시지가 분실되었음을 알게 되고

그 응답 메시지를 재전송한다.

INVITE 요청 메시지의 경우는 다른 요청 메시지의 경우와 그 처리 방식이 다르다.

INVITE 요청의 최종 응답은 수신측 사용자가 수화기를 들어야만 가능하므로 그 시간이 상대적으로 길다.

따라서 발신측은 INVITE 요청에 대한 진행 응답(Provisional Response)을 수신하더라도 타이머 T2를 작동시키지 않고

대신에 더 이상의 INVITE 요청 메시지 재전송을 중단한다. 수신측에서는 INVITE 메시지를 수신하고 나서 최종 응답

메시지를 전송할 때 비로소 T1 타이머를 작동시킨다. 만약 발신측으로부터 타이머 시간내에 ACK를 보내오지 않으면

그 응답 메시지를 재전송한다. 이러한 절차를 통해 분실된 INVITE나 최종 응답 메시지, 즉 ACK의 확실한 전송을 보장하게

된다. 이와 같은 재전송 규칙의 예외는 진행 메시지이다. 진행 메시지는 ACK를 요구하지 않기 때문에 그 메시지가

분실되었는지 잘 수신되었는지 확인할 방법이 없다. 그래서 PRACK 라는 신뢰성 있는 진행 응답

(Reliable Provisinal Responese) 메시지 확장이 개발되었으며 이를 통해 SIP의 모든 요청 및 응답 메시지에 대한 신뢰성을

보장 할 수 있게 된다.

GK#sh sip-ua timers

SIP UA Timer Values (millisecs unless noted)

trying 500, expires 180000, connect 500, disconnect 500

prack 500, rel1xx 500, notify 500, update 500

refer 500, register 500, info 500, options 500, hold 2880 minutes

tcp/udp aging 5 minutes

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

[세션 외 기능들]

[이동성]

SIP의 등록 기능은 이동전화에서의 등록과 유사하다. 사용자는 Proxy로 보내는 등록 메시지에 수신 가능한 URI을 실어

보낸다. 등록 서버(registrar server 는 위치 서버(Location Server)에 있는 사용자 레코드를 갱신하고 등록 확인 메시지인

200ok 응답을 보낸다. 사용자가 사무실을 떠나 집에 도착하면 집전화를 새로 등록하면 사무실 SIP 전화기의 등록은

취소한다. 전화기와 등록서버 간에 SIP를 사용하지만 등록서버와 위치서버는 다른 프로토콜을 사용 할 수 있다.

또한 집 전화기도 반드시 SIP단말일 필요는 없고, PSTN 전화기이더라도 웹이나, 이메일, 또는 다른 등록 프로그램을

통해 등록할 수 있다.

다수의 URI를 함께 등록할 수 있으며 선호하는 순서로 우선순위가 주어진다.

아래 처럼 우선순위의 3가지 URI를 등록 할 수 있다.

<SIP client to Registrar>

REGISTER

...

Contact: sip:usera@4.3.2.1;class=personal

Contact: tel:+1-314-555-1212

Contact: mailto:usera@here.com

<Registrar to SIP client>

200 OK

...

Contact: sip:usera@4.3.2.1;class=personal

Contact: tel:+1-314-555-1212

Contact: mailto:usera@here.com

Contact 헤더의 SIP URI 에 확장된 파라미터들이 추가될 수 있다. 통화자 취향(Caller Preferences) 표준에서 볼 수 있는

확장 파라미터들은 통해 사용자는 URI 단말에 대한 부가정보를 지정할 수 있다. 즉 첫번째 URI는 개인 URI, 둘째는

음성메일, 셋째는 업무용, 넷째는 이동전화로 지정할 수 있다. 순서대로 호 시도를 하게 된다.

비슷한 예로 Reject-Contact 헤더도 있는데 특정 단말이나 방식으로의 연결은 원치 않음을 지정할 수 있다.

Proxy가 SIP 메시지를 처리할 때, 해당 메시지를 Proxy 방식으로 처리 할 지, 다른 서버로 대처 할 지, 다수 단말을

순차적으로 시도할지 아니면 동시에(forking) 시도할지에 대한 결정은 서버의 재량이다.

하지만 Request-Disposition 헤더를 사용하면 그 처리방식을 발신자가 직접 지정할 수 있다.

예를 들어 Request-Disposition: proxy, sequential 헤더는 해당 호 연결이 대체(redirect) 방식이 아닌 Proxy 방식 방식으로,

수신 단말들을 동시에 시도하지 않고 순차적으로 시도하도록 지정한다. 통화자 취향 표준에 기술되어 있다.

UA는 Requires:prefs 헤더를 추가하여 등록서버가 사용자 취향 정보를 처리하도록 요청할 수 있다.

[메시지 전달]

MESSAGE 메소드는 해당 URI로 메시지를 전달할 때 사용된다. MESSAGE 메소드 전달은 해당 세션의 내외 모두에서

가능하다. URI가 SIP 가 아니라 IM URI를 사용한다. A가 보낸 것을 받으면 B는 200 ok 응답을 보내게 된다.

INFO 메소드는 두 UA 간에 세션이 설정되어 있어야만 전달될 수 있는 반면에 MESSAGE 메소드는 세션 설정에

관계없이 아무 때나 전달될 수 있다.

To: User B <im:userb@there.com>

From: User A <im:uesra@here.com>;tag=4541232ds

[이벤트 알림요청 및 알림]

SUBSCRIBE(알림요청), NOTIFY(알림)는 특정 이벤트에 대한 알림을 요청하고 정보를 제공하는 기능이다.

수신자가 통화중일 때 통화가 끝나는 즉시 발신자에게 전화를 걸어주는 자동 콜백 기능을 들 수 있다.

아래 처럼 A->B로 전화 시 B가 통화 중이면 486으로 통화 중이라는 응답을 받는다.

A는 B에게 통화를 마치면 알려달라는 신호로 Subscribe 메시지를 보내고 B가 통화를 끝낸 후 Notify 메시지를 보내면

A는 세션을 설정한다.

알림요청 메시지의 Event 헤더는 요청하는 이벤트가 무엇인지를 나타낸다 만약 B가 해당 이벤트의 알림을 원치 않을

경우에는 603 Decline 응답으로 거부할 수 있다. Subscribe, Notify 는 서버 없이 구현될 수도 있고, PUBLISH 메소드를

통해 서버를 사용하는 구현도 가능하다.

[상태정보 알림]

SIP PUBLISH 메소드를 통해 UA는 자신의 상태정보를 상태정보 서버에 저장하거나 공개할 수 있다.

상태정보 서버는 저장된 정보를 원하는 사용자들에게 보낸다.

[인증]

두 가지 인증 제공(UA간, UA와 Server간) , 서버와 서버간은 SIP 자체로는 제공하지 않고 다른 프로토콜(ex. IPSec)로 제공.

SIP 인증은 대부분 http 에서 가지고 왔으며 대표적인 예가 SIP Digest 인증 이다. 어떤 SIP 메시지도 인증을 요구 받을 수

있다. SIP와 Proxy 간 인증은 407 응답 사용. 단 Proxy 와 Proxy 간 인증은 없다. 대신 IPSec 등을 사용 한다.

[확장성]

SIP 확장이 쉽다. 기존의 서버나 Proxy 변경 없이 개별 UA들은 메시지 본문이나 새로운 헤더를 이용하여 확장된 기능을

구현할 수 있다. 메시지에 잘 모르는 헤더나 요청이 포함되어 있더라도 수정없이 전달한다. 요청자는 Supported 헤더에

새로운 확장이 포함되어 있다는 정보를 실어 망과 사용자에게 알려주며 이를 어떻게 처리할 지에 대한 안내를 제공한다.

만약 확장된 기능이 반드시 처리되어야 할 사항이라면 Require 헤더를 이용하여 명시한다. 이 메시지를 받은 UA가 추가된

기능에 대해 모르거나 지원할 수 없으면 오류 응답을 보낸다. 또한 Proxy-Require 헤더를 통해 메시지가 전달되는 과정에

위치한 Proxy들이 처리해야 할 확장 기능임을 명시할 수 있다. 하지만 이러한 헤더의 사용은 호 성공률을 낮추고 원활한

상호 연동을 제한할 수 있기 때문에 가급적이면 사용하지 않는 것이 좋다.

또한 UA는 Allow, Supported, Allow-Events 및 Accept-Content 헤더를 통해 자신이 지원 가능한 기능과 메소드들을

분명하게 명시하는 것이 바람직하다.

일관성 있고 최적화된 Ajax 응용 프로그램

브라우저, 시스템, 사용자에 내재하는 차이점을 고려하자

브라우저, 컴퓨터 시스템, Ajax 응용 사용자가 모두 똑같다면 개발자가 얼마나 편할까요? 안타깝게도 현실은 그렇지 못합니다. 개발자는 다양한 브라우저, 컴퓨터 시스템, 사용자 환경에서 일관성 있게 동작하는 응용 프로그램을 구현하느라 온갖 골칫거리에 시달립니다. 사용자가 Ajax 프로그램을 한 브라우저 유형에서 다른 브라우저 유형으로 옮기면 (특히 웹 서비스 포털로 옮기면) 각 브라우저 본래의 제약으로 인해 프로그램이 똑같이 돌아간다는 보장이 없습니다. 이 기사에서 필자인 Judith Myerson은 브라우저, 시스템, 사용자에 내재하는 제약을 간략히 설명합니다. 또한 프로그램을 짜면서 주의할 함정, 브라우저 차이를 최적화하는 방법도 소개합니다.
시작하면서

다양한 브라우저, 컴퓨터 시스템, 사용자 환경에서 일관성 있게 동작하는 Ajax 프로그램을 구현하려는 개발자는 다양한 난관에 부딪힌다. 사용자와 개발자가 여러 브라우저를 차별없이 사용하는 경우가 흔하기 때문이다. 사용자가 프로그램을 한 브라우저 유형에서 다른 브라우저 유형으로 옮기는 경우도 흔하므로 Ajax 개발자는 다양한 시나리오를 고려해야만 한다. 하지만 브라우저마다 고유한 제약이 존재하는 탓에 모든 브라우저에서 완벽하게 돌아가는 프로그램을 내놓기는 매우 어렵다. 브라우저에 내재하는 제약은 Ajax 프로그램이 웹 페이지를 표시하는 방식에 (심지어 Ajax 프로그램이 동작하는 방식에) 영향을 미치기도 한다.

많이 사용하는 브라우저는 마이크로소프트 인터넷 익스플로러(Microsoft® Internet Explorer®), 오페라(Opera), 파이어폭스(Firefox), 컨쿼러(Konquerer)다. 리눅스에서만 돌아가는 컨쿼러를 제외한 나머지는 모두 윈도, 리눅스, 애플 맥 OS X에서 돌아간다. 현재 인기 있는 브라우저가 여러 개이므로, 개발자로서 인기 브라우저를 비교하여 차이점을 익혀두면 유용하다. 이 기사에서는 먼저 컴퓨터 시스템의 (메모리, 디스크 크기, USB 포트 수 등의) 하드웨어 차이점, (글꼴 가용성, HTML 확장 기능, 폼 요소 같은) 소프트웨어 제약을 살펴본다. 다음으로 브라우저 성능 문제를 고려한다. 마지막으로, 사용자가 Ajax 프로그램을 특정 브라우저 유형에서 다른 브라우저 유형으로 옮기거나 웹 서비스 포털로 옮길 가능성을 대비하여 브라우저 차이를 최적화하는 해결책 몇 가지를 제안한다. 이 과정에서 Ajax 개발자가 흔히 빠지는 함정(또한 피하는 방법)을 소개한다.

컴퓨터 기종은 많고 시간은 없다!

많은 개발자가 PC에서 웹 페이지를 Ajax 포털로 변환하지만, 매킨토시 사용자도 같은 변환을 수행한다. PC와 매킨토시에서 같은 브라우저 최신판으로 웹 페이지를 열어보면 두 컴퓨터에서 페이지가 다르게 보인다는 사실을 알아챌 것이다. 게다가 같은 기종이라도 모델이 다르면 화면 크기와 캔버스 크기가 달라지기도 한다. 어떤 매킨토시 모델은 PC 모델과 똑같이 설정해도 캔버스 크기와 해상도가 크게 차이난다. 컴퓨터 기종과 모델에 내재한 차이점은 단순히 글꼴 크기나 외양만이 아니라 다른 설정에도 영향을 미친다.

다양한 브라우저, 운영체제, 컴퓨터 기종에서 사용자 인터페이스가 적절히 표시되고 동작이 일관성 있는 Ajax 응용 프로그램을 만들려면 개발자가 고려할 사항이 아주 많다. 응용 프로그램을 최적화하여 성능과 사용 편의성을 높이려면 이 기사에서 제공하는 팁을 명심한다.

Ajax 응용 프로그램을 구현하는 개발자는 페이지 폭/높이와 프로그램이 화면에 표시되는 모양새를 고려해야 한다. 사용자 환경에 따라 800x600, 1024x768 등 해상도가 크게 달라지기 때문이다. 해상도가 높은 화면에 프로그램 크기를 맞추면 해상도가 낮은 화면을 사용하는 사용자는 스크롤하느라 불편함을 겪는다. 스크롤이 불편하다면 사용자는 사이트를 떠난다.

메모리와 디스크 공간

복잡한 계산을 수행하려는 데 메모리가 부족하다면 컴퓨터는 디스크 공간을 확보하여 계산을 진행한다. 계산 과정을 완료하기 전에 메모리나 디스크가 바닥나면 사용자는 메모리나 디스크 공간이 부족하다는 오류 메시지를 받는다.

Ajax 프로그램에서 이런 오류 유형이 발생하는 근본 원인은 프로그램이 메모리, 디스크 공간, 기타 시스템 자원을 제대로 운용하지 못했기 때문이다. 이 때 개발자가 취할 대응책은 두 가지다. 하나는 시스템 자원에 걸리는 부하를 경감하는 방법이고, 다른 하나는 프로그램을 고치는 방법이다. 시스템 자원에 걸리는 부하를 경감하려면 예를 들어, 필요하지 않는 파일을 삭제하거나 큰 Ajax 프로그램을 외부 USB 디스크 드라이버로 옮긴 후 실행한다. 프로그램을 고치려면 예를 들어, 여러 모듈로 나눈 후 각 모듈 단위로 예외를 처리하여 문제 원인을 찾는다.

USB 포트

컴퓨터에 USB 포트가 많을수록 동시에 사용이 가능한 USB 디바이스도 많아진다. 일반적으로 적어도 두 개는 있어야 적당하다. 그래야 (Y 케이블이 있는) 휴대용 120MB USB 외부 디스크 드라이브처럼 강력한 USB 디바이스를 연결한다. 이러한 디바이스는 내부 디스크 공간이 부족할 때 Ajax 프로그램을 저장하고 실행하기에 유용하다. 컴퓨터가 제공하는 USB 포트로 부족하다면 USB 허브를 사용하는 방법도 있다. 허브는 Y 케이블이 따라오므로 두 커넥트를 USB 포트에 연결하면 된다.

참고: 어댑터가 없는 허브에 커다란 외부 하드 드라이브를 장착하면 드라이브도 웹 서비스 포털도 동작하지 않는다. 외부 드라이브가 필요한 전력을 허브가 제공하지 못하기 때문이다. 제대로 돌아가려면 적절한 전력을 제공하는 허브와 어댑터가 필요하다.

글꼴

글꼴 문제 두 가지를 살펴보자. 하나는 가용성이고 다른 하나는 호환성이다.

글꼴 가용성

윈도에서 돌아가는 IE가 표시하는 텍스트는 매킨토시에서 돌아가는 IE나 내비게이터(Navigator)가 표시하는 텍스트와 달라 보인다. 구체적으로 말하자면, 글꼴 크기를 똑같이 지정해도 매킨토시 글자가 PC 글자보다 작아 보인다. 그러므로 개발자는 일반적인 방법으로 텍스트 크기를 조정할 때 PC와 매킨토시가 실제로 사용하는 크기 중 최대 값을 알아야 한다. 특정 PC에서 사용자가 선호하는 글꼴이 다른 PC 모델이나 매킨토시에 없는 경우도 있다. 시스템에 원하는 글꼴이 없다면 시스템 기본 글꼴을 사용한다. (PC 윈도에서 글꼴 가용성을 확인하려면 시작->제어판->글꼴 아이콘을 선택한다.)

글꼴 호환성

많은 개발자가 모든 브라우저와 플랫폼에서 텍스트 크기를 동일하게 만드느라 골치를 앓는다. 그런데 브라우저마다 사용자가 글꼴 크기를 조정하는 방법은 다양하다. 예를 들어 윈도에서 IE는 가장 크게(Largest), 크게(Larger), 보통(Medium), 작게(Smaller), 가장 작게(Smallest)라는 다섯 가지 크기를 제공한다. 모질라 파이어폭스는 글꼴 크기를 확대하거나, 축소하거나, 재설정하는 메뉴를 제공한다. 반면, 오페라 사용자는 목록에서 백분율을 선택하여 글꼴 크기를 조정한다. 그러므로 응용 프로그램이 사용하는 글꼴 크기가 변했을 때 서로 같은 결과를 보여주는 브라우저는 없다.

심지어 글꼴 크기를 똑같이 보통(medium)이라 설정해도 브라우저마다 다른 결과를 내놓는다. 다양한 브라우저에서 텍스트 크기를 일관적으로 유지하는 방법 중 하나가 CSS(Cascading Style Sheet)다. CSS에서 글꼴 크기를 정의할 때 백분율이나 em을 사용하면 된다. 정말로 다른 방법이 없다면 마지막 수단으로 픽셀 크기를 사용한다. 단, 픽셀 크기를 사용하면 화면 해상도에 따라 텍스트 크기가 달라진다.

HTML 표준

Ajax 응용 프로그램은 자바스크립트와 XML 외에도 HTML, DHTML, DOM(Document Object Model)을 사용한다. HTML로는 웹 폼을 만들고, DHTML로는 HTML 마크업으로 폼을 동적 갱신한다. DOM은 서버가 반환하는 XML이나 HTML의 구조를 분석하고 참조한다. 그런데 모두가 똑같은 표준과 똑같은 폼 요소를 사용하지 않으므로 문제가 생긴다.

최신 HTML 버전

최신 HTML 표준은 최신 브라우저에서 더욱 잘 표시되므로 대다수 사용자가 자신의 브라우저를 최신 버전으로 판올림한다. 하지만 일부 브라우저는 최신 버전이라도 새 표준을 완벽하게 지원하지 못한다. 실생활에서 표준이 브라우저 개발 속력을 앞서가기 때문이다. 최신 HTML 표준을 100% 지원하는 브라우저는 아직 없지만, 브라우저마다 표준을 지원하는 정도에는 차이가 있다.

최신 HTML 태그를 지원하지 못하는 브라우저도 있으므로, 개발자가 최신 HTML 태그를 사용한다면 브라우저가 페이지를 인식하지 못하는 사태도 발생한다. 브라우저가 페이지 일부를 인식하지 못하면 페이지는 제대로 표시되지 않는다. 예를 들어, IE에서 레이어를 겹쳐 사용했다면 다른 IE 버전이나 다른 브라우저 유형이 페이지를 올바로 인식하지 못할지도 모른다. 오페라나 파이어폭스는 겹쳐진 레이어를 일부라도 표시할지 모르겠지만 IE는 아니다. 그러므로 프로그램을 출시하기 전에 마이크로소프트 익스프레션 웹(Microsoft Expression® Web) 같은 웹 개발 소프트웨어를 이용하여 여러 브라우저 환경에서 페이지를 미리 확인하는 편이 바람직하다.

폼 요소

브라우저와 HTML 버전에 따라 폼 요소는 크기와 간격과 모양새가 많이 달라진다. 구체적으로는 풀다운 메뉴, 텍스트 입력 필드, 기타 폼 요소가 차지하는 공간이 달라진다. 어떤 브라우저에서는 멋지게 보이던 폼 요소가 다른 브라우저에서 볼품없어 보이는 경우도 많다.

성능

프로그램을 출시하기 전에 몇 가지 성능 요소도 고려해야 한다. 예를 들면 브라우저 속력, XML 파일 크기, 추가 기능이 미치는 영향 등이다.

브라우저 속력

윈도 응용 프로그램이라면 오페라가 가장 빠르다고 생각한다. 속력 면에서는 파이어폭스와 IE가 비슷하지만, 표준이나 보안이나 기능 면에서는 파이어폭스가 낫다. 그래도 오페라만큼 빠르지는 않다. 리눅스 응용 프로그램이라면 KDE 환경에서 기본 페이지를 시작하고 표시하는 속력 면에서 컨쿼러가 가장 빠르다. 그러나 페이지에 스크립트나 이미지가 있다면 오페라가 더 빠르다. 파이어폭스도 전반적으로 우수하지만 스크립트 실행 속력, 캐시 처리 속력, 이미지가 있는 페이지 처리 속력 등이 오페라에 미치지 못한다. 맥 OS X에서는 오페라와 사파리(Safari) 둘 다 아주 빠르다. 사파리 2는 CSS를 시작하고 표시하는 속력이 빠른 반면, 오페라는 테이블과 스크립트와 이력을 표시하는 속력이 빠르다.

브라우저 속력은 오페라가 가장 빠르지만, 글꼴 크기를 조정하는 기능은 IE의 크기 메뉴나 파이어폭스의 Ctrl 옵션이 더 편리하다. 마이크로소프트 익스프레션 웹 설계 도구로 웹 페이지를 미리 살펴보려는 경우 오페라는 옵션으로 제공되지 않는다.

XML 파일 크기

크기가 아주 큰 텍스트 XML 파일은 꼭 필요한 경우에만 신중하게 사용한다. XML 파일이 크면 브라우저 응답 시간이 느려지고 심지어 네트워크도 느려진다. 텍스트 XML 파일 대신 이진 XML 파일을 사용하는 방법도 고려한다. (웹 서비스 취약성을 피하면서 Ajax 응용 프로그램 속력을 높이는 방법은 참고자료에서 제공하는 기사를 읽어본다.)

브라우저 추가 기능

팝업 차단기, 탭 관리자, UI 테마 등 브라우저에 추가하는 기능도 때때로 예상치 못한 방식으로 Ajax 프로그램에 영향을 미친다. 예를 들어, 팝업 차단기를 설치하면 새 브라우저 창이 열리지 않는다. 하지만 팝업 차단기가 브라우저 화면 일부를 사용하면서 프로그램을 가리기도 한다. 브라우저 화면 일부가 가려지는 바람에 Ajax 프로그램이 페이지를 의도대로 표시하지 못하는 경우도 생긴다.

developerWorks Ajax 참고자료 센터

Ajax 참고자료 센터에서는 Ajax 프로그래밍 모델에 관한 기사, 튜토리얼, 토론 포럼, 블로그, 위키, 행사, 뉴스 등 다양한 정보와 자료를 제공한다. 웬만한 자료는 다 있다.

열 가지 팁과 함정

다음은 최적화된 웹 페이지를 작성할 때 유용한 팁과 피할 함정이다. Ajax 프로그램을 사용하는 사용자에게도 마찬가지로 유용한 정보다.

개발자: 가능하면 HTML 확장 기능을 사용하지 말라. 최신 언어 기능은 주의 깊게 사용하라. 주요 브라우저가 최신 기능을 지원하지 않을지도 모른다.

개발자: 브라우저 최신 버전이 지원하는 HTML 기능으로 페이지를 제작하겠다고 서둘러 덤비지 말라.

개발자: 주요 브라우저마다 최신판 두 개에서 올바로 동작하도록 페이지를 설계하라.

개발자: 메모리, 디스크, 기타 시스템 자원에 걸리는 부하를 줄이라. 최대한 적게 사용하라.

개발자와 사용자: (필요하다면) Ajax 프로그램을 다시 시작하거나 (다른 방법이 없다면) 컴퓨터를 다시 시작해 Ajax 프로그램을 갱신하라.

개발자와 사용자: 사용하지 않는 파일이나 필요없는 파일은 주기적으로 삭제하라. 프로그램이 사용할 디스크 공간을 늘리라.

개발자와 사용자: 메모리를 늘리거나 120MB짜리 외장 하드 드라이브를 사용하라.

개발자: Ajax 포털용으로 웹 페이지를 설계할 때는 레이어 옵션을 단순화하라.

개발자: 문제를 디버깅하기 쉽도록 Ajax 프로그램을 모듈로 분리하라. 프로그램에 예외 처리 기능을 추가하라.

개발자: CSS를 사용하여 텍스트 크기 문제를 없애라. CSS에서는 글꼴 크기를 백분율이나 em으로 지정하라. 다른 방법이 없다면 마지막 수단으로 픽셀 크기를 사용하라.

결론

개발자, 테스터, 시스템 관리자, 잠재적인 사용자로 이루어진 팀에 의견을 구해도 좋겠다. 그러면 개발자가 Ajax 프로그램을 개발하고 웹 서비스 포털로 변환할 때 브라우저 차이로 발생하는 문제점을 최적화하기가 쉬워진다. Ajax 프로그램에서 브라우저가 미치는 영향을 최소로 줄이려면 프로그램을 개발하고 테스트하고 배포하는 과정에서 상당한 계획이 필요하다. 꼼꼼히 계획해야 프로그램 성능이 좋아지고 일관성이 높아진다.

출처: IBM닷컴

[QT/Win32] Qt Win32 opensource 4.3.2 + Eclipse IDE for C/C++ Developers 개발환경 설정

출처 : http://tong.nate.com/kangdydtjs/44533197

To summarize, the base version info returned by GetVersionEx for various Windows versions is:

invalid-file

invalid-file

invalid-file

VC++ MFC로 구현된 예제 프로그램

> adrtest6.zip

MSDN의 "Serial Communications in Win32"의 메뉴얼을 참고하면 된다!

#include <stdafx.h> // <- 이것이 header file

C언어로 리눅스 환경에서 동작하는 예제 프로그램

> sjinn-1.tar.gz

BOOL CSerialCom::OpenPort(CString portname)
{
portname= "//./" + portname;

hComm = CreateFile(portname,
                      GENERIC_READ | GENERIC_WRITE,
                      0,
                      0,
                      OPEN_EXISTING,
                      0,
                      0);
if(hComm==INVALID_HANDLE_VALUE){
	return false;}
	else
	return true;

}

BOOL CSerialCom::ConfigurePort(DWORD BaudRate, BYTE ByteSize, 
                               DWORD fParity, BYTE Parity, BYTE StopBits)
{
	if((m_bPortReady = GetCommState(hComm, &m_dcb))==0)
	{
		MessageBox("GetCommState Error","Error",MB_OK+MB_ICONERROR);
		CloseHandle(hComm);
	    return false;
	}
    
    m_dcb.BaudRate =BaudRate;
    m_dcb.ByteSize = ByteSize;
    m_dcb.Parity =Parity ;
    m_dcb.StopBits =StopBits;
    m_dcb.fBinary=TRUE;
    m_dcb.fDsrSensitivity=false;
    m_dcb.fParity=fParity;
    m_dcb.fOutX=false;
    m_dcb.fInX=false;
    m_dcb.fNull=false;
    m_dcb.fAbortOnError=TRUE;
    m_dcb.fOutxCtsFlow=FALSE;
    m_dcb.fOutxDsrFlow=false;
    m_dcb.fDtrControl=DTR_CONTROL_DISABLE;
    m_dcb.fDsrSensitivity=false;
    m_dcb.fRtsControl=RTS_CONTROL_DISABLE;
    m_dcb.fOutxCtsFlow=false;
    m_dcb.fOutxCtsFlow=false;

    m_bPortReady = SetCommState(hComm, &m_dcb);
    if(m_bPortReady ==0)
    {
		MessageBox("SetCommState Error","Error",MB_OK+MB_ICONERROR);
		CloseHandle(hComm);
		return false;
	}
    return true;
}

ConfigurePort(CBR_9600, 8, true, EVENPARITY , ONESTOPBIT )

BOOL CSerialCom::SetCommunicationTimeouts(DWORD ReadIntervalTimeout, 
                                          DWORD ReadTotalTimeoutMultiplier, 
                                          DWORD ReadTotalTimeoutConstant, 
                                          DWORD WriteTotalTimeoutMultiplier, 
                                          DWORD WriteTotalTimeoutConstant)
{
    if((m_bPortReady = GetCommTimeouts (hComm, &m_CommTimeouts))==0)
        return false;
    m_CommTimeouts.ReadIntervalTimeout =ReadIntervalTimeout;
    m_CommTimeouts.ReadTotalTimeoutConstant =ReadTotalTimeoutConstant;
    m_CommTimeouts.ReadTotalTimeoutMultiplier =ReadTotalTimeoutMultiplier;
    m_CommTimeouts.WriteTotalTimeoutConstant = WriteTotalTimeoutConstant;
    m_CommTimeouts.WriteTotalTimeoutMultiplier =WriteTotalTimeoutMultiplier;
	m_bPortReady = SetCommTimeouts (hComm, &m_CommTimeouts);
	
	if(m_bPortReady ==0)
	{
        MessageBox("StCommTimeouts function failed",
                   "Com Port Error",MB_OK+MB_ICONERROR);
		CloseHandle(hComm);
		return false;
	}
	return true;
}

BOOL CSerialCom::WriteByte(BYTE bybyte)
{
    iBytesWritten=0;
    if(WriteFile(hComm,&bybyte,1,&iBytesWritten,NULL)==0)
        return false;
    else 
        return true;
}

BOOL CSerialCom::ReadByte(BYTE &resp)
{
    BYTE rx;
    resp=0;

    DWORD dwBytesTransferred=0;

    if (ReadFile (hComm, &rx, 1, &dwBytesTransferred, 0))
    {
        if (dwBytesTransferred == 1)
        {
            resp=rx;
	        return true;
	     }
	}
	return false;
}

void CSerialCom::ClosePort()
{
CloseHandle(hComm);
return;
}

    // Open Communication Port. Please check functions return value to ensure whether
    // Port opened successfully.
    port.OpenPort( ); 
    
    // Configure Port for Communication. Please check functions return value to
    // ensure whether Port is configured  successfully.
    port.ConfigurePort( );  

    // Set communication time outs. Please check functions return 
    // value to ensure whether communication time outs configured  
    // successfully.
    port.SetCommunicationTimeouts( ); 
					 
    // call this function in a loop till all bytes are written. Please check 
    // functions return value to ensure whether Write operation completed  
    // successfully.
    port.WriteByte(); 
					
    // call this function in a loop till all bytes are received. Please check 
    // functions return value to ensure whether Read operation completed  
    // successfully or a time out occurred.
    port.ReadByte( ); 

    // Call this function to close the handle to the port.
    // Process the received Data
    port.ClosePort(); 

출처 : http://blog.naver.com/parkyoungju

■ adduser : 사용자를 새로 등록한다.

이것은 슈퍼 유저만이 사용할 수 있다. 명령을 입력하면 로그온 이름 등을 차례로 물어오며, 그에 따라서 알맞게 입력해 나가면 된다.

     Enter login name for new account (^C to quit): blade
     Editing information for new user [blade]
     Full name: Park Chan Wook ,,사용자 전체 이름을 입력
     GD [100]: ,,정해주는 값을 그냥 사용한다.

그외에도 홈 디렉토리에 사용하는 셸 등을 계속 물어오는데, 대괄호 속에 내정된 것을 그냥 사용하고자 한다면 엔터키만 누르면 된다. 패스워드 등을 입력하고 나면 지금까지 입력된 정보를 보여주고, 몇 가지 생성 작업을 화면으로 보여준 후 작업을 종료한다.

■ at : 프로그램을 지금이 아닌 나중에 실행하도록 예약한다.
     at -q [-m][-f 파일명] 큐(queue) 시간
     at -r 작업번호
     at -l
옵션
     -q 큐 : 대소문자 알파벳으로 큐를 지정한다. 순서적으로 빠른 알파벳이 지정된 큐 일수록 CPU 시간 점유 우선권이 낮다.
     -r 작업번호 : 큐에서 작업 번호가 지시하는 작업을 지운다. 슈퍼유저가 아니라면 자신의 작업만을 지울 수 있다.
     -l : 현재 계획된 작업들의 목록을 보여준다. 슈퍼 유저라면 모든 작업들의 계획목록을 보여준다.
     -m : 작업이 완결되면 사용자에게 메일을 보낸다.
     -f 파일명 : 표준 입력이 아닌 지시된 파일에서 작업을 읽어온다.

설명
명령은 기본적으로 표준 입력 장치를 통해서 받으며, ^D로 입력을 종료한다.

리다이렉션을 사용하여 다른 파일의 내용을 사용할 수 있다.

/etc/at.allow 파일이 있다면 이 파일에 명단이 있는 사용자만이 at 명령을 사용할 수 있다. /etc/at.allow 파일이 없다면 /etc/at.deny 파일을 찾는다. 이 파일에 목록이 있는 사용자는 at 명령을 사용할 수 없다. 두 파일 모두 찾지 못한다면 오로지 슈퍼 유저만이 at 명령을 사용할 수 있다. 그리고 /etc/at.deny 파일이 비어 있다면 모든 사용자가 at 명령을 사용할 수 있다.

시간을 지정할 때 상당히 다양한 방법을 사용할 수 있다. hhmm 혹은 hh:mm 형태도 가능하며, noon, midnight이나 오후 4시를 의미하는 teatime이라고도 할 수 있다. 오전 오후를 쉽게 구분하려면 am pm 문자를 추가해도 된다. 이미 지나간 시간이라면 다음 날 그 시간에 수행될 것이다. 정확한 날짜를 지정하려면 mmddyy 혹은 mm/dd/yy 아니면 dd.mm.yy 형태 중 선택하라.

현재부터 얼마의 시간이 경과한 후에 수행할지를 지정하려면 + 기호를 사용하라. 이 + 기호뒤에 숫자를 명시하고, 다시 뒤에 그 숫자의 단위가 무엇인지 지정하면 된다.

사용예
     at 8am work : work에 수록된 작업 사항들을 오전 8시에 수행하도록 한다.
     at noon work : 정오에 work에 수록된 작업을 수행한다.
     at -f work 14:40 tomorrow : 내일 오후2시 40분에 work 파일에 수록된 작업을 수행한다.

■ banner : 인수로 주어진 문자열을 큰 글씨로 만들어서 출력한다.
     banner [ -w [숫자] ] 문자열

옵션
     -w : 옵션 지정만 하면 80 칼럼으로 폭을 바꾼다. 지정하지 않으면 132 칼럼으로 내정되어 있다. -w 옵션 뒤에 숫자를 지정하면 원하는 폭으로 조정할 수 있다.

설명
출력은 표준 출력으로 내정되어 있다. 글자는 열 배 정도 확대된다. 글자는 에스터리스크(*)를 조합하여 만든다.

사용예
     banner "hello world"
     banner linux | lqr ,,디폴트 프린터에 확대한 글자를 출력한다.

■ bash : 이것은 리눅스의 Boume 셸이다. sh를 사용하면 sh가 bash를 호출하여 실행한다. bash를 직접 사용하지 말고 sh를 사용하도록 하라.

     sh [ 옵션 ][ 파일 ]

설명
    sh의 설명을 참조하라.

■ biff : 전자우편의 수신을 즉시 알려주는 동작을 가능하게 할 것인지 그렇지 않은 지의 여부를 보여주거나 결정한다.

     biff [ y 혹은 n]

설명
유닉스 셸은 사용중이라도 주기적으로 전자우편의 수신 여부를 점검한다. 만일 사용자가 전자우편이 도착하는 즉시 알고자 한다면 biff를 사용하여 그것을 지시할 수 있다. 또는 언제라도 그 기능을 해제할 수도 있다. biff는 인수없이 사용되면 현재 어떤 상태로 되어 있는지 보여준다. 기능 설정과 해제 여부는 y 혹은 n 인수를 주어서 결정한다.

사용예
     $ biff
     is n ,,전자우편 수신 즉시 통고 기능은 설정되어 있지 않음
     $ biff y ,,기능설정
     $ biff
     is y

■ cal : 서기 원년부터 9999년까지의 달력을 볼 수 있다.

     cal [-jy] [ [ 달 ] 연도 ]

옵션
     -j : 1월 1일부터 날짜수를 계산하는 julian 날짜를 표시한다.
     -y : 올해의 달력을 표시한다.

설명
인수를 하나만 준다면 그 숫자는 연도를 의미하는 것으로 간주된다. 두 개의 숫자를 준다면 앞의 것은 월, 그 다음은 연도를 의미하는 것이 된다. 우리의 습관과는 다른 방법을 사용한다. 아무 인수도 주어지지 않으면 이번달의 달력을 표시한다. 연도를 표기할 때는 서기를 완전히 표기해야 한다. 예를들어 97은 1997년이 아니라 서기 97년의 달력을 출력할 것이다.

사용예
     $ cal 1997
     $ cal 4 1997

■ cat : cat은 catenate(사슬로 잇다. 연결하다)에서 이름이 유래한다. 이것은 파일의 내용을 화면에 출력하는 데 사용되기도 하며 파일을 다른 곳에 순차적인 스트림으로 보내기 위해 사용된다.

     cat [ -benstuvETA ] [ 파일명(들) ]

옵션
     -b : 공백 외의 글자가 있는 모든 행의 개수를 센다.
     -e : 제어 문자를 ^ 형태로 출력하면서, 각 행의 끝에 $를 추가한다. -vE와 같다.
     -n : 각 행을 출력하면서 행 번호를 함께 첨부한다.
     -s : 중복되고 겹치는 빈 행은 하나의 빈 행으로 처리한다.
     -r : 행바꿈 문자를 제외한 제어 문자를 ^ 형태로 출력한다. -vT와 같다.
     -u : 유닉스 호환성을 위해 추가된 옵션으로서 무시된다.
     -v : tab과 행바꿈 문자를 제외한 제어 문자를 ^ 형태로 출력한다.
     -E : 각 행마다 끝에 $ 문자를 출력한다.
     -T : 시로서 탭(tab) 문자를 출력한다.
     -A : -vET 옵션을 사용한 것과 같은 효과를 가진다.

설명
유닉스 시스템은 기본적으로 텍스트 자료들을 처리하는 것을 매우 중요시 여겼다. 많은 초기 설정 작업들이 텍스트 문서로 이루어지고, 텍스트 문서를 처리하는 수많은 명령들이 있다. cat 명령은 그러한 것들 중 기본적인 것이다. cat 명령은 읽어들이는 파일 이름을 지정하지 않으면, 기본 내정값으로 표준 입력 장치를 선정한다.

     $ cat

이렇게 하면 키보드로부터 입력을 받고, ^d로 입력이 끝나면 다시 표준 출력 장치인 화면으로 출력한다.

사용예
     $ cat document.1 ,,document.1 파일을 화면으로 출력한다.
     $ cat content report.first myreport

content와 report.first 두 개의 문서가 연결된 myreport라는 파일을 생성하게 된다.

■ cd : 현재 작업하는 디렉토리를 변경한다.

     cd [ 디렉토리 ]

설명
디렉토리 이름과 cd 명령 사이에 반드시 공백이 있어야 한다. 디렉토리 이름을 주지 않고 수행하면 사용자의 홈 디렉토리로 이동한다. 자신이 이동하고자 하는 디렉토리는 자신에게 실행 권한(execution permission)이 있어야 한다.

사용예
     $ cd /home
     $ pwd
     /home

■ chgrp : 파일의 그룹 소유권을 바꾼다.

     chgrp [ -cfvR ] 그룹 파일들

옵션
     -c : 실제로 소유자가 바뀐 파일에 대해서 자세히 기술한다.
     -f : 파일의 그룹 소유권을 바꿀 수 없더라도 에러 메시지를 출력하지 않는다.
     -v : 소유권의 바뀜에 대해서 자세히 기술한다.
     -R : 디렉토리와 그 내용 파일들의 소유권을 재귀적으로 모두 바꾼다.

설명
파일의 소유자나 슈퍼 유저만이 파일의 그룹 소유권을 바꿀 수 있다. chgrp 명령 뒤에 원하는 옵션을 사용한 후 목적하는 그룹의 이름을 명시하고 대상 파일의 이름을 명시한다.

사용예
     $ chgrp DoublePlus /usr/project/*

이것은 /usr/project의 모든 파일들의 소유권을 DoublePlus 그룹으로 바꾼다.

■ chmod : 파일의 모드를 바꾼다. 파일의 모드는 권한(permission) 을 제어한다.

     chmod [ -cfvR ] 모드 파일명(들)
     chmod [ -cfvR ] 레벨 동작 권한 파일이름(들)

옵션
     -c : 실제로 파일의 권한이 바뀐 파일만 자세히 기술한다.
     -f : 파일의 권한이 바뀔 수 없어도 에러 메시지를 출력하지 않는다.
     -v : 변경된 권한에 대해서 자세히 기술한다.
     -R : 디렉토리와 파일들의 권한을 재귀적으로 모두 바꾼다.

설명
위에서 보인 문법에서 첫 번째 보인 형식에 사용되는 모드는 파일의 권한을 8진수로 표현한 값이 된다. 파일의 권한은 세 가지가 있기 때문에 각 특성을 하나의 비트로 표현하면 0부터 7까지의 수로 표현할 수 있다. 이것은 8진법 표현이 매우 적당하다.

두 번째 형식은 어떤 사용자 레벨을 바꿀 것인가 어떻게 바꿀 것인가를 개별적으로 정하는 방법이다. 숫자를 사용하지 않고 ls 등을 사용할 때 실제로 볼 수 있는 기호 문자를 사용한다는 것과 특정 권한을 줄 것인가 뺄 것인가 지정할 수 있다는 장점이 있다. 특정한 경우 두 번째 형식이 편리하겠지만 고유한 값의 권한을 지정하는데에는 첫 번째 형식이 훨씬 편리할 것이다. 8진법을 다루는 것은 조금만 알면 너무나 쉽기 때문이다.

사용예
     $ chmod 666 broadboard ,,파일을 모두가 읽고 쓸 수 있도록 한다.
     $ chmod 746 broad ,,파일 권한을 -rwxr--rw-로 변경한다.
     $ chmod o+x,g-w broadboard

파일 소유자는 실행권한을 추가하고, 그룹은 쓰기 권한을 금지한다.

     $ chmod u=r broad ,, 다른 사용자의 권한을 읽기로 제한한다.   사용자의 다른 권한은 사라져 버린다.

■ chown : 파일의 소유권을 다른 사람에게로 변경시킨다.

     chown [ -cfvR ] 사용자 파일명(들)

옵션
     -c : 실제로 파일의 소유권이 바뀐 파일만 자세히 기술한다.
     -f : 파일의 소유권이 바뀔 수 없어도 에러 메시지를 출력하지 않는다.
     -v : 변경된 소유권에 대해서 자세히 기술한다.
     -R : 디렉토리와 파일들의 소유권을 재귀적으로 모두 바꾼다.

설명
파일의 소유권을 다른 사람에게로 바꾸는 것은 슈퍼 유저만이 할 수 있다.

사용예
     $ chown blade /user/sisap/*

/usr/sisap 디렉토리의 모든 파일을 blade의 것으로 바꾼다.

■ clear : clear 명령은 도스의 cls와 마찬가지로 화면을 지우는 동작을 한다.

     cmp [-ls][파일명][파일명2][오프셋1][오프셋2]

옵션
     -l : 일치하지 않는 모든 바이트 값과 그 오프셋을 알 수 있다.
     -s : 비교만을 수행할 뿐 아무런 메시지도 출력하지 않는다.

설명

옵션없이 두 파일 이름만을 지정하면 cmp는 두 개의 파일 처음부터 순서대로 비교를 시작한다. 만일 끝까지 차이점을 발견하지 못하면 cmp는 조용히 끝난다.

만일 중간에 다른 점을 발견한다면 더 이상의 작업은 중단하고 차이를 발견한 지점을 알려주고는 종료한다. 또한 계속해서 일치해 나가다가 두 파일 중 어느 하나가 끝나는 경우가 있을 수 있다. 다시 말해, 한 파일이 다른 파일의 앞부분에 해당하는 경우이다. 이때는 어느쪽 파일의 end of file 표시를 만나게 되었는지를 알려주고 종료한다.

     $ cmp document1 document2
     document1 document2 differ: char 128, line 13 ,,차이 발견

오프셋을 지정하면 파일의 어느 부분부터 비교할 것인지를 정할 수 있다. -s 옵션이 왜 필요한 지를 이해하지 못할 테지만, cmp 명령이 보이지 않게 리턴값을 들려준다는 점을 알면 이해할 수 있을 것이다. cmp는 비교 후 두 파일이 일치한다고 판단하면 0을 리턴하며, 그렇지 않으면 1을 리턴한다. 셸 스크립트 상에서 비교 결과만을 원하고 화면에 메시지가 출력되는 것을 원치 않을 때에는 이러한 옵션을 사용할 수 있을 것이다. C 언어를 아는 사람이라면 금방 이해할 수 있었으리라 생각된다.

사용예
     $ cmp mail.1 mail.2 13 14

■ compress : 파일을 압축하거나 압축을 푼다.

     compress [ -cCdfv ] 파일명

옵션
     -c : 옵션을 사용하면 압축 결과가 표준 출력으로 나가며 파일은 변함없다.
     -C : 파일을 블록으로 분화하는 것을 금지한다. 이것은 compress의 구식 버전이 파일을 읽을 수 있도록 하기 위함이다.
     -f : 수행 결과 파일과 같은 이름의 파일이 있다면 물어보지 않고 덮어쓴다. 또한 파일의 크기가 줄어들지 않더라도 파일 이름에 .Z를 추가한다.
     -v : 파일이 압축되면 압축 효율을 퍼센트로 보여준다.

설명
압축된 파일은 이름에 접미사 .Z가 추가된다. 압축 알고리즘에 의해 크기가 줄어드는 경우만 압축을 수행한다. -d 옵션은 역으로 압축을 풀지만 uncompress를 사용하면 옵션을 주지 않고 압축을 풀 수 있다. 압축을 푸는 경우 파일 이름 뒤에 접미사 .Z를 생략할 수도 있다.

사용예
     $ compress -v roman
     $ compress -d noman.Z 혹은 $ compress -d roman

■ cp :: 파일을 현재의 위치나 다른 디렉토리로 복사(copy)한다.

     cp [ -abdfilPprsuvxR ] 파일명1 파일명2
     cp [ -abdfilPprsuvxR ] 파일명(들) 디렉토리

옵션
     -a : 가능한한 원 파일의 구조와 속성을 그대로 복사한다.
     -b : 복사할 때 덮어쓰게 되는 파일은 백업을 만든다.
     -d : 심볼릭 링크는 심볼릭 링크로 복사한다. 그리고 원본 파일과의 하드 링크 관계를 유지한다.
     -f : 복사 위치에 존재하는 파일을 제거하고 복사한다.
     -i : 복사시 같은 이름의 파일이 존재한다면 덮어쓸 것인가 확인한다.
     -I : 하드 링크를 만든다.
     -P : 원본 파일의 소유자, 그룹, 권한, 시간 기록을 그대로 복사한다.
     -r : 파일과 하위 디렉토리에 포함된 파일 모두를 재귀적으로 복사한다.
     -s : 디렉토리가 아닌 파일의 심볼릭 링크를 만든다. 소스 파일의 이름은 전체 경로 이름으로 한다. 목적지 파일 이름은 전체 경로를 주지 않아도 현재 디렉토리로 간주되므로 상관없다.
     -u : 파일의 정보를 갱신한다.
     -x : 다른 파일 시스템인 하위 디렉토리는 무시한다.
     -R : 디렉토리를 재귀적(recursive)으로 복사한다.

설명
만일 파일명2가 이미 존재하는 파일의 이름이라면 기존에 있던 파일은 사라지고 새로운 복사본 파일로 바뀐다. 이것이 원하지 않는 결과라면 -i 옵션을 주어서 확인 작업을 거칠 수 있다. -i 옵션은 파일명2가 이미 존재하는 이름이라면 그대로 복사할 것인지 아닌지를 선택할 수 있게 물어온다.

사용예

     $ cp -i blade.Z temp.Z
     $ cp -r * /somewhere

당연히 -r 옵션은 파일명2가 디렉토리 이름일 때만 사용이 가능하다.

■ crontab : 실행될 프로그램들과 스케줄의 cron 데몬을 구성한다.  

     crontab -l [ -u 사용자 ]
     crontab -e [ -u 사용자 ]
     crontab -d [ -u 사용자 ]

옵션
     -l : crontab 파일 목록을 보여준다.
     -e : 에디터를 사용하여 crontab 파일을 수정한다.
     -d : 사용자의 crontab 파일을 지운다.
     -u 사용자 : 특정 사용자의 crontab 파일을 다루도록 지정한다. 이 명령을 사용하려면 슈퍼 유저로 로그인해야만 한다.

설명
crontab 파일 내의 빈 핵과 # 문자로 시작되는 행은 무시된다.
파일의 각 행은 M H D m d cmd 형태로 되어 있다. 필드의 에스테리스크(*)표시는 어떠한 값이든 일치하는 조건으로 가정한다는 의미이다.
     M 분을 의미한다.(0-59) H 시를 의미한다(0-23)
     D 날짜를 의미한다(1-31) m 달을 의미한다(1-12)
     d 요일을 의미한다(0-6) cmd 실행할 명령을 의미한다.

■ csh : 이것은 유닉스 C 셸이다. 하지만 리눅스에서는 tcsh에 링크되어 있는 파일에 불과하다. 자세한 내용은 tcsh를 참조하라.

■ cut : 파일에서 필드를 뽑아낸다. 필드는 필드 구분자나 문자 위치로 지정된다.

     cut -c문자위치 파일명(들)
     cut -f필드 -d필드 구분자 [ -s ] 파일명(들)

옵션
     -c문자위치 : 잘라낼 곳의 글자 위치를 지정한다. 콤마를 사용하거나 하이픈을 사용하여 범위를 정할 수도 있으며, 이런 표현들을 혼합하여 사용할 수도 있다.
     -f필드 : 잘라낼 필드를 정한다. 지정하는 방법은 -c 옵션과 같다.
     -d필드 구분자 : 필드를 구분하는 문자를 지정한다. 디폴트는 탭 문자다.
     -s : 필드 구분자를 포함할 수 없다면 그 행은 하지 않는다.

사용예
     $ cut -f1,5 -d: /etc/passwd
     $ cut -c1,3-7 /usr/tmp/board

■ date : 시스템은 현재의 날짜와 시간을 유지하고 있다. date 명령을 사용하면 그러한 시간을 확인할 수 있다. 또한 날짜와 시간 정보를 변경할 수 있다. 물론 시스템의 날짜와 시간은 슈퍼 유저만이 변경할 수 있다.

     date [yymmddhhmm [ss] ]
     date +형식

설명
date 는 위와 같이 주어진 인수가 없다면 현재 시스템의 시간과 날짜를 출력한다. 주어지는 인지가 있다면 그에 따라서 시스템의 시간과 날짜를 변경한다.
yy는 연도를 나타내는 두 숫자이며(99년까지), mm은 월을 나타내는 수이다. 그리고 dd는 날짜, hh는 24시간 단위로 표현되는 시간이며, mm은 분을 의미한다. 마지막 ss는 초를 의미하는 부분인데, 명시하지 않아도 상관없다.

+형식 구문을 사용한다면 날짜가 출력되는 형태를 지정할 수 있다. 여기에 사용되는 기호는 다음과 같은 것들이 있다.

     n 개행 t 수평탭
     H 시간(00-23) I 시간(01-12)
     k 시간(0-23) l 시간(1-12)
     M 분(00-59) p AM 혹은 PM
     r 시간(12단위, hh:mm:ss AM/PM)
     s 초(00-61) T 시간(24단위, hh:mm:ss)
     X 시간 표현(hh:mm:ss) Z 시간대(예를들어CMT)
     a 요일표현(Sun-Sat) A 요일명(Sunday-Saturday)
     b 달 표현(Jan-Dec) B 달이름(January-December)
     D mm/dd/yy 형태의 날짜 h %b 와 같은 것
     j 일년단위 날짜(001-366) m 달(01-12)
     y 서기의 뒷부분 숫자(00-99) Y 서기(0000-9999)

사용예
     $ date

The Oct 1 15:57:23 KST 1996

■ df : 디스크의 여유 공간을 검사하여 보고한다.

     df [ -aikpvtx ] 파일시스템

옵션
     -a : 0 블록을 가진 파일도 보고한다. 기본적으로는 무시한다.
     -i : 블록 사용 대신 incode 사용 정보를 보고한다.
     -k : 블록의 크기를 1K바이트로 계산한다.
     -p : POSIX 형태의 출력을 한다.
     -v : System V의 df와의 호환을 위한 옵션이다. 무시된다.
     -t 형태 : 특정 형태의 파일 시스템으로 검사를 제한한다.
     -x 형태 : 특정 형태의 파일 시스템 이외의 것으로 검사를 제한한다.

설명
이것은 바이트 크기를 사용하는 대신 블록 단위로 보고한다는 점을 유의해야 한다. 기본적으로 512바이트 크기로 한 블록을 다룬다.

■ diff : 두 개의 파일을 비교한다. 이것은 두 개의 파일이 과연 어떻게 다른가를 중요시한다. 그래서 어떻게 수정되어야만 두 파일이 같아질 수 있는지를 말해준다.

     diff [ -ibefw ] 파일명1 파일명2

옵션
     -i : 대소문자를 구분하지 않는다.
     -b : 하나 이상의 공백 문자는 모두 같은 것으로 취급해서 비교한다.
     -e : ed 에디터를 위한 스크립트를 생성한다.
     -f : 반대 순서로 스크립트를 생성한다. 하지만 이것은 ed 에디터에 사용될 수가 없다.
     -w : 탭(tab) 문자를 포함한 모든 공백 문자를 무시하고 비교 작업을 수행한다.

설명
diff가 보여주는 정보는 언뜻 보아서는 이해할 수 없다. 일단 명심해야 할 것은 표본이 되는 문서는 두 번째 파일이라는 점이다. 그래서 모든 정보는 '첫번째 파일이 어떻게 수정되어야 두 번째 파일과 같아지느냐'하는 것이다.

파일2에서 파일1로 첨가(append)되어야 할 것은 'a' 기호로 표현된다. 그리고 파일1에서 제거(delete)되어야 하는 내용은 'd'로, 두 파일의 내용이 바뀌어(change)하는 내용은 'c'기호로 표시한다. 이러한 수정 기호와 함께 행의 번호가 함께 표시되며, 해당 줄의 내용이 함께 출력된다.

     행숫자 a 파일2시작행번호 파일2끝행번호
     파일1시작행번호 파일1끝행번호 d 행숫자
     파일1시작행번호 파일1끝행번호 c 파일2시작행번호 파일2끝행번호

사용예
     $ diff -i doc1.txt doc2.txt

■ du : 지정된 특정 디렉토리나 파일들이 차지하는 공간을 보고한다.

     du [ -sabxL ][ 디렉토리,파일명(들) ]

옵션
     -s : 총 합계만을 따진다. 하위 디렉토리의 숫자 등은 나오지 않는다.
     -a : 크기가 계산된 각 파일의 크기를 보인다.
     -b : 바이트 크기로 출력한다.
     -x : 현재 디렉토리에 마운트된 파일 시스템만 검사된다.
     -L : 심볼릭 링크 자신의 공간 대신 연결된 파일의 크기를 다룬다.

설명
디렉토리나 파일을 지정하지 않으면 현재 디렉토리로 간주된다. 크기는 1K 바이트 크기의 블록으로 보고한다.

사용예
     $ du /root ,,/root 디렉토리의 공간 크기를 보고한다.

■ echo : echo는 인수로 지정된 문자열을 그대로 화면에 출력한다. 이것은 인수로 주어진 문자열이 오퍼레이팅 시스템으로 읽혀진 후에 다시 그대로 화면에 '메아리'치는 것으로 생각할 수 있다.

     echo [ -ne ] 문자열

옵션
     -n : 새로 개행하지 않고 출력하게 한다.
     -e : 문자열 중에서 백슬래쉬와 조합되는 특수 문자를 인식하게 한다. 그러한 특수 문자들은 다음과 같은 것들이 있다.

     \a 밸소리 \b 백스페이스
     \f 용지바꿈(form feed) \n 행바꿈
     \r 0 칼럼으로(carriage return) \f 탭(tab)
     \v 수직 탭 \\ 백슬래쉬 문자
     \nnn 8진법으로 표기되는 ASCII 문자 \c 출력 후 행바꿈 금지

설명
일반적으로 echo 명령은 프롬프트 상에서 사용되는 일은 없다. 하지만 스크립트 작성시 번번히 사용된다. 셸 스크립트 상에서 echo 명령은 BASIC의 PRINT 명령이나 C 언어의 printf() 함수와 같이 메시지를 출력하는 데에 자주 사용된다. 또한 전혀 필요없을 것 같은 echo의 -n 옵션도 스크립트 상에서는 유용하게 사용될 수 있다.

사용예
     $ echo "The RedHat !"
     The RedHat !
     $ echo -e 'Linux\RedHat !'
     Linux RedHat !

■ ed : 풀 스크린 에디터를 사용할 수 없는 열악한 환경의 터미널을 위한 라인 에디터(line editor)이다.

     ed [ - ][ -s ][ -p문자열 ] 파일명

옵션
     - : e, r, w, q, ! 명령에 의해 발생하는 메시지를 금지한다.
     -s : 검사 작업을 금지한다.
     -p문자열 : 프로프트를 원하는 문자열로 바꾼다.

설명
ed는 기능이 다양한 에디터이나 라인 에디터는 거의 사용할 일이 없을 것이다.

■ env : 현재의 환경에 영향을 주지 않고 원하는 환경을 만들어 명령을 실행한다. 또는 현재의 환경을 보고한다.

     env [ - ][-i ][ -u 이름 ][ 이름=값 ][명령]

옵션
     - : 뒤에 오는 이름=값 목록으로 환경을 제한한다.
     -i : 현재의 환경을 무시하고 빈 환경 상태로 시작한다.
     -u 이름 : 현재의 환경에 그 이름의 변수가 있다면 제거한다.

설명
'이름=값'의 형식으로 특정 환경 변수를 지정해서 명령을 실행한다. 이러한 값을 필요한 대로 여러 개 나열하면 되고, 현재의 환경은 변경하지 않으므로 명령의 수행이 끝나면 환경의 상태는 이전과 다름없게 된다.

사용예
     $ env HOME=/usr/victor tsh

홈 디렉토리 변수를 지정하여 셸을 실행한다.

     $ env ,,현재 설정되어 있는 환경 변수들을 보여준다.

■ file : 파일이 어떠한 형태의 파일인지 알아낸다.

     file [-czL ][ -fm 파일명 ] 파일명(들)

옵션
     -c : 매직 파일의 파싱된 형태를 보여준다.
     -z : 압축되어 있는 파일의 형태를 검사한다.
     -L : 뒤따르는 심볼릭 링크를 야기시킨다.
     -f 파일명 : 검사한 파일에 대해 리포트를 만들 파일의 이름을 지정한다.
     -m 파일명 : 파일의 형태를 결정하는 데에 사용되는 매직 파일을 정한다.

설명
파일이 텍스트 문서인지 실행할 수 있는 파일인지 아니면 데이터 파일인지 등을 인식한다. 에디터를 사용해서 보거나 수정될 수 있는 파일인가 알아 보는 데에 많이 사용된다.

사용예
     $ file -z /home/Book.Z

■ find : 원하는 특정 파일을 디렉토리를 탐색하여 찾는다. find는 매우 강력한 도구로 특정 디렉토리들을 순회하면서 지정된 조건에 만족하는 파일을 찾는다. 파일의 조건은 이름이나 크기, 날짜 등 다양하게 지정할 수 있다.

     find [ 디렉토리 ] 탐색 조건

탐색 조건
     -name 파일명 : 찾고자 하는 파일의 이름을 정한다. 와일드 카드도 가능하다.
     -perm 모드 : 파일 권한(permission)이 일치되는 것을 찾는다. 원하는 권한은 ls로 볼 수 있는 형태와 같이 지정한다.
     -type ? : 형태가 같은 파일을 찾는다. 물음표(?) 부분에 디렉토리는 d, 파이프는 p, 심볼릭 링크는 l, 소켓은 s, 블록 파일은 b, 일반 파일은 f 등의 기호를 사용한다.
     -links ? : 특정 개수의 링크를 가진 파일을 찾는다. 물음표 부분에 링크의 숫자를 표기한다.
     -size ? : 파일의 크기가 일치하는 것을 탐색한다. 파일 크기는 블록단위로 물음표 부분에 지정한다.
한 블록은 512바이트로 내정되어 있지만 블록 숫자 뒤에 단위로 k자를 붙이면 1키로바이트 크기의 블록 숫자로 간주된다
     -user 사용자 : 파일 사용자의 ID에 따라서 검색한다. 로그인 이름이나 번호 모두가 가능하다.
     -atime ? : 최근 며칠내에 엑세스한 파일을 검색한다. 날짜수는 ?에 명시한다.
     -exec 명령 : 원하는 검색 조건에 맞는 파일을 찾으면 명시된 명령을 실행한다. 명령의 끝은 \;을 사용하여 끝낸다.
find가 검색해낸 파일의 이름을 인수로 사용하고 싶다면 그 위치에 {}를 사용한다.
     -newer 파일 : 어떤 파일보다 최근에 갱신된 모든 파일을 검색한다.

사용예
     $ find /bin -name ro*
     $ find -user qwfwq -exec cat {} list\;


■ finger : 시스템 상의 사용자들에 대한 정보를 보여준다.

     finger [ -slpm ][ 사용자 ]

옵션
     -s : 사용자의 로그온 이름, 실제이름, 터미널 이름, 로그온 시간 등등을 보인다.
     -I : -s 옵션 정보에 몇 가지를 추가하여, 여러 줄에 걸쳐서 보여준다.
     -p : -l 옵션 정보에서 .plan과 .project 파일을 보이지 않는다.

설명
인수로 아무 것도 주어지지 않으면, finger는 현재 시스템에 로그인되어 있는 사용자들을 보여준다. 옵션이 주어지지 않으면, 기본적으로 -l 옵션을 사용한 것으로 간주된다.

사용예
     $ finger
     Login Name Tty Idle Login Time Office Office Phone
     blade kimtaihan 2 1 Oct 20 11:31
     root root 1 Oct 20 11:28


■ fsck : 파일 시스템이 완전한 상태를 유지하고 있는가를 검사하고, 잘못된 것은 바로 잡는다.

     fsck [ -arsVN ][ 파일시스템 ]

옵션
     -a : 검사도중 발견된 에러를 자동적으로 복구한다.
     -r : 검사도중 에러가 발견되면 복구할 것인가를 물어온다. 이것은 하위 호환성을 위한 것으로서 사실상은 사용되지 않는다.
     -s : 병렬적인 방법이 아니라 순차적인 방법으로 검색한다.
     -V : 검색중 각종 정보를 자세하게 보여준다.
     -N : 실제로 검사 작업을 하지는 않도록 한다.

설명
이것은 시스템이 처음 가동될 때 자동으로 호출된다. 이름은 file system check를 줄인 것으로, 파일 시스템을 스캔(scan)하여 일관성을 유지하고 있는가를 검사한다.

디스크의 블록이 bitmap에는 사용되지 않은 상태로 표시되었음에도 불구하고 inode로부터 참조된다든지 반대로 사용된 블록으로 표시되었는데도 inode로부터 참조되지 않는 일이 있는가를 검색한다. 그 외에도 inode 링크계수가 올바른지 두 개 이상의 inode가 같은 블록을 참조하는지 혹은 블록번호가 유효한 것인가 등의 여러 가지를 검사한다.

-a 옵션을 사용하였다면 검사도중 발견된 오류는 자동으로 복구된다. -r 옵션을 사용한다면 반드시 -s 옵션을 함께 사용해야 한다. fsck는 기본적으로 한꺼번에 몇 개의 검사를 병행하는 병렬 작업을 하기 때문에 하나의 에러를 발견하더라도 다른 검사는 계속 수행되고 있다. 검사 시간을 최대한 절약하기 위해서 병렬 작업을 하기 때문에 사용자의 수정과 다른 검사 작업의 호홉이 맞지 않을 수 있다. 그러므로 -s 옵션을 주어서 오직 하나의 검사 작업만 진행되도록 해야 한다. 그러나 -r 옵션은 하위 버전과의 호환성을 위한 것으로서 사용자는 -a 옵션만을 사용하는 것으로서 충분하다. 파일 시스템을 지정해 주지 않으면 /etc/fstab 파일에 나열된 파일 시스템을 검색한다.

■ grep/fgrep : 파일내에서 특정 패턴을 검색한다. 이름은 Global Regular Express Printer 의 머리글자이다.

     grep [ -vclhnief ] 표현 파일명(들)
     fgrep [ -vclhnief ] 문자열 파일명(들)

옵션
     -V : 일치되는 내용이 없는 라인을 표시한다.
     -C : 일치되는 내용이 있는 행의 개수를 센다.
     -I : 일치되는 내용이 있는 파일의 이름만을 표시한다.
     -h : 일치되는 내용을 찾은 파일의 이름을 표시하지 않는다.
     -n : 일치 내용이 있는 행은 행번호와 함께 표시된다.
     -i : 대소문자 구분을 하지 않는다.
     -e 표현 : 표현이 하이픈 문자로 시작될 때 사용한다.
     -f 파일 : 찾으려는 문장이나 표현이 있는 파일을 지시한다.

설명
원하는 탐색 단어 혹은 문장을 검색한다. 표현은 일반 표현식을 사용한다. fgrep은 문자열을 검색할 때 빠르게 사용할 수 있다.

사용예
     $ grep catch myletter
          myletter에 catch라는 단어가 있는지 검사한다.
     $ grep "[Cc]atch" myletter
          앞 글자가 대소문자인지 상관하지 않고 catch라는 단어를 찾는다. 이것은 다음의 fgrep 명령과 같은 동작을 한다.
     $ fgrep catch myletter

■ halt : halt는 아무런 경고없이 시스템을 즉시 종료시킨다.

     halt

설명
시스템이 halt되면 'System halted' 메시지가 나오고, 시스템은 정지한다. halt는 옵션을 가지지 않는다.명령이 내려지면 일련의 마무리 작업을 수행한 후에 정지한다. 시스템 종료 기록도 /var/adm/wtmp 로그 파일에 추가된다.

■ head : 파일의 처음 부분을 출력한다.

     head [ -행수 ] [ 파일이름(들) ]

옵션
     -행수: 출력될 행수를 지정한다.

설명
옵션으로 주는 행 숫자는 화면에 표시될 행의 개수를 의미한다. 만일 그것이 주어지지 않는다면 기본적으로 10개의 행을 출력한다.

사용예
     $ cat letter
     원일이에게.
     안뇽?
     자네가 돈을 빌려간지도 1년이 넘었네.
     난 포기 안하지.
     하루속히 갚기를 바라네.
     독촉해서 미안하군
     건강하길...
     1997년 모월 모일 친구가.

문서의 앞 머리 세 줄만 확인하기 위해서 다음과 같이 할 수 있다.
     $ head -3 letter
     원일이에게.
     안뇽?
     자네가 돈을 빌려간지도 1년이 넘었네.

■ hostname : 현재 설정되어 있는 호스트의 이름을 표시하거나 변경한다.

     hostname [ 호스트이름 ]

설명
이것은 인수없이 사용된다면 현재 설정되어 있는 호스트 이름을 보여준다. 리눅스는 기본적으로 프롬프트에서 호스트의 이름을 보여줄 것이다. 혹은 사용자가 프롬프트에 호스트 이름이 나타나도록 할 수도 있다. 인수로서 새로운 호스트 이름을 지정한다면 새로 지정된 이름으로 호스트 이름을 바꾼다. 하지만 이런 작업은 수퍼 유저만이 할 수 있다.

사용예
     $ hostname
     Blade

■ id : 시스템에 등록된 ID를 확인한다.

     id [ -gGnru ]

옵션
     -g: 그룹 ID만을 출력한다.
     -G: 추가 그룹들만을 출력한다.
     -n: ID 번호대신 이름으로 출력한다.
     -r: 실제 사용자나 그룹 ID를 출력한다. 다른 옵션과 함께 사용한다.
     -u: 사용자의 ID만을 출력한다.

사용예
     $ id -un

■ jobs : 현 터미널에서 수행된 작업들을 간략하게 나열해준다.

     jobs [ -I ]

옵션
     -I: 프로세서 번호를 추가해서 보여준다.

설명
jobs 명령에 대한 것은 fg와 bg명령에 대한 설명과 함께 3장을 참고하라.여기서는 프로세서 번호와 jobs 볼 수 있는 작업 번호에 대해 생각해 보자.

작업번호는 한 사용자의 작업에 대한 것으로, 1번부터 순서대로 부여되지만 다른 터미널의 다른 사용자도 같은 번호의 job을 가지는 것이다. 또한 이 작업 번호는 중지되었거나 백그라운드에 있는 것들만이 작업 번호가 주어진다는 점이다. 프로세서 번호는 시스템 중심적이고, 작업 번호는 사용자 중심적인 번호인 것이다.

■ join : 두 개의 정렬된 파일을 하나로 수평 병합한다.

     join [ -aejotv ] [파일명]1 [파일명]2

옵션
     -an : 첫 번째나 두 번째 파일로부터 일치하지 않는것도 처리, n은 1이나 2이다.
     -e 문자열 : 비어 있는 필드는 문자열로 대체한다.
     -j n m : 파일n의 m번째 필드를 두 파일에 병합한다.
     -o 파일 : 명시된 파일의 형태에 따라서 출력을 만든다.
     -t 문자 : 필드 구분 문자를 정한다. 기본적으로 공백, 탭, 기행 문자다.
     -v 파일 : 파일1이나 파일2의 짝이 연결되지 않는 행을 지정된 파일로 출력한다.

설명
두 파일의 내용을 하나의 파일로 병합하는데, cat을 사용하는 것처럼 한 파일의 뒤에 다른 하나를 추가하는 것이 아니라 각 행끼리 붙이기를 한다. 이 명령을 사용하면 두 개의 다른 데이터를 가진 목록을 합칠 수 있다.

■ kill : 현재 수행중인 프로세서에게 시그널을 보낸다. 보통 kill 명령은 프로세서를 죽이는 데에 사용된다. 그래서 이 유틸리티의 이름도 kill이 되었다.

     kill [-signalID] PID
     kill -l

옵션
     -signalID : 프로세서에게 보낼 시그널을 지정한다. 시그널은 번호로 지정될 수도 있고 시그널 이름으로 지정될 수도 있다.
     -l : 시그널 종류를 나열한다. 시그널의 종류는 시그널 번호 순서대로 이름으로 나열한다.

설명
시그널의 종류를 지정하지 않으면 프로세서를 종료시키는 의미로 디폴트 시그널 ID 15번을 보내게 된다. 예를 들면 당신이 시스템을 사용을 마치고 로그아웃할 때는 시그널 ID 1번의 HUP(hang up) 시그널이 시스템으로 전달되며, 이 시그널은 당신의 셸 상태에서 실행중인 모든 프로세서를 종료시키고(앞에서 언급한 nohup에 의한 프로세서는 제외) 로그아웃하게 한다.

사용예
     $ kill -l
     1) SIGHUP 2) SIGNT 3) SIGQUIT 4) SIGILL
     5) SIGTRAP 6) SIGIOT 7) SIGBUS SIGPPE
     9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2
     13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD
     1 SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN
     22) SIGTTOL 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
     26) SIGVTALRM 27) SIGPROF 2 SIGWINCH 29) SIGIO
     30) SIGPWR
     $ kill -9 16034
     $ kill -kill 16034 ,,두 명령은 같은 의미이다.
     $ kill -9 0

이것은 모든 프로세서를 종료시킨다.

■ less : more와 유사하게 페이지 단위로 문서를 보여준다. 이것은 문서의 앞으로도 이동하는 것이 가능하다.

      less [ -?acCeEinqQsx ] 파일명(들)

옵션
     -? : less에서 사용할 수 있는 명령들에 대한 도움말을 제공한다. 이 옵션이 사용되면 다른 인수는 무시되고, 도움말 화면을 보여준다.
     -a : 마지막 라인이 화면에 출력되고 나서 탐색을 시작한다.
     -c : 필요할 때 전체 화면은 다시 갱신한다.
     -C : -c 옵션과 같지만 갱신할 때 화면 전체를 지우고 시작한다.
     -e : 두 번째로 파일의 끝에 도달하면 자동적으로 종료한다.
     -E : 파일의 끝에 도달하기만 하면 자동적으로 종료한다.
     -i : 대소문자를 구분하여 탐색한다.
     -n : 행번호를 추가한다.
     -q : 특정 에러가 발생하지 않으면 아무 소리도 내지 않고 조용히 동작한다.
     -Q : 결코 아무 소리도 내지 않는다.
     -s : 연속되는 공백 라인은 하나의 행으로 처리한다.
     -x 숫자 : 수치를 지정해서 탭 간격을 조정한다. 기본값은 8이다.

설명
less는 많은 옵션과 키 사용법이 있다. 온라인 레퍼런스를 참조하기 바란다.

사용예
     $ less lovemessage

■ ln : 두 개의 파일 사이에 링크를 만들어, 하나의 파일을 두 개 이상의 이름으로 접근이 가능하도록 한다.

     ln [ -s ] 파일명1 파일명2
     ln 파일명들 디렉토리

옵션
     -s : 하드 링크 대신 심볼릭 링크를 만든다.

설명
유닉스 파일 시스템의 링크 개념의 자세한 내용에 대해서는 다른 자료를 참고하라. 파일을 복사하는 대신 링크를 사용하면 디스크 공간을 매우 절약할 수 있다. 위에서 보면 첫 번째 형식에서 파일명2는 원하는 링크 파일의 경로와 이름이 된다. 이것은 일종의 alias(별명)라고 생각할 수 있다. 두 번째 형식에서 파일명들은 링크되기 원하는 파일들의 이름이고, 디렉토리는 링크된 파일이 지정되기 원하는 위치이다. 링크에 익숙해지면 ln명령은 cp 명령을 사용하는 것처럼 간단하게 사용할 수 있을 것이다.

사용예
     $ ln project theplan ,,두 개의 이름은 같은 문서를 의미한다.

■ longname : 이것은 현재 시스템에서 당신이 사용하는 로그온 이름을 보여준다.

     longname

설명
longname은 옵션을 가지지 않는다. 이름은 /etc/utmp 파일을 알아낸다.

사용예
     $ longname

■ ls : 파일 시스템 상의 파일을 목록을 보여준다.

     ls [ -aCxdlstucriFR ][ 파일명(들) ]

옵션
     -a : 도트로 시작되는 이름을 가진 파일명도 전부 보여준다.
     -C : 가로 순서로 나열하여 출력한다.
     -x : 세로 순서로 나열하여 출력한다.
     -d : 현재 디렉토리에 대한 정보를 출력한다.
     -l : 각 파일들에 대한 소유자, 권한, 갱신일 등의 자세한 정보를 출력한다.
     -s : 파일이 얼마나 많은 디스크 블록을 차지하고 있는가를 보여준다.
     -t : 파일 갱신일 순서대로 정렬한다.
     -u : 엑세스(access)한 날짜 순서대로 정렬한다.
     -c : inode가 마지막 바뀐 시간 순서대로 정렬한다.
     -r : 정렬된 순서의 역으로 출력한다.
     -i : 파일의 inode 번호를 보여준다.
     -F : 파일의 특성을 쉽게 알 수 있는 문자를 나타낸다. +는 실행 가능한 파일을, /는 디렉토리 이름을 의미한다.      @는 심볼릭 링크를 나타내고, =는 소켓(socket)을 나타낸다. 하지만 여러분의 리눅스는 기본적으로 이러한 특성을 보여줄 것이다.