명령줄 인터페이스

섬네일|300px|페도라 15의 그놈 터미널 3에서 실행 중인 배시 세션 스크린샷
섬네일|300px|윈도우 비스타에서 실행 중인 윈도우 파워셸 1.0 스크린샷

명령줄 인터페이스(, CLI, 커맨드 라인 인터페이스) 또는 명령행 인터페이스, 명령어 인터페이스 또는 명령줄 셸은 텍스트 줄 형태로 구성된 명령어를 통해 소프트웨어와 상호작용하는 수단이다. 명령줄 인터페이스는 1960년대 중반 단말기에서 천공 카드를 사용하는 비대화형 방식에 대한 대화형이며 더 사용자 친화적인 대안으로 등장했다.

거의 30년 동안 CLI는 소프트웨어의 가장 일반적인 인터페이스였으나, 오늘날에는 그래픽 사용자 인터페이스(GUI)가 더 흔하게 사용된다. 그럼에도 불구하고 운영체제나 소프트웨어 개발 유틸리티와 같은 많은 프로그램은 여전히 CLI를 제공한다.

CLI는 명령어를 반복적으로 사용할 수 있는 스크립트 언어 파일에 저장할 수 있기 때문에 컴퓨터 프로그램의 자동화를 가능하게 한다. 스크립트를 사용하면 포함된 명령어들을 하나의 그룹(단일 프로그램)으로 실행할 수 있다.

CLI는 입력된 명령어를 실행하는 프로그램인 명령줄 인터프리터 또는 명령줄 프로세서에 의해 구현된다.

CLI의 대안으로는 (윈도우와 같은 데스크톱 메타포를 포함하는) GUI, 텍스트 사용자 인터페이스 기반의 메뉴 방식(도스 셸 및 IBM AIX SMIT 포함), 그리고 단축키 등이 있다.

 그래픽 사용자 인터페이스와의 비교 

섬네일|250px|아이콘과 창을 사용하는 그래픽 사용자 인터페이스(GEM 1.1 데스크톱)
그래픽 사용자 인터페이스와 비교할 때, 명령줄 인터페이스는 구현에 더 적은 시스템 리소스를 필요로 한다. 명령어의 옵션이 각 명령줄에 몇 개의 문자로 주어지기 때문에 숙련된 사용자는 종종 옵션에 접근하는 것이 더 쉽다고 느낀다. 반복적인 작업의 자동화는 자주 사용되는 시퀀스를 저장하는 줄 편집 및 히스토리 메커니즘을 통해 간소화되며, 이는 매개변수와 변수 옵션을 가질 수 있는 스크립트 언어로 확장될 수 있다. 명령줄 히스토리를 유지하여 명령을 검토하거나 반복할 수 있다.

명령줄 시스템은 사용자가 참고하기 위해 종이 또는 온라인 매뉴얼이 필요할 수 있지만, 종종 도움말 옵션을 통해 명령어 옵션에 대한 간결한 검토를 제공한다. 명령줄 환경은 GUI에서 볼 수 있는 다양한 글꼴이나 확장된 편집 창과 같은 그래픽적 향상을 제공하지 않을 수 있다. 초보 사용자가 매뉴얼을 참조하지 않고 그래픽 사용자 인터페이스의 아이콘 및 드롭다운 메뉴와 비교하여 사용 가능한 모든 명령어와 옵션에 익숙해지는 것은 어려울 수 있다.

 종류 
 운영체제 명령줄 인터페이스 
운영체제(OS) 명령줄 인터페이스는 대개 운영체제와 함께 제공되는 별개의 프로그램이다. 이러한 텍스트 인터페이스를 구현하는 프로그램은 종종 명령줄 인터프리터, 명령 프로세서 또는 셸이라고 불린다.

명령줄 인터프리터의 예로는 Nushell, 디지털 이큅먼트 코퍼레이션(DEC)의 OpenVMS 및 용 DIGITAL 명령 언어(DCL), 다양한 유닉스 셸(sh, ksh, csh, tcsh, zsh, 배시 등), 의 콘솔 명령 프로세서(CCP), 도스의 COMMAND.COM, 그리고 OS/2 및 윈도우의 Cmd.exe 프로그램이 있다. 후자 그룹은 DEC의 RSX-11 및 RSTS/E CLI를 기반으로 한다. 대부분의 운영체제에서 기본 셸 프로그램을 대안으로 교체할 수 있다. 예로는 도스용 4DOS, OS/2용 4OS2, 윈도우용 4NT / Take Command가 있다.

비록 셸이라는 용어가 명령줄 인터프리터를 설명하는 데 자주 사용되지만, 엄밀히 말하면 셸은 명령 인터프리터이자 프로세서이며, 더 나아가 명령 인터프리터 및 프로세서와 운영체제의 광범위한 기능에 대한 인터페이스(사용자 인터페이스(CLI, GUI 등) 또는 프로그래밍 인터페이스)를 제공하는 프로그램이다. 예를 들어, 기본 윈도우 GUI는 WIN.INI 설정 파일의 SHELL=EXPLORER.EXE 줄에 정의된 대로 EXPLORER.EXE라는 이름의 셸 GUI이다. 이 프로그램은 엄밀히 말해 셸 GUI이자 확장된 의미의 셸이지만(엄밀히 말하면 윈도우 셸은 shell32.dll이며 explorer.exe는 shell32.dll을 위한 셸 GUI임), CLI(명령줄 인터프리터)나 셸 CLI(셸 명령줄 인터페이스)는 아니다.

 애플리케이션 명령줄 인터페이스 
섬네일|250px|명령줄 인터페이스를 포함한 GNU 옥타브의 GUI
(운영체제와 대비되는) 애플리케이션 프로그램 또한 명령줄 인터페이스를 가질 수 있다.

애플리케이션 프로그램은 다음 세 가지 주요 명령줄 인터페이스 메커니즘 중 일부 또는 전부를 지원할 수 있다:

 매개변수: 대부분의 명령줄 인터페이스는 프로그램이 실행될 때 프로그램에 추가 정보를 전달하는 수단을 지원한다.
 대화형 명령줄 세션: 실행 후, 프로그램은 운영자에게 명령을 입력할 수 있는 독립적인 수단을 제공할 수 있다.
 프로세스 간 통신: 대부분의 운영체제는 프로세스 간 통신 수단(예: 표준 스트림 또는 명명된 파이프)을 지원한다. 클라이언트 프로세스의 명령줄은 이러한 방법 중 하나를 통해 CLI 프로그램으로 리다이렉션될 수 있다.

일부 애플리케이션은 사용자에게 자체 프롬프트를 제시하고 명령줄을 수락하는 CLI를 지원한다. 다른 프로그램은 CLI와 GUI를 모두 지원한다. 어떤 경우에는 GUI가 단순히 별도의 CLI 실행 파일을 감싸는 래퍼 역할을 하기도 한다. 또 다른 경우에는 프로그램이 GUI에 대한 선택적 대안으로 CLI를 제공할 수 있다. CLI와 GUI는 종종 서로 다른 기능을 지원한다. 예를 들어, 수치해석학 컴퓨터 프로그램인 매트랩의 모든 기능은 CLI를 통해 사용할 수 있는 반면, 매트랩 GUI는 기능의 일부만 노출한다.

1975년의 콜로설 케이브 어드벤처에서 사용자는 동굴 시스템을 탐험하기 위해 한두 단어를 입력하는 CLI를 사용한다.

 역사 
명령줄 인터페이스는 사람들이 전신타자기(TTY) 기기를 통해 수행하던 통신 방식에서 진화했다. 때때로 여기에는 텔렉스를 사용하여 주문이나 확인을 보내는 것이 포함되었다. 초기 컴퓨터 시스템은 종종 운영자와의 상호작용 수단으로 전신타자기를 사용했다.

기계식 전신타자기는 전신타자기를 에뮬레이트하는 키보드와 화면인 "글래스 tty"로 대체되었다. "지능형" 단말기는 전체 화면에서의 커서 이동이나 컴퓨터로 전송하기 위한 단말기에서의 로컬 데이터 편집과 같은 추가 기능을 허용했다. 마이크로컴퓨터 혁명이 전통적인미니컴퓨터 + 단말기{{Snd]]시분할 시스템 구조를 대체함에 따라, 하드웨어 단말기는 PC의 직렬 포트를 통해 전송된 단말기 신호를 해석하는 PC 소프트웨어인 단말 에뮬레이터로 대체되었다. 이것들은 일반적으로 조직의 새 PC를 기존 미니컴퓨터나 메인프레임 컴퓨터와 연결하거나 PC끼리 연결하는 데 사용되었다. 이 PC들 중 일부는 BBS 소프트웨어를 실행하고 있었다.

초기 운영체제 CLI는 상주 모니터 프로그램의 일부로 구현되었으며 쉽게 교체할 수 없었다. 교체 가능한 구성 요소로서의 셸의 첫 번째 구현은 멀틱스 시분할 시스템 운영체제의 일부였다. 1964년, MIT 계산 센터 직원인 루이 푸진은 인수 대체를 허용하면서 명령 스크립트를 실행하기 위한 RUNCOM 도구를 개발했다. 푸진은 명령어를 프로그래밍 언어처럼 사용하는 기술을 설명하기 위해 셸이라는 용어를 만들었고, 멀틱스 운영체제에서 이 아이디어를 구현하는 방법에 대한 논문을 썼다. 푸진은 1965년에 고국인 프랑스로 돌아갔고, 최초의 멀틱스 셸은 글렌다 슈뢰더에 의해 개발되었다.

섬네일|250px|버전 7 유닉스에서의 본 셸 상호작용
최초의 유닉스 셸인 톰프슨 셸(V6 셸)은 1971년 벨 연구소에서 켄 톰프슨에 의해 개발되었으며 슈뢰더의 멀틱스 셸을 모델로 했다. 본 셸은 1977년 V6 셸의 대체품으로 도입되었다. 대화형 명령 인터프리터로 사용되지만, 스크립트 언어로도 의도되었으며 구조화된 프로그램을 생성하는 데 일반적으로 간주되는 대부분의 기능을 포함하고 있다. 본 셸은 콘셸(ksh), 암키스트 셸(ash), 그리고 인기 있는 배시(Bash)의 개발로 이어졌다.

초기 마이크로컴퓨터 자체는 CP/M, 도스 또는 애플소프트 베이직과 같은 명령줄 인터페이스를 기반으로 했다. 1980년대와 1990년대 동안 애플 매킨토시와 PC에서의 마이크로소프트 윈도우 도입으로 주요 사용자 인터페이스로서의 명령줄 인터페이스는 그래픽 사용자 인터페이스로 대체되었다. 명령줄은 시스템 관리, 컴퓨터 프로그래밍 및 일괄 처리를 위해 시스템 관리자 및 기타 고급 사용자가 자주 사용하는 대안 사용자 인터페이스로 남았다.

2006년 11월, 마이크로소프트는 전통적인 유닉스 셸의 기능과 자사의 객체 지향 닷넷 프레임워크를 결합한 윈도우 파워셸(이전 코드명 Monad) 1.0 버전을 출시했다. MinGW와 시그윈은 윈도우에서 유닉스 스타일의 CLI를 제공하는 오픈 소스 소프트웨어 패키지이다. 마이크로소프트는 윈도우 서비스 포 유닉스 애드온을 통해 MKS Inc.의 ksh 구현체인 MKS 콘 셸을 윈도우용으로 제공한다.

2001년 이후 매킨토시 운영체제인 MacOS는 다윈이라는 유닉스 계열 운영체제를 기반으로 하고 있다. 이러한 컴퓨터에서 사용자는 응용 프로그램 폴더의 유틸리티 하위 폴더에 있는 단말 에뮬레이터 프로그램인 터미널을 실행하거나 ssh를 사용하여 원격으로 접속함으로써 유닉스 계열 명령줄 인터페이스에 접근할 수 있다. Z 셸은 MacOS의 기본 셸이며, 배시, tcsh, 콘셸도 제공된다. MacOS 카탈리나 이전에는 배시가 기본이었다.

 용도 
CLI는 방대한 명령어 또는 쿼리 어휘와 넓은(또는 임의의) 범위의 옵션이 결합되어 순수 GUI보다 텍스트로 더 빠르게 입력될 수 있을 때마다 사용된다. 이는 일반적으로 운영체제 명령 셸의 경우에 해당한다. CLI는 그래픽 사용자 인터페이스를 지원하기에 리소스가 부족한 시스템에서도 사용된다. 일부 컴퓨터 언어 시스템(파이썬, 포스, LISP, REXX, 그리고 많은 베이직 방언 등)은 코드의 신속한 평가를 가능하게 하는 대화형 명령줄 모드를 제공한다.

CLI는 프로그래머와 시스템 관리자, 공학 및 과학 환경, 그리고 기술적으로 숙련된 개인용 컴퓨터 사용자에 의해 자주 사용된다. 또한 명령어와 응답을 점자 단말기를 사용하여 표시할 수 있기 때문에 시각 장애가 있는 사람들 사이에서도 인기가 있다.

 셸 CLI의 구조 

명령줄의 일반적인 패턴은 다음과 같다:

 프롬프트 명령어 매개변수1 매개변수2 매개변수3 … 매개변수N

 프롬프트 — 입력 준비가 되었음을 나타내기 위해 프로그램에 의해 출력됨. 프롬프트에는 상황 정보가 포함될 수 있으며, 종종 입력이 예상된다는 시각적 신호를 제공하는 기호로 끝난다.
 명령어 — 사용자에 의해 입력됨. 명령어는 대개 두 가지 부류 중 하나이다:
 내부 명령어는 명령줄 인터프리터에 의해 인식되고 처리된다. 내부 명령어는 빌트인 명령어로도 불린다.
 외부 명령어는 별도의 실행 파일에 있는 실행 파일을 실행한다. 명령줄 인터프리터는 외부 명령어와 일치하는 이름을 가진 실행 파일을 검색한다.
 매개변수1 …매개변수N — 사용자에 의해 제공되는 매개변수. 매개변수의 형식과 의미는 명령어에 따라 다르다. 외부 명령어의 경우, 매개변수 값은 OS에 의해 프로그램이 실행될 때 전달된다. 매개변수는 인수 또는 옵션일 수 있다.

이 형식에서 명령줄 요소 사이의 구분 기호는 공백 문자이며, 줄 끝 구분 기호는 새줄 문자이다. 이는 널리 사용되지만 보편적이지는 않은 관례이다.

CLI는 일반적으로 구문과 의미론으로 구성된 것으로 간주될 수 있다. 구문은 모든 명령어가 따라야 하는 문법이다. 운영체제의 경우, 도스와 유닉스는 각각 모든 명령어가 따라야 하는 자체 규칙 세트를 정의한다. 임베디드 시스템의 경우, 노텔, 주니퍼 네트웍스 또는 시스코 시스템즈와 같은 각 벤더가 자체적인 전용 규칙 세트를 정의한다. 이러한 규칙은 사용자가 명령어 시스템을 탐색하는 방법도 규정한다. 의미론은 어떤 종류의 작업이 가능한지, 어떤 종류의 데이터에 대해 이러한 작업이 수행될 수 있는지, 그리고 문법이 이러한 작업과 데이터를 어떻게 표현하는지(구문의 상징적 의미)를 정의한다.

두 개의 서로 다른 CLI가 구문이나 의미론 중 하나에서 일치할 수 있지만, 사용자가 새로 배울 필요 없이 두 CLI를 모두 사용할 수 있게 하고 스크립트의 재사용을 가능하게 하려면 두 가지 모두에서 일치해야 한다.

단순한 CLI는 프롬프트를 표시하고, 사용자가 입력하고 엔터 키로 종료한 명령줄을 수락한 다음, 지정된 명령을 실행하고 결과나 오류 메시지를 텍스트로 표시한다. 고급 CLI는 명령을 실행하기 전에 명령줄을 검증, 해석 및 매개변수 확장하며, 선택적으로 출력을 캡처하거나 리다이렉션한다.

GUI의 버튼이나 메뉴 항목과 달리, 명령줄은 일반적으로 사용자가 수행하려는 작업을 정확히 명시하므로 자기 문서화적이다. 또한 명령줄에는 결과를 사용자 지정하기 위해 변경할 수 있는 많은 기본값이 포함되는 경우가 많다. 유용한 명령줄은 전체 명령을 나타내는 별칭을 할당하여 저장하거나, 여러 명령을 그룹화하여 더 복잡한 시퀀스(예: 프로그램 컴파일, 설치 및 실행)를 수행하도록 하여 명령 프로시저 또는 스크립트라고 불리는 단일 개체를 만들 수 있으며, 이 자체가 하나의 명령처럼 취급될 수 있다. 이러한 장점은 사용자가 복잡한 명령이나 일련의 명령을 한 번만 파악하면 저장하여 다시 사용할 수 있음을 의미한다.

CLI 셸에 주어지는 명령어는 종종 다음과 같은 형식 중 하나이다:

 doSomething how toFiles
 doSomething how sourceFile destinationFile
 doSomething how < inputFile > outputFile
 doSomething how | doSomething how | doSomething how > outputFile

여기서 doSomething은 사실상 동사, how는 부사(예: 명령을 자세히 실행할지 조용히 실행할지), toFiles는 명령이 작용해야 하는 객체(일반적으로 하나 이상의 파일)이다. 세 번째 예시의 >는 리다이렉션 연산자로, 명령줄 인터프리터에게 명령의 출력을 자체 표준 출력(화면)이 아닌 지정된 파일로 보내도록 지시한다. 이는 파일을 덮어쓰게 된다. >>를 사용하면 출력을 리다이렉션하여 파일 끝에 추가한다. 또 다른 리다이렉션 연산자는 수직선(|)으로, 한 명령의 출력이 다음 명령의 입력이 되는 파이프라인을 생성한다.

 CLI와 리소스 보호 
유닉스 계열 시스템이나 윈도우와 같은 일부 시스템에서는 PATH 환경 변수 또는 그에 상응하는 경로에 나타나는 경로를 수정하여 사용 가능한 명령 세트를 수정할 수 있다. 유닉스 계열 시스템에서 명령어의 실행 파일이나 스크립트를 포함하는 파일에는 실행 권한이 부여되어야 한다. 경로 변수의 디렉토리는 주어진 순서대로 검색된다. 경로 순서를 재조정함으로써, 예를 들어 기본값과 반대일 때 대신 를 실행할 수 있다. 실행 파일의 이름을 바꾸는 것도 가능하다. 예를 들어 사람들은 종종 자신이 즐겨 쓰는 편집기의 이름을 EDIT로 바꾸곤 한다.

명령줄을 사용하면 고급 내부 명령에 대한 액세스와 같이 사용 가능한 명령을 제한할 수 있다. 본 셸 및 배시와 같은 유사 셸은 제한된 셸로 실행될 수 있다. 무엇보다도 이는 사용자가 PATH 환경 변수를 수정하는 것을 금지하므로, PATH가 허용된 명령만 포함된 디렉토리만 포함하도록 설정된 경우 사용자는 해당 명령만 실행할 수 있다. 윈도우 Cmd.exe 또한 사용 가능한 명령 제한을 지원한다. 종종 쉐어웨어 프로그램은 프롬프트에서 '관리자가 배치 파일 실행을 비활성화했습니다'라는 메시지를 출력하는 등 명령 범위를 제한한다.

네트워크 라우터에 있는 것과 같은 일부 CLI에는 각 모드에서 서로 다른 명령 세트가 지원되는 계층적 모드가 있다. 명령 세트는 보안, 시스템, 인터페이스 등과의 연관성에 따라 그룹화된다. 이러한 시스템에서 사용자는 일련의 하위 모드를 거칠 수 있다. 예를 들어, CLI에 인터페이스와 시스템이라는 두 가지 모드가 있는 경우, 사용자는 인터페이스 모드로 들어가기 위해 interface 명령을 사용할 수 있다. 이 시점에서 시스템 모드의 명령은 사용자가 인터페이스 모드를 종료하고 시스템 모드로 들어갈 때까지 접근하지 못할 수 있다.

IBM의 주력 MVS 운영체제에서 인가된 프로그램 시설(APF)은 특정 인가된 프로그램이 유닉스 계열 시스템의 UID(0)와 유사하게 향상된 권한으로 실행될 수 있도록 허용한다. TSO/E는 인가된 명령 호출 등을 지원하지만, 설치 제어 목록에 있는 해당 명령, 프로그램 및 서비스에 대해서만 지원한다.

 명령 프롬프트 
섬네일|전원을 켜거나 하드 리셋 후의 BBC 마이크로 프롬프트

명령 프롬프트(또는 그냥 프롬프트)는 명령을 수락할 준비가 되었음을 나타내기 위해 명령줄 인터페이스에서 사용되는 (하나 이상의) 문자 시퀀스이다. 이는 문자 그대로 사용자에게 조치를 취하도록 프롬프트(촉구)한다. 프롬프트는 대개 $, %, #, :, > 또는 - 문자 중 하나로 끝나며, 현재 작업 디렉토리의 경로 및 호스트명과 같은 다른 정보를 포함하는 경우가 많다.

많은 유닉스 및 파생 시스템에서 프롬프트는 일반 사용자의 경우 $ 또는 %로 끝나지만, 슈퍼유저(유닉스 용어로 "root")인 경우 #으로 끝나는 것이 일반적이다.

최종 사용자는 종종 프롬프트를 수정할 수 있다. 환경에 따라 색상, 특수 문자 및 기타 요소(현재 시간, 사용자, 셸 번호 또는 작업 디렉토리에 대한 변수 및 함수 등)를 포함하여 프롬프트를 더 유익하거나 시각적으로 즐겁게 만들고, 다양한 머신의 세션을 구분하거나, 현재 명령의 중첩 수준을 나타낼 수 있다. 일부 시스템에서는 프롬프트를 표시하는 동안 명령줄 인터프리터가 외부 프로그램을 호출하도록 하기 위해 프롬프트 정의에 특수 토큰을 사용할 수 있다.

도스의 COMMAND.COM 및 윈도우 NT의 Cmd.exe에서 사용자는 PROMPT 명령을 내리거나 해당 %PROMPT% 환경 변수 값을 직접 변경하여 프롬프트를 수정할 수 있다. 대부분의 현대 시스템의 기본값인 C:\> 스타일은 예를 들어 PROMPT $P$G로 얻을 수 있다. 이전 도스 시스템의 기본값인 C>는 PROMPT만으로 얻을 수 있지만, 일부 시스템에서는 플로피 드라이브 A: 또는 B:에서 사용하지 않는 한 최신 C:\> 스타일이 생성된다. 이러한 시스템에서는 자동 기본값을 무시하고 이전 스타일로 명시적으로 전환하기 위해 PROMPT $N$G를 사용할 수 있다.

많은 유닉스 시스템은 $PS1 변수(프롬프트 문자열 1)를 사용하지만, 다른 변수들도 사용되는 셸에 따라 프롬프트에 영향을 줄 수 있다. 배시 셸에서 다음과 같은 형식의 프롬프트는:

[time] user@host: work_dir $
다음 명령을 실행하여 설정할 수 있다.
export PS1='[\t] \u@\H: \W $'

zsh에서 $RPROMPT 변수는 디스플레이 오른쪽에 선택적 프롬프트를 제어한다. 텍스트 입력 위치가 바뀌지 않는다는 점에서 실제 프롬프트는 아니다. 이는 프롬프트와 동일한 줄에 정보를 표시하되 오른쪽으로 정렬하는 데 사용된다.

RISC OS에서 명령 프롬프트는 * 기호이며, 따라서 (OS) CLI 명령은 종종 스타 명령(star commands)으로 불린다. BBC 베이직 명령줄과 같은 다른 명령줄에서도 명령 앞에 *를 붙여 동일한 명령에 접근할 수 있다.

IBM의 TSO에서 명령 프롬프트는 프롬프트의 READY라는 단어를 따서 READY 프롬프트라고 불린다.

배시, zsh, 파워셸과 같은 일부 셸은 원격 연결 유형, 머신 센서 상태 또는 버전 관리 시스템에 대한 추가 정보와 같이 훨씬 더 많은 정보를 명령 프롬프트에 표시하는 프롬프트 시스템을 사용할 수 있게 해준다. 이들은 종종 화려한 디스플레이를 설정하기 위해 여러 ANSI 색상, 유니코드 문자 및 고급 셸 기능을 사용한다.

 인수 

섬네일|right|명령어와 인수로 파싱되는 것을 보여주는 MS-DOS 명령줄
명령줄 인수 또는 매개변수는 프로그램이 시작될 때 제공되는 정보 항목이다. 프로그램은 정보의 소스나 대상을 식별하거나 프로그램의 작동을 변경하는 많은 명령줄 인수를 가질 수 있다.

명령 프로세서가 활성화되어 있을 때 프로그램은 일반적으로 이름을 입력하고 그 뒤에 명령줄 인수(있는 경우)를 입력하여 호출된다. 예를 들어, 유닉스 및 유닉스 계열 환경에서 명령줄 인수의 예는 다음과 같다:

rm file.s

는 프로그램 rm에게 라는 이름의 파일을 제거하도록 지시하는 명령줄 인수이다.

C, C++, 자바와 같은 일부 프로그래밍 언어는 메인 함수에서 문자열 매개변수로 처리하여 프로그램이 명령줄 인수를 해석할 수 있도록 허용한다. 파이썬과 같은 다른 언어는 sys 모듈, 특히 명령줄 인수를 위한 sys.argv를 통해 운영체제별 API 기능을 노출한다.

유닉스 계열 운영체제에서 파일 이름 대신 사용되는 단일 하이픈은 프로그램이 표준 입력에서 오는 데이터를 처리하거나 표준 출력으로 데이터를 보내야 함을 지정하는 특수 값이다.

 명령줄 옵션 

명령줄 옵션 또는 단순히 옵션(플래그 또는 스위치라고도 함)은 명령어의 작동을 수정하며, 그 효과는 명령어의 프로그램에 의해 결정된다. 옵션은 명령줄의 명령어 이름 뒤에 오며 쉼표, 공백 등으로 구분된다. 구분 기호가 항상 필요한 것은 아니다. 예를 들어 도스의 Dir/?와 DIR /?는 동일한 효과를 내며 DIR 명령의 사용 가능한 옵션을 나열하는 반면, (많은 유닉스 버전의) dir --help는 옵션 앞에 적어도 하나의 공백이 필요하다(또한 대소문자를 구분한다).

옵션의 형식은 운영체제마다 크게 다르다. 대부분의 경우 구문은 운영체제 요구 사항이라기보다는 관례에 가깝다. 전체 명령줄은 단순히 프로그램에 전달되는 문자열이며, 인터프리터가 명령어 이름이 어디서 끝나고 인수와 옵션이 어디서 시작되는지 알 수만 있다면 프로그래머가 원하는 방식으로 처리할 수 있다.

몇 가지 관례를 설명하기 위해 주로 디렉토리의 파일을 나열하는 것과 관련된 몇 가지 대표적인 명령줄 옵션 샘플은 다음과 같다:

프로그램의 인수를 파싱하기 위해 명령줄 인수 파싱이 사용되며, 이러한 기능은 다양한 언어에서 제공된다. 예를 들어, 인수를 파싱하기 위해 C POSIX 라이브러리에 가 있다.

 명령어 축약 #####

멀틱스에서 명령줄 옵션과 하위 시스템 키워드는 축약될 수 있다. 이 아이디어는 키워드가 단축된 PL/I 프로그래밍 언어(예: STRINGRANGE의 경우 STRG, DECLARE의 경우 DCL)에서 유래한 것으로 보인다. 예를 들어, 멀틱스 forum 하위 시스템에서 -long_subject 매개변수는 -lgsj로 축약될 수 있다. 또한 멀틱스 명령어를 축약하는 것도 일반적이며, 대개 밑줄로 연결된 단어들의 첫 글자에 해당한다. 예를 들어 delete_iacl_dir 대신 did를 사용하는 식이다.

일부 다른 시스템에서 축약은 자동적이다. 예를 들어 명령 이름을 고유하게 식별할 수 있을 만큼의 첫 글자들을 허용하는 방식(예: SUPERUSER의 축약형으로 SU 허용)이 있고, 다른 시스템에서는 특정 축약형이 미리 프로그램되어 있거나(예: COMMAND.COM의 MD), 배치 스크립트 및 별칭(예: tcsh의 alias md mkdir)을 통해 사용자 정의될 수 있다.

 도스, 윈도우, OS/2의 옵션 관례 #####
도스, OS/2 및 윈도우에서 COMMAND.COM 또는 Cmd.exe로부터 호출되는 서로 다른 프로그램(또는 내부 명령어)은 동일한 운영체제 내에서 서로 다른 구문을 사용할 수 있다. 예를 들어:

 옵션은 스위치 문자인 /, - 중 하나로 표시되거나 둘 다 허용될 수 있다. 아래를 참조하라.
 대소문자를 구분할 수도 있고 그렇지 않을 수도 있다.
 때로는 옵션과 인수가 붙어 있고, 때로는 공백으로 구분되며, 때로는 : 또는 =와 같은 문자로 구분된다. 따라서 Prog -fFilename, Prog -f Filename, Prog -f:Filename, Prog -f=Filename 등이 가능하다.
 일부 프로그램은 단일 문자 옵션을 결합하는 것을 허용하지만 다른 프로그램은 허용하지 않는다. 스위치 -fA가 -f -A와 동일할 수도 있고, 잘못된 것일 수도 있으며, 심지어 유효하지만 다른 매개변수일 수도 있다.

도스, OS/2 및 윈도우에서는 슬래시(/)가 가장 널리 사용되지만, 하이픈 마이너스도 가끔 사용된다. 도스의 많은 버전(MS-DOS/PC DOS 2.xx 이상, 5.0 이후의 모든 DR-DOS 버전, PTS-DOS, 임베디드 도스, 프리도스 및 RxDOS)에서 사용될 스위치 문자(종종 switchar 또는 switchchar로 축약됨)는 시스템 호출(INT 21h/AX=3700h)에서 반환된 값에 의해 정의된다. 이 API에 의해 반환되는 기본 문자는 /이지만, 위에 언급된 시스템들에서는 하이픈 마이너스로 변경될 수 있다. 다만 Datalight ROM-DOS 및 MS-DOS/PC DOS 5.0 이상에서는 이 호출에서 항상 /를 반환한다(SwitChar 기능을 다시 활성화하기 위해 사용 가능한 많은 TSR 중 하나를 로드하지 않는 한). 이러한 시스템 중 일부(MS-DOS/PC DOS 2.xx, DOS Plus 2.1, DR-DOS 7.02 이상, PTS-DOS, 임베디드 도스, 프리도스 및 RxDOS)에서는 CONFIG.SYS의 SWITCHAR 지시어에 의해 설정을 미리 구성할 수도 있다. General Software의 임베디드 도스는 동일한 목적을 위해 SWITCH 명령을 제공하는 반면, 4DOS는 SETDOS /W:n을 통해 설정을 변경할 수 있게 해준다. DR-DOS에서 설정이 /에서 변경된 경우, PROMPT 매개변수 $G의 표시에서 첫 번째 디렉토리 구분 기호 \가 슬래시 /(도스, FlexOS, 4680 OS, 4690 OS, OS/2 및 윈도우에서도 유효한 디렉토리 구분 기호임)로 변경되어 시각적으로 변경을 알려준다. 또한 현재 설정은 내장 도움말 화면에도 반영된다. 일부 DR-DOS COMMAND.COM 버전은 현재 설정을 표시하기 위해 $/ 프롬프트 토큰도 지원한다. DR-DOS 7.02 이후의 COMMAND.COM은 이식 가능한 배치 작업을 작성할 수 있도록 %/%라는 이름의 의사 환경 변수도 제공한다. 여러 외부 DR-DOS 명령은 시스템 설정을 재정의하기 위해 %SWITCHAR% 환경 변수를 추가로 지원한다.

그러나 많은 프로그램은 명령줄 인수를 파싱하기 전에 스위치 설정을 검색하지 않고 /만 사용하도록 고정되어 있다. 주로 유닉스 계열 시스템에서 포팅된 아주 소수의 프로그램은 스위치 문자가 설정되어 있지 않더라도 -를 수용하도록 프로그래밍되어 있다(예를 들어 마이크로소프트 윈도우와 함께 제공되는 Netstat 및 ping은 사용 가능한 옵션을 나열하기 위해 /? 옵션을 수락하지만, 목록은 - 관례를 지정한다).

 유닉스 계열 시스템의 옵션 관례 #####

유닉스 계열 시스템에서는 ASCII 하이픈 마이너스가 옵션의 시작을 나타낸다. 새로운 (그리고 GNU) 관례는 옵션의 용도를 식별하기 위해 두 개의 하이픈 뒤에 단어를 사용하는 것이고(예: --create), 오래된 관례(자주 사용되는 옵션을 위해 여전히 사용 가능함)는 하나의 하이픈 뒤에 하나의 글자를 사용하는 것이다(예: -c). 하나의 하이픈 뒤에 두 개 이상의 글자가 오면 두 개의 옵션이 지정된 것을 의미하거나, 두 번째 이후의 글자가 첫 번째 옵션에 대한 매개변수(파일명 또는 날짜 등)임을 의미할 수 있다.

뒤에 글자가 없는 두 개의 하이픈 마이너스 문자(--)는 나머지 인수가 옵션으로 처리되지 않아야 함을 나타낼 수 있다. 이는 예를 들어 파일 이름 자체가 하이픈으로 시작하거나 추가 인수가 내부 명령(예: Sudo)을 위한 것일 때 유용하다. 더 설명적인 옵션 이름이 사용되는 긴 옵션의 접두사로 이중 하이픈 마이너스가 사용되기도 한다. 이는 GNU 소프트웨어의 공통된 특징이다. 명령줄 옵션을 파싱하기 위해 일반적으로 Getopt 함수 및 프로그램과 getopts 명령어가 사용된다.

유닉스 명령어 이름, 인수 및 옵션은 대소문자를 구분한다(다른 운영체제의 인기 있는 명령어가 유닉스로 포팅된 몇 가지 사례는 제외).

 기타 시스템의 옵션 관례 #####
FlexOS, 4680 OS 및 4690 OS는 -를 사용한다.

CP/M은 일반적으로 [를 사용했다.

대화형 모니터 시스템(CMS)은 명령 끝에 있는 옵션을 다른 인수와 구분하기 위해 단일 왼쪽 괄호를 사용한다. 예를 들어, 다음 명령에서 옵션은 대상 파일이 존재하면 교체하고 원본 파일의 날짜와 시간을 복사본에 유지해야 함을 나타낸다:
COPY source file a target file b (REPLACE OLDDATE)

OS/360 운영자 명령은 쉼표로 구분된 위치 및 키워드 매개변수 목록을 사용하며, 문서화된 명령어 및 키워드 축약형만 유효하다. 키워드 값은 등호로 키워드와 구분된다.

TSO 명령은 공백으로 구분된 위치 및 키워드 매개변수 목록을 사용하며, 키워드는 임의의 고유한 부분 문자열로 잘릴 수 있다. 문서화된 명령어 축약형만 유효하다. 키워드 값은 괄호 안에 들어간다.

데이터 제너럴의 RDOS, AOS 등의 운영체제 하에서의 CLI 및 그들의 비즈니스 베이직과 함께 제공된 CLI 버전은 /만 스위치 문자로 사용하며, 대소문자를 구분하지 않고 일부 인수가 해석되는 방식을 제어하기 위해 해당 인수에 대한 로컬 스위치를 허용한다. 예를 들어 는 매크로 어셈블러 명령에 사용자 기호를 추가하기 위한 글로벌 옵션 를 가지지만, LIB가 패스 2에서 건너뛰어야 함을 지정하는 로컬 스위치와 출력을 프린터 $LPT로 보내도록 지시하는 로컬 스위치 두 개를 가지고 있다.

 내장 사용법 도움말 

CLI에 대한 비판 중 하나는 사용 가능한 작업에 대한 단서가 부족하다는 점이다. 반면 GUI는 대개 메뉴, 아이콘 또는 기타 시각적 단서를 통해 사용 가능한 작업을 사용자에게 알린다. 이러한 한계를 극복하기 위해 많은 CLI 프로그램은 인수가 없거나 ?, -?, -h, -H, /?, /h, /H, /Help, -help, --help 중 하나로 호출될 때 사용법 메시지를 표시한다.

그러나 명령줄 인수가 선택적인 프로그램 및 스크립트는 추가 통지 없이 실행되므로, 사용법 도움말이 표시될 것이라는 기대로 매개변수 없이 프로그램 이름을 입력하는 것은 위험할 수 있다.

도움말 매개변수의 경우 적어도 바람직하긴 하지만, 프로그램이 위에 예시된 모든 옵션 시작 문자를 지원하지 않을 수도 있다.
기본 명령줄 옵션 문자를 /에서 -로 변경할 수 있는 도스에서, 프로그램은 현재 설정을 결정하기 위해 SwitChar API를 쿼리할 수 있다. 따라서 프로그램이 이를 모두 지원하도록 고정되어 있지 않다면, 사용자는 도움말을 안정적으로 요청하기 위해서라도 현재 설정을 알아야 할 수도 있다.
SwitChar가 -로 변경되어 도스 명령줄에서도 / 문자가 대체 경로 구분 기호로 수락되는 경우, 프로그램은 /h 또는 /H와 같은 옵션을 도움말 매개변수가 아닌 경로로 오해할 수 있다. 그러나 첫 번째 또는 유일한 매개변수로 주어지면, 대부분의 도스 프로그램은 관례에 따라 현재 SwitChar 설정에 관계없이 도움말 요청으로 수락한다.

어떤 경우에는 프로그램에 대해 서로 다른 수준의 도움말을 선택할 수 있다. 이를 지원하는 일부 프로그램은 도움말 매개변수에 선택적 인수로 상세 수준을 줄 수 있게 하거나(예: /H:1, /H:2 등), 물음표로는 도움말 매개변수에 대한 짧은 도움말만 주고 다른 도움말 옵션으로는 더 긴 도움말 화면을 제공하기도 한다.

프로그램에 따라, 수락된 매개변수에 대한 추가적이거나 더 구체적인 도움말은 해당 매개변수를 도움말 매개변수의 인수로 제공하거나 그 반대로 제공함으로써 가능할 때가 있다(예: /H:W 또는 /W:? (여기서 /W는 프로그램에서 지원하는 다른 매개변수라고 가정함)).

도움말 매개변수와 유사한 방식이지만 훨씬 덜 흔한 것으로, 일부 프로그램은 -!, /!, -about, 또는 --about과 같은 about 매개변수로 호출될 때 자신에 대한 추가 정보(모드, 상태, 버전, 작성자, 라이선스 또는 연락처 정보 등)를 제공한다.

? 및 ! 문자는 일반적으로 명령줄에서 다른 목적으로도 사용되므로 모든 시나리오에서 사용 가능하지 않을 수 있다. 따라서 해당 도움말 정보에 접근하는 유일한 옵션이 되어서는 안 된다.

섬네일|VT100에 표시된 RT-11SJ의 명령어 출력 끝부분
프로그램의 내장 도움말에서 제공하는 것보다 더 상세한 도움말이 필요한 경우, 많은 시스템은 전용 외부 help 명령어 명령(또는 유사한 명령)을 지원한다. 이 명령은 명령어 이름을 호출 매개변수로 받아 외부 도움말 시스템을 호출한다.

DR-DOS 제품군에서는 명령어 자체 대신 COMMAND.COM 프롬프트에 /? 또는 /H를 입력하면 사용 가능한 내부 명령어의 동적으로 생성된 목록이 표시된다. 4DOS 및 NDOS는 프롬프트에 ?를 입력하여 동일한 기능을 지원한다.(이는 최신 버전의 DR-DOS COMMAND.COM에서도 허용됨) 내부 명령어는 SETDOS /I를 통해 개별적으로 비활성화하거나 다시 활성화할 수 있다. 이 외에도 일부 최신 버전의 DR-DOS COMMAND.COM은 사용 가능한 내장 의사 환경 변수 목록을 표시하기 위해 ?% 명령도 수락한다. 빠른 도움말 참조 목적 외에도 이는 배치 작업에서 기본 명령줄 프로세서의 기능을 쿼리하는 데 사용될 수 있다.

 명령어 설명 구문 
내장 사용법 도움말과 매뉴얼 페이지는 일반적으로 유효한 명령어 형식을 설명하기 위해 작은 구문을 사용한다:

 각괄호(꺽쇠괄호)는 필수 매개변수를 나타냄: ping <호스트명>
 대괄호는 선택적 매개변수를 나타냄: mkdir [-p] <디렉토리명>
 줄임표는 반복되는 항목을 나타냄: cp <원본1> [원본2…] <대상>
 수직선은 항목 중 선택을 나타냄: netstat {-t|-u}

이러한 문자는 셸에서 직접 사용될 때와는 다른 의미를 가짐에 유의하라. 매개변수 이름을 리터럴 문자열과 혼동할 가능성이 없는 경우 각괄호는 생략될 수 있다.

 공백 문자 
컴퓨팅의 많은 분야에서, 특히 명령줄에서 공백 문자는 두 가지 뚜렷하고 호환되지 않는 기능을 가지기 때문에 문제를 일으킬 수 있다. 즉, 명령어 또는 매개변수의 일부로서의 기능과, 매개변수 또는 이름 구분 기호로서의 기능이다. 모호함은 파일 및 디렉토리 이름에 처음부터 포함된 공백을 금지하거나(예: 밑줄 _로 대체), 포함된 공백이 있는 이름을 따옴표 문자로 묶거나 공백 앞에 이스케이프 문자(보통 역슬래시 \)를 사용하여 방지할 수 있다. 예를 들어:
Long path/Long program name 매개변수 하나 매개변수 둘 …
은 모호하다(program name이 프로그램 이름의 일부인지, 아니면 두 개의 매개변수인지?). 그러나:
Long_path/Long_program_name 매개변수_하나 매개변수_둘 …,
LongPath/LongProgramName 매개변수하나 매개변수둘 …,
"Long path/Long program name" "매개변수 하나" "매개변수 둘" …
그리고
Long\ path/Long\ program\ name 매개변수\ 하나 매개변수\ 둘 …
은 모호하지 않다. 유닉스 기반 운영체제는 따옴표의 필요성을 최소화하기 위해 포함된 공백의 사용을 최소화한다. 마이크로소프트 윈도우에서는 (디렉토리 이름 등에) 포함된 공백이 흔하기 때문에 종종 따옴표를 사용해야 한다.

 명령줄 인터프리터 

명령줄 인터프리터라는 용어는 사용자가 입력하거나 파일 또는 다른 종류의 데이터 스트림에서 읽은 일련의 텍스트 줄을 해석하도록 설계된 컴퓨터 프로그램에 적용된다. 해석의 맥락은 대개 주어진 운영체제나 프로그래밍 언어 중 하나이다.

명령줄 인터프리터는 사용자가 매우 효율적이고 (종종 간결한) 방식으로 다양한 명령을 내릴 수 있게 해준다. 이를 위해 사용자는 명령어의 이름과 매개변수, 그리고 해석되는 언어의 구문을 알고 있어야 한다.

유닉스의 #! 메커니즘과 OS/2의 EXTPROC 명령은 배치 파일을 외부 프로세서에 전달하는 것을 용이하게 한다. 이러한 메커니즘을 사용하여 전용 용도를 위한 특정 명령 프로세서를 작성하고 배치 파일에 상주하는 외부 데이터 파일을 처리할 수 있다.

OS/2 프레젠테이션 매니저 및 초기 마이크로소프트 윈도우 버전과 같은 많은 그래픽 인터페이스는 명령줄을 사용하여 문서와 프로그램을 열기 위한 도우미 프로그램을 호출한다. 명령어는 그래픽 셸이나 레지스트리 또는 OS/2 OS2USER.INI 파일과 같은 파일에 저장된다.

 초기 역사 
섬네일|천공 테이프 판독기와 펀치가 장착된 텔레타입 모델 33 ASR 전신타자기 키보드
섬네일|디지털 이큅먼트 코퍼레이션(DEC) VT52 단말기
초기 컴퓨터는 대화형 입출력 장치를 지원하지 않았으며, 종종 컴퓨터 운영자와 통신하기 위해 센스 스위치와 조명에 의존했다. 이는 프로그래머가 운영자 역할을 수행하며 한 번에 하나의 프로그램을 실행하는 일괄 처리 시스템에 적합했다. 또한 조명과 스위치는 하나의 기계어 명령으로 테스트하고 설정할 수 있었기 때문에 오버헤드가 낮다는 장점도 있었다. 나중에 운영자가 시스템과 통신할 수 있도록 단일 시스템 콘솔이 추가되었다.

1960년대부터 컴퓨터와 사용자의 상호작용은 주로 명령줄 인터페이스에 의해 이루어졌으며, 초기에는 텔레타입 모델 33 ASR과 같은 기기에서, 그 후에는 VT52와 같은 초기 브라운관(CRT) 기반 단말기에서 이루어졌다.

이러한 모든 장치는 그래픽이나 사진을 표시할 수 있는 능력이 없는 순수 텍스트 기반이었다. 비즈니스 응용 프로그램의 경우 텍스트 기반 메뉴가 사용되었지만, 보다 일반적인 상호작용을 위해서는 명령줄이 인터페이스였다.

1964년경 루이 푸진은 호환 시분할 시스템(CTSS)의 초기 시스템을 기반으로 멀틱스에 셸이라는 개념과 이름을 도입했다.

1970년대 초부터 유닉스 운영체제는 강력한 명령줄 환경의 개념을 채택했고, 한 명령의 출력을 다른 명령의 입력으로 연결하는 파이프 기능을 도입했다. 유닉스는 또한 일련의 명령어들을 사용자 정의 명령어처럼 작동하는 셸 스크립트로 저장하고 다시 실행할 수 있는 기능을 가졌다.

명령줄은 또한 코모도어 PET, 애플 II 및 BBC 마이크로와 같은 초기 홈 컴퓨터의 주요 인터페이스이기도 했다. 거의 항상 베이직 인터프리터 형태였다. CP/M과 이후 도스 컴퓨터(예: IBM PC)와 같은 더 강력한 비즈니스 지향 마이크로컴퓨터가 등장했을 때, 명령줄은 글로빙이나 출력 파이프와 같은 유닉스 셸의 구문과 기능을 차용하기 시작했다.

명령줄은 1983년 애플 리사와 1984년 애플 매킨토시에서 사용된 PARC GUI 접근 방식에 의해 처음으로 심각하게 도전받았다. 몇몇 컴퓨터 사용자들은 GEOS나 윈도우 3.1과 같은 GUI를 사용했지만, 대다수의 IBM PC 사용자들은 1995년 윈도우 95가 출시될 때까지 COMMAND.COM 셸을 GUI로 교체하지 않았다.

 현대의 운영체제 셸로서의 사용 
대부분의 비전문가 컴퓨터 사용자는 이제 거의 독점적으로 GUI를 사용하지만, 고급 사용자들은 강력한 명령줄 환경을 이용할 수 있다:

 유닉스 계열 시스템에는 본 셸과 배시와 같은 호환 셸 및 기타 유닉스 셸들이 포함된다.
 FreeBSD는 슈퍼유저를 위한 기본 대화형 셸로 tcsh를 사용하며, 기본 스크립팅 셸로는 ash를 사용한다.
 많은 리눅스 배포판은 배시를 가지고 있다.
 애플 MacOS와 일부 리눅스 배포판은 zsh를 사용한다. 이전에는 MacOS가 tcsh와 배시를 사용했다.
 임베디드 리눅스(및 기타 임베디드 유닉스 계열) 시스템은 종종 Busybox의 일부인 ash를 사용한다.
 안드로이드는 mksh 셸을 사용하며, 이는 이전 안드로이드 버전에서 사용되었던 ash 파생 셸을 대체하고 별도의 toolbox 바이너리 명령으로 보완된다.
 OpenVMS는 DIGITAL 명령 언어(DCL)를 사용한다.
 유닉스 명령 셸들이 OpenVMS로 포팅되었다.
 도스와 윈도우는 여러 명령줄 환경을 가지고 있다.
 COMMAND.COM은 MS-DOS, IBM PC DOS, 윈도우 9x 및 DR-DOS, SISNE plus, PTS-DOS, ROM-DOS, 프리도스와 같은 클론들의 명령줄 인터프리터이다.
 윈도우 NT는 Cmd.exe를 가지고 있으며, 이후 버전은 파워셸을 가지고 있다.
 윈도우 리소스 킷 및 윈도우 서비스 포 유닉스에는 펄 인터프리터와 함께 콘 셸 및 본 셸이 포함되어 있다.
 윈도우 사용자는 명령줄에서 대체 프로그램을 위해 CScript 인터페이스를 사용할 수 있다. 유닉스 셸의 구현은 POSIX 하위 시스템, 시그윈, MKS Toolkit, UWIN, Hamilton C shell 및 기타 소프트웨어 패키지의 일부로도 제공된다. 이러한 상호운용성 도구에서 사용 가능한 셸에는 csh, ksh, sh, 배시, rsh, tclsh 및 덜 일반적인 zsh, psh가 포함된다.
 DCL은 PC-DCL 및 Acceler8 DCL Lite를 포함하여 윈도우 시스템으로 적어도 세 번 포팅되었다.
 또 다른 cmd.exe는 윈도우 CE 3.0용으로 축소된 셸이다.
 PocketDOS라는 MS-DOS 유형의 인터프리터가 윈도우 CE 기기로 포팅되었다. 최신 릴리스는 MS-DOS 6.22와 거의 동일하며 윈도우 1, 2, 3.0, 큐베이직 및 기타 개발 도구, 4NT 및 4DOS를 실행할 수 있다. 최신 릴리스에는 MS-DOS 6.22, PC DOS 7, DR DOS 3.xx 등 여러 셸이 포함되어 있다.
 IBM OS/2(및 EComStation, ArcaOS와 같은 파생 제품)는 Cmd.exe 프로세서를 가지고 있다. 이는 REXX로의 확장을 포함하여 COMMAND.COM 명령을 복제한다.
 PHP 구현체는 대화형 사용을 위해 php-cli라는 셸을 가지고 있다.
 표준 Tcl/Tk는 두 개의 대화형 셸인 Tclsh와 Wish를 가지고 있으며, 후자는 GUI 버전이다.
 파이썬, 루비, 루아, XLNT 및 기타 인터프리터들도 대화형 사용을 위한 명령 셸을 가지고 있다.
 HarmonyOS, 오픈하모니 및 Oniro는 musl-libc 라이브러리와 훙멍 커널의 리눅스 ABI가 포함된 KAL 하위 시스템의 리눅스 커널에 부착된 제3자 toybox 호환성 시스템의 명령어를 기본 셸과 함께 사용한다.
 시스코 IOS를 사용하는 라우터, Junos 및 기타 많은 장치들이 일반적으로 명령줄에서 구성된다.
 플랜 9 운영체제는 본 셸과 설계가 유사한 rc 셸을 사용한다.

 스크립팅 
대부분의 명령줄 인터프리터는 다양한 정도로 스크립팅을 지원한다. 그들은 결국 해석된 프로그래밍 언어의 인터프리터이며, 많은 경우 해당 언어는 특정 명령줄 인터프리터에 고유하다. 그들은 자신이 해석하는 언어로 작성된, 셸 스크립트 또는 배치 파일로 불리는 스크립트를 해석한다. 일부 명령줄 인터프리터는 자체 엔진 외에도 REXX와 같은 다른 언어의 인터프리터 엔진을 통합하여 해당 언어로 된 스크립트를 명령줄 인터프리터 자체 내에서 직접 실행할 수 있게 한다.

반대로, 특히 Eval 함수를 가진 스크립트 언어(REXX, 펄, 파이썬, 루비 또는 자이썬 등)는 명령줄 인터프리터 및 필터를 구현하는 데 사용될 수 있다. 도스와 같은 일부 운영체제의 경우, 이러한 명령 인터프리터는 제공된 것보다 더 유연한 명령줄 인터페이스를 제공한다. 다른 경우에 이러한 명령 인터프리터는 해당 언어의 사용자 인터페이스 및 입출력 기능을 사용하는 고도로 사용자 정의된 사용자 인터페이스를 제시할 수 있다.

 기타 명령줄 인터페이스 
명령줄은 사용자뿐만 아니라 프로그램 간의 인터페이스도 제공한다. 이런 의미에서 명령줄은 대화 상자의 대안이다. 편집기와 데이터베이스는 대체 명령 프로세서가 실행될 수 있는 명령줄을 제시한다. 반면에 명령줄에 대화 상자를 여는 옵션을 가질 수도 있다. 'Take Command'의 최신 버전에는 이 기능이 있다. DBase는 명령줄을 구성하기 위해 대화 상자를 사용했으며, 사용 전에 추가로 편집할 수 있었다.

베이직, Diskpart, Edlin, 큐베이직과 같은 프로그램들은 모두 시스템 셸을 사용하는 명령줄 인터페이스를 제공한다. 베이직은 8비트 인텔 컴퓨터의 기본 인터페이스를 모델로 했다. 계산기는 명령줄 또는 대화형 인터페이스로 실행될 수 있다.

이맥스는 미니버퍼 형태로 명령줄 인터페이스를 제공한다. 명령어와 인수는 이맥스 표준 텍스트 편집 지원을 사용하여 입력할 수 있으며, 출력은 다른 버퍼에 표시된다.

어드벤처나 킹스 퀘스트 1-3과 같이 화면 하단에 명령어를 입력하는 방식에 의존하는 텍스트 모드 게임들이 많이 있다. 사용자는 'get ring' 또는 'look'과 같은 명령어를 입력하여 캐릭터를 제어한다. 프로그램은 캐릭터가 보는 방식을 설명하거나 행동이 일어나게 하는 텍스트를 반환한다. 더글러스 애덤스의 동명 소설을 기반으로 한 인터랙티브 픽션인 은하수를 여행하는 히치하이커를 위한 안내서는 텔레타입 스타일의 명령줄 게임이다.

이러한 인터페이스 중 가장 주목할 만한 것은 표준 스트림 인터페이스로, 한 명령의 출력이 다른 명령의 입력으로 전달될 수 있게 한다. 텍스트 파일도 두 가지 목적을 모두 수행할 수 있다. 이는 파이핑, 필터 및 리다이렉션 인터페이스를 제공한다. 유닉스에서 모든 것은 파일이므로, stdin, stdout, stderr에 사용되는 셸의 일반적인 파일 유형은 tty 장치 파일이다.

또 다른 명령줄 인터페이스는 셸 프로그램이 문서를 실행하거나 프로그램을 시작하기 위해 도우미 프로그램을 실행할 수 있게 한다. 명령은 셸 내부에서 처리된 다음 문서를 실행하기 위해 다른 프로그램으로 전달된다. 윈도우와 OS/2의 그래픽 인터페이스는 다른 프로그램(콘솔 또는 그래픽 프로그램)으로 전달되는 명령줄에 크게 의존하며, 해당 프로그램들은 대개 사용자 콘솔을 제시하지 않고 명령줄을 처리한다.

OS/2 E 편집기 및 일부 다른 IBM 문서 편집기와 같은 프로그램은 일반적으로 셸을 위한 명령줄을 처리할 수 있으며, 그 출력은 문서 창에 직접 배치된다.

웹 브라우저의 URL 입력 필드는 명령줄로 사용될 수 있다. 이는 웹 애플리케이션을 실행하거나, 브라우저 설정에 접근하거나, 검색을 수행하는 데 사용될 수 있다. "인터넷의 명령줄"이라 불려온 구글은 알려진 형식의 검색 매개변수를 감지하면 도메인 특정 검색을 수행한다. 이 기능은 브라우저 필드에서 검색이 트리거되든 구글 웹사이트에서 트리거되든 상관없이 작동한다.

독립 실행형 웹 앱이나 더 큰 애플리케이션의 일부로 브라우저에서 명령줄 애플리케이션을 작성할 수 있게 해주는 자바스크립트 라이브러리가 있다. 그러한 웹사이트의 예로 덕덕고의 CLI 인터페이스가 있다. 브라우저에서 서버의 명령줄 인터페이스에 접근할 수 있게 해주는 웹 기반 SSH 애플리케이션도 있다.

많은 PC 비디오 게임은 종종 콘솔이라고 불리는 명령줄 인터페이스를 갖추고 있다. 이는 일반적으로 개발 중에 게임 개발자가 사용하거나, 디버깅 목적 및 게임의 일부를 건너뛰거나 치트를 사용하기 위해 모드 개발자가 사용한다.

 같이 보기 
 명령어
 그래픽 사용자 인터페이스(GUI)
 텍스트 사용자 인터페이스
 마이크로소프트 파워셸(MSH)
 Bash (리눅스의 기본 셸)

 각주 

 내용주

 외부 링크 

 Linux Command Line — 유닉스 셸 명령어 모음.
 Coming Soon to Windows: The Microsoft Shell (MSH) by Jason Nadal - 마이크로소프트 파워셸에 대한 설명.
 "GetPot. 객체 지향 명령줄 파싱." C++, Python, Java, Ruby 등에서 사용 가능한 라이브러리.

 
분류:소프트웨어 구조
분류:사용자 인터페이스 기술
분류:사용자 인터페이스