Command-line interface

명령줄 인터페이스 (command-line interface, 줄여서 CLI)는 텍스트 줄 형식으로 컴퓨터 프로그램에 대한 명령을 처리합니다. 인터페이스를 처리하는 그 프로그램은 명령-줄 해석기(command-line interpreter) 또는 명령-줄 처리기(command-line processor)라고 불립니다. 운영 시스템은 운영 시스템 기능 또는 서비스로의 대화식 접근을 위해 쉘에서 명령-줄 인터페이스를 구현합니다. 그러한 접근은 1960년대 중반부터 컴퓨터 터미널에 의해 주로 사용자에게 제공되었고, VAX/VMS, 유닉스 시스템 및 DOS, CP/M 및 Apple DOS를 포함한 개인용 컴퓨터 시스템에서 1970년대와 1980년대 내내 계속 사용되었습니다.

오늘날, 많은 사용자가 그래픽 사용자 인터페이스와 메뉴-기반 상호 작용에 의존합니다. 어쨌든, 일부 프로그래밍과 유지 관리 임무는 그래픽 사용자 인터페이스를 가질 수 있고 여전히 명령-줄을 사용할 수 있습니다.

명령행 인터페이스에 대한 대안으로는 텍스트-기반 사용자 인터페이스 메뉴 (예를 들어, IBM AIX SMIT), 키보드 단축키, 및 포인터를 중심으로 하는 다양한 데스크탑 메타포 (보통 마우스로 제어)를 포함합니다. 이러한 예제는 Microsoft Windows, DOS Shell, 및 Mouse Systems PowerPanel을 포함합니다. 명령-줄 인터페이스는 종종 커서 주소 지정을 디스플레이 화면에 기호를 배치하기 위해 사용하는 화면-지향 텍스트-기반 사용자 인터페이스가 가능한 터미널 장치에서 구현됩니다.

명령줄 인터페이스를 갖는 프로그램은 일반적으로 스크립팅을 통해 자동화하기가 더 쉽습니다.

많은 소프트웨어 시스템은 제어와 작동을 위한 명령-줄 인터페이스를 구현합니다. 여기에는 프로그래밍 환경과 유틸리티 프로그램을 포함합니다.

Comparison to graphical user interfaces

그래픽 사용자 인터페이스와 비교하여, 명령-줄 인터페이스는 구현하기 위해 더 적은 시스템 자원을 요구합니다. 명령에 대한 옵션은 각 명령줄에서 몇 글자로 제공되므로, 숙련된 사용자는 종종 옵션에 더 쉽게 접근할 수 있습니다. 반복 임무의 자동화는 자주 사용하는 시퀀스를 저장하기 위한 줄 편집과 역사 메커니즘에 의해 단순화됩니다; 이것은 매개변수와 변수 옵션을 취할 수 있는 스크립팅 언어로 확장될 수 있습니다. 명령-줄 역사는 유지되며, 명령을 검토하거나 반복할 수 있습니다.

명령-줄 시스템은 비록 종종 "도움말" 옵션이 명령 옵션의 간략한 검토를 제공할지라도 사용자 참조에 대해 종이나 온라인 설명서를 요구할 수 있습니다. 명령-줄 환경은 GUI에서 볼 수 있는 다른 글꼴이나 확장된 편집 창과 같은 향상된 그래픽 기능을 제공하지 않을 수 있습니다. 새로운 사용자는 설명서를 반복적으로 참조하지 않고 그래픽 사용자 인터페이스의 아이콘과 드롭다운 메뉴와 비교하여 사용 가능한 모든 명령과 옵션에 익숙해지기 어려울 수 있습니다.

Types

Operating system command-line interfaces

운영 시스템 (OS) 명령-줄 인터페이스는 보통 운영 시스템과 함께 제공되는 별개의 프로그램입니다. 그러한 텍스트 인터페이스를 구현하는 프로그램은 종종 명령-줄 해석기, 명령 처리기 또는 쉘이라고 불립니다.

명령-줄 해석기의 예로는 OpenVMS와 RSX-11의 DEC의 디지털 명령 언어 (DCL), 다양한 유닉스 쉘 (sh, ksh, csh, tcsh, zsh, Bash, 등), CP/M의 CCP, DOS의 COMMAND.COM과 마찬가지로 OS/2와 Windows CMD.EXE 프로그램을 포함하며, 후자의 그룹은 DEC의 RSX-11과 RSTS CLI에 크게 기반합니다. 대부분의 운영 시스템 아래에서, 기본 쉘 프로그램을 대안적인 프로그램으로 교체할 수 있습니다; 예로는 DOS에 대해 4DOS, OS/2에 대해 4OS2, 및 Windows에 대해 4NT / Take Command를 포함합니다.

비록 '쉘'이라는 용어가 종종 명령-줄 해석기를 설명하기 위해 사용될지라도, 엄밀하게 말하면, '쉘'은 완전하게 그래픽 지향적인 프로그램을 포함하여 사용자-인터페이스를 구성하는 임의의 프로그램이 될 수 있습니다. 예를 들어, 기본 Windows GUI는 WIN.INI 구성 파일에서 SHELL=EXPLORER.EXE 행에 정의된 대로 EXPLORER.EXE라는 쉘 프로그램입니다. 이들 프로그램은 쉘이지만, CLI는 아닙니다.

Application command-line interfaces

응용 프로그램 (운영 시스템과 반대)에도 명령-줄 인터페이스를 가질 수 있습니다.

응용 프로그램은 다음 세 가지 주요 유형의 명령-줄 인터페이스 메커니즘을 전혀 지원하지 않거나, 일부 또는 모두 지원할 수 있습니다:

• 매개변수: 대부분의 운영 시스템은 프로그램이 시작될 때 프로그램에 추가 정보를 전달하는 수단을 지원합니다. 프로그램이 OS 명령-줄 쉘에서 시작되면, 프로그램 이름과 함께 제공된 추가 텍스트가 시작된 프로그램에 전달됩니다.
• 대화형 명령-줄 세션: 실행 후 프로그램은 운영자에게 텍스트 형식으로 명령을 입력할 수 있는 독립적인 수단을 제공할 수 있습니다.
• 프로세서-사이 통신: 대부분의 운영 시스템은 프로세스-사이 통신 수단 (예를 들어, 표준 스트림 또는 이름-지어진 파이프)을 지원합니다. 클라이언트 프로세스로부터 명령줄은 이들 방법 중 하나에 의해 CLI 프로그램으로 리다이렉션될 수 있습니다.

일부 응용 프로그램은 CLI만 지원하여, 사용자에게 CLI 프롬프트를 표시하고 명령이 입력될 때 명령줄에 따라 작동합니다. 다른 프로그램은 CLI와 GUI를 모두 지원합니다. 경우에 따라, GUI는 별도의 CLI 실행 파일을 둘러싼 단순한 래퍼입니다. 다른 경우에서, 프로그램은 GUI에 대한 선택적 대안으로 CLI를 제공할 수 있습니다. CLI와 GUI는 종종 다른 기능성을 지원합니다. 예를 들어, 수치 해석 컴퓨터 프로그램, MATLAB의 모든 기능은 CLI를 통해 사용할 수 있지만 MATLAB GUI는 기능의 하위 집합만 표시합니다.

처음 세 개의 King's Quest 게임 (1984–1986)과 같은 초기 Sierra 게임은 내부 명령-줄의 명령을 사용하여 그래픽 창에서 캐릭터를 이동했습니다.

History

명령-줄 인터페이스는 한때 사람에 의해 텔레프린터(teleprinter) (TTY) 기계에 걸쳐 수행했던 대화의 형식에서 발전했으며, 여기에서 사람은 원격으로 보통 한 번에 한 줄의 텍스트로 정보를 교환했습니다. 초기 컴퓨터 시스템은 종종 사람 운용자와의 상호 작용 수단으로 텔레프린터 기계를 사용했습니다. 그 컴퓨터는 인간-대-인간 텔레프린터 모델의 한쪽 끝이 되었습니다. 그래서 사람이 텔레프린터에 걸쳐 또 다른 사람과 의사 소통하는 대신, 컴퓨터와 통신했습니다.

기계식 텔레프린터는 텔레프린터를 모방한 키보드와 화면, "유리 tty"에 의해 대체되었습니다. "스마트" 터미널은 전체 화면에 걸쳐 커서를 이동하거나, 컴퓨터로 전송하기 위해 터미널에서 데이터를 로컬로 편집하는 것과 같은 추가 기능을 허용했습니다. 마이크로컴퓨터 혁명이 전통적인 – 미니컴퓨터 + 터미널 – 시간 공유 아키텍처를 대체함에 따라, 하드웨어 터미널은 터미널 에뮬레이터에 의해 대체되었습니다 – 터미널 에뮬레이터는 PC의 직렬 포트를 통해 전송된 터미널 신호를 해석하는 PC 소프트웨어입니다. 이것들은 전형적으로 조직의 새 PC를 기존 미니- 또는 메인프레임 컴퓨터와 인터페이스하거나, PC를 PC에 연결하기 위해 사용되었습니다. 이들 PC 중 일부는 게시판 시스템 소프트웨어를 실행하고 있었습니다.

초기 운영 시스템 CLI는 상주 모니터 프로그램의 일부로 구현되었고, 쉽게 교체될 수 없었습니다. 교체 가능한 구성 요소로 쉘의 첫 번째 구현은 Multics 시분할 운영 시스템의 일부였습니다. 1964년에, MIT Computation Center 직원 Louis Pouzin은 인수 치환을 허용하면서 명령 스크립트를 실행하기 위한 RUNCOM 도구를 개발했습니다. Pouzin은 프로그래밍 언어와 같은 명령을 사용하는 기술을 설명하기 위해 "쉘"이라는 용어를 만들었고, Multics 운영 시스템에서 그 아이디어를 구현하는 방법에 대한 논문을 작성했습니다. Pouzin은 1965년에 그의 모국인 프랑스로 돌아왔고, Glenda Schroeder에 의해 최초의 Multics 쉘이 개발되었습니다.

최초의 유닉스 쉘, V6 쉘은 1971년 벨 연구소에서 Ken Thompson에 의해 개발되었고 Schroeder의 Multics 쉘을 모델로 했습니다. 본 쉘은 1977년 V6 쉘의 대체품으로 도입되었습니다. 비록 그것이 대화형 명령 해석기로 사용되었지만, 그것은 역시 스크립팅 언어로 사용되었고 공통적으로 구조화된 프로그램을 생성하는 것으로 여겨지는 대부분의 기능을 포함하고 있습니다. 본 쉘은 KornShell (ksh), Almquist shell (ash), 및 인기 있는 Bourne-again shell (or Bash)의 개발로 이어졌습니다.

초기 마이크로컴퓨터 자체는 CP/M, DOS, 또는 AppleSoft BASIC과 같은 명령줄 해석기를 기반으로 했습니다. 1980년대와 1990년대에, PC에 Apple Macintosh와 Microsoft Windows가 도입되면서 명령=줄 인터페이스가 그래픽 사용자 인터페이스로 대체된 기본 사용자 인터페이스로 여겨지게 되었습니다. 명령줄은 시스템 관리, 컴퓨터 프로그래밍, 및 일괄 처리를 위해 시스템 관리자와 기타 고급 사용자에 의해 자주 사용되는 대안적인 사용자 인터페이스로 계속 사용 가능했습니다.

2006년 11월에, Microsoft는 기존 유닉스 쉘의 기능과 독점 개체 지향 .NET Framework를 결합한 Windows PowerShell (이전 코드명 Monad) 버전 1.0을 출시했습니다. MinGW과 Cygwin은 유닉스-계열 CLI를 제공하는 Windows에 대한 오픈-소스 패키지입니다. Microsoft는 Services for UNIX 에드-온을 통해 Windows에 대해 MKS Inc.의 ksh 구현 MKS Korn 쉘을 제공합니다.

2001년부터, 매킨토시 운영 시스템 macOS는 Darwin이라는 유닉스-계열 운영 시스템을 기반으로 하고 있습니다. 이들 컴퓨터에서, 사용자는 응용 프로그램 폴더의 유틸리티 하위 폴더에 있는 Terminal이라고 하는 터미널 에뮬레이터 프로그램을 실행하거나 ssh를 사용하여 컴퓨터에 원격으로 로그인하여 유닉스-계열 명령-줄 인터페이스에 접근할 수 있습니다. Z 쉘은 macOS에 대한 기본 쉘입니다; Bash, tcsh, 및 KornShell도 제공됩니다. macOS Catalina 이전에는, Bash가 기본값이었습니다.

Usage

CLI는 광범위한 (또는 임의적인) 옵션과 결합된 명령 또는 질의의 방대한 어휘를 순수 GUI보다 텍스트로 더 빠르게 입력할 수 있을 때마다 사용됩니다. 이것은 전형적으로 운영 시스템 명령 쉘의 사례입니다. CLI는 역시 그래픽 사용자 인터페이스를 지원하기에 충분하지 않은 자원을 갖는 시스템에 의해 사용됩니다. 일부 컴퓨터 언어 시스템 (예를 들어, Python, Forth, LISP, Rexx, 및 BASIC의 여러 통용어)은 코드의 신속한 평가를 허용하는 대화식 명령-줄 모드를 제공합니다.

CLI는 종종 공학과 과학 환경에서 프로그래머와 시스템 관리자에 의해, 및 기술적으로 고급 개인용 컴퓨터 사용자에 의해 사용됩니다. CLI는 새로 고칠 수 있는 점자 디스플레이를 사용하여 명령과 응답을 표시할 수 있기 때문에 시각 장애를 갖는 사람들에게도 인기가 있습니다.

Anatomy of a shell CLI

OS 명령-줄 인터페이스의 일반적인 패턴은 다음과 같습니다:

Prompt command param1 param2 param3 … paramN

• Prompt — 클라이언트에 컨텍스트를 제공하기 위해 프로그램에 의해 생성됩니다.
• Command — 클라이언트에 의해 제공됩니다. 명령은 보통 다음 세 가지 클래스 중 하나입니다:
  1. 내부(Internal) 명령은 명령-줄 해석기 자체에 의해 인식되고 처리되고 외부 실행 파일에 의존하지 않습니다.
  2. 포함된(Included) 명령은 일반적으로 운영 환경의 일부로 고려되고 항상 OS에 포함된 별도의 실행 파일을 실행합니다.
  3. 외부(External) 명령은 기본 OS의 일부가 아니지만, 특정 목적과 응용 프로그램을 위해 다른 것에 의해 더해진 실행 파일을 실행합니다.
• param1 …paramN — 클라이언트에 의해 제공되는 선택적 매개변수입니다. 매개변수의 형식과 의미는 실행된 명령에 따라 다릅니다. 포함된 또는 외부 명령의 경우에서, 매개변수의 값은 OS에 의해 실행될 때 프로그램 (명령에 의해 지정됨)에 전달됩니다. 매개변수는 인수 또는 옵션일 수 있습니다.

이 예제에서, 명령줄 요소 사이의 구분 기호는 공백 문자이고 줄 끝 구분 기호는 줄바꿈 구분 기호입니다. 이것은 명령줄 인터페이스에 대해 널리 사용되는 (공통적인 것은 아님) 규칙입니다.

CLI는 일반적으로 구문과 의미 체계로 구성된 것으로 여겨질 수 있습니다. 구문은 모든 명령이 따라야 하는 문법입니다. 운영 시스템의 경우에서, DOS와 유닉스는 각각 모든 명령이 따라야 하는 자체의 규칙의 집합을 정의합니다. 임베디드 시스템의 경우에서, Nortel, Juniper Networks 또는 Cisco Systems와 같은 각 공급업체는 그들의 CLI 내의 모든 명령이 준수하는 자체의 독점적인 규칙의 집합을 정의합니다. 이들 규칙은 역시 사용자가 명령 시스템을 탐색하는 방법을 지정합니다. 의미 체계는 어떤 종류의 연산이 가능한지, 어떤 종류의 데이터에서 이러한 연산을 수행할 수 있는지, 및 문법이 이들 연산과 데이터를 나타내는 방법 (구문에서 상징적 의미)을 정의합니다.

두 개의 서로 다른 CLI가 구문 또는 의미 체계에 동의할 수 있지만, 그것들은 사용자가 아무것도 배우지 않고도 두 CLI를 모두 사용할 수 있고 스크립트를 재사용할 수 있도록 두 CLI가 충분히 유사하다고 여겨질 수 있는 경우에만 두 가지 모두에 동의합니다.

간단한 CLI는 프롬프트를 표시하고, Enter 키에 의해 종료된 사용자에 의해 입력된 "명령 줄"을 수락하고, 그런-다음 지정된 명령을 실행하고 결과 또는 오류 메시지의 텍스트 표시를 제공합니다. 고급 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 and resource protection

우리는 PATH 환경 변수에 나타나는 경로를 수정함으로써 사용 가능한 명령의 집합을 수정할 수 있습니다. 유닉스 아래에서, 명령은 역시 실행-가능한 파일로 표시되어야 합니다. 경로 변수에서 디렉토리는 그것들이 지정된 순서대로 검색됩니다. 경로를 재정렬하면, 우리는 기본값이 반대일 때 예를 들어 \OS2\E.EXE 대신 \OS2\MDOS\E.EXE를 실행할 수 있습니다. 실행 파일의 이름을 바꾸는 것도 동작합니다: 예를 들어 사람들은 종종 좋아하는 편집기의 이름을 EDIT로 바꿉니다.

명령줄은 고급 내부 명령에 대한 접근과 같이 사용 가능한 명령을 제한하는 것을 허용합니다. 윈도우 CMD.EXE가 이 작업을 수행합니다. 종종, 셰어웨어 프로그램은 프롬프트에서 '관리자가 배치 파일 실행을 비활성화했습니다'라는 명령을 인쇄하는 것을 포함하여 명령의 범위를 제한받을 것입니다.

네트워크 라우터에 있는 것과 같은 일부 CLI는 모드 계층 구조를 가지며, 각 모드에서 지원되는 다른 명령의 집합을 가집니다. 명령의 집합은 보안, 시스템, 인터페이스, 등과의 결합에 의해 그룹화됩니다. 이들 시스템에서, 사용자는 일련의 하위-모드를 횡단할 수 있습니다. 예를 들어, CLI에 인터페이스와 시스템이라는 두 가지 모드가 있으면, 사용자는 인터페이스 명령을 인터페이스 모드로 들어가기 위해 사용할 있습니다. 이 지점에서, 시스템 모드에서 명령은 사용자가 인터페이스 모드를 종료하고 시스템 모드로 들어갈 때까지 접근될 수 없습니다.

Command prompt

명령 프롬프트 (또는 그냥 프롬프트)는 명령을 수용할 준비가 되었음을 나타내기 위해 명령-줄 인터페이스에서 사용되는 (하나 이상의) 문자 시퀀스입니다. 그것은 말 그대로 사용자에게 행동을 취하라고 독촉하는 것(prompt)입니다. 프롬프트는 보통 $, %, #, :, > 또는 - 문자 중 하나로 끝나고 종종 현재 작업 디렉토리의 경로와 호스트이름과 같은 다른 정보를 포함합니다.

많은 유닉스와 파생 시스템에서, 프롬프트는 공통적으로 사용자가 일반 사용자이면 $ 또는 %로 끝나지만, 사용자가 수퍼유저 (유닉스 용어로 "root")이면 #으로 끝납니다.

최종-사용자는 종종 프롬프트를 수정할 수 있습니다. 환경에 따라, 그것들은 색상, 특수 문자, 및 기타 요소 (예를 들어, 현재 시간, 사용자, 쉘 번호 또는 작업 디렉토리에 대한 변수와 함수)를, 프롬프트를 보다 유익하거나 시각적으로 보기 좋게 만들기 위해, 다양한 시스템에서 세션을 구별하기 위해, 또는 명령 중첩의 현재 수준을 나타내기 위해, 포함할 수 있습니다. 일부 시스템에서, 프롬프트 정의에 있는 특수 토큰은 프롬프트를 표시하는 동안 명령줄 해석기에서 외부 프로그램을 호출하기 위해 사용될 수 있습니다.

DOS의 COMMAND.COM과 Windows NT의 cmd.exe에서, 사용자는 PROMPT 명령을 실행하거나 해당 %PROMPT% 환경 변수의 값을 직접 변경함으로써 프롬프트를 수정할 수 있습니다. 대부분의 최신 시스템의 기본값, C:\> 스타일은, 예를 들어, PROMPT $P$G로 획득됩니다. 오래된 DOS 시스템의 기본값, C>는 단지 PROMPT에 의해 획득되지만, 일부 시스템에서는 플로피 드라이브 A: 또는 B:에서 사용되지 않는 한 새로운 C:\> 스타일을 생성합니다; 그들 시스템에서는 PROMPT $N$G는 자동 기본값을 무시하고 명시적으로 이전 스타일로 전환하기 위해 사용될 수 있습니다.

많은 유닉스 시스템은 $PS1 변수 (Prompt String 1)의 특색을 이루지만, 다른 변수도 프롬프트에 영향을 미칠 수 있습니다 (사용된 쉘에 따라 다릅니다). Bash 쉘에서, 다음 형식의 프롬프트가:

[time] user@host: work_dir $

다음 명령을 실행하여 설정될 수 있습니다:

export PS1='[\t] \u@\H: \W $'

zsh에서 $RPROMPT 변수는 디스플레이 오른쪽의 선택적 "프롬프트"를 제어합니다. 그것은 텍스트 엔트리의 위치가 변경되지 않는다는 점에서 실제 프롬프트가 아닙니다. 그것은 프롬프트와 같은 줄에 정보를 표시하는 데 사용되지만 오른쪽 정렬됩니다.

RISC OS에서 명령 프롬프트는 * 기호이고, 따라서 (OS) CLI 명령은 종종 "스타 명령"으로 참조됩니다. 우리는 역시 명령 앞에 *를 붙임으로써 다른 명령줄 (BBC BASIC 명령줄 등)에서 같은 명령에 접근할 수도 있습니다.

Arguments

명령-줄 인수(command-line argument) 또는 매개변수는 프로그램이 시작될 때 그것에 제공되는 정보의 항목입니다. 프로그램은 정보의 출처 또는 대상을 식별하거나, 프로그램의 작동을 변경하는 많은 명령줄 인수를 가질 수 있습니다.

명령 프로세서가 활성화될 때, 프로그램은 전형적으로 그것의 이름 뒤에 (만약 있다면) 명령-줄 인수를 입력함으로써 호출됩니다. 예를 들어, 유닉스와 유닉스-계열 환경에서, 명령줄 인수의 예제는 다음과 같습니다:

rm file.s

"file.s"는 파일 "file.s"를 제거하기 위해 프로그램 rm에 지시하는 명령-줄 인수입니다.

C, C++, 및 Java와 같은 일부 프로그래밍 언어는 프로그램에게 주요 함수에서 문자열 매개변수로 처리함으로써 명령줄 인수를 해석하는 것을 허용합니다. Python과 같은 다른 언어는 sys 모듈, 특히 "명령줄 인수"에 대한 sys.argv를 통해 운영 시스템-별 API (기능성)를 노출합니다.

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

Command-line option

명령-줄 옵션(command-line option) 또는 단순히 옵션 (역시 플래그 또는 스위치로 알려져 있음)은 명령의 작업을 수정합니다; 그 효과는 명령의 프로그램에 의해 결정됩니다. 옵션은 명령줄에서 공백으로 구분하여 명령 이름을 따릅니다. 첫 번째 옵션 앞에 공백이 항상 필요한 것은 아닙니다. 예를 들어, DOS에서 Dir/?과 DIR /?는 DIR 명령의 사용 가능한 옵션을 나열하는 것과 같은 효과를 가지고, 반면에 dir --help (많은 유닉스 버전에서)는 옵션 앞에 최소한 하나의 공백이 있어야 합니다 (그리고 대소문자를 구분합니다).

옵션의 형식은 운영 시스템마다 크게 다릅니다. 대부분의 경우에서, 구문은 운영 시스템 요구 사항이 아니라 관례에 따릅니다; 전체 명령줄은 단순히 프로그램에 전달된 문자열이며, 해석기가 명령 이름이 끝나고 그것의 인수와 옵션이 시작되는 위치를 알 수 있는 한 프로그래머가 원하는 임의의 방법으로 프로그램을 처리할 수 있습니다.

몇 가지 관례를 설명하기 위해, 디렉토리에서 파일 나열과 관련된 명령줄 옵션의 몇 가지 대표적인 예시:

Operating system	Command	Valid alternative	Notes
OpenVMS	directory/owner	Dir /Owner	디렉토리 명령에 파일의 소유권도 표시하도록 지시합니다. 디렉토리 명령 이름은 대소문자를 구분하지 않고, 고유한 상태를 유지하기 위해 필요한 만큼의 문자로 축약될 수 있음을 주목하십시오.
Windows	DIR/Q/O:S d*	dir /q d* /o:s	이름이 "D"로 시작하는 파일의 소유권을 표시하고, 크기별로 정렬되고 작은 것부터 표시됩니다. 인수 d* 주위에 공백이 필요함을 주목하십시오.
Unix-like systems	ls -lS D*	ls -S -l D*	"D" ("d"가 아님)로 시작하는 긴 형식의 파일과 디렉토리를 크기별로 (가장 큰 것부터) 정렬하여 표시합니다. 공백은 모든 인수와 옵션 주위에 필요하지만, 일부는 함께 실행될 수 있음을 주목하십시오, 예를 들어, -lS는 -l -S와 같습니다.
Data General RDOS CLI	list/e/s 04-26-80/b	List /S/E 4-26-80/B	1980년 4월 26일 이전에 생성된 파일에 대해 모든 속성을 나열합니다. 날짜 인수 끝에 있는 /B는 해당 인수의 의미를 수정하는 지역 스위치이고, 반면에 /S 및 /E는 전체 명령에 적용되는 전역 스위치임을 주목하십시오.

 

Abbreviating commands

Multics에서, 명령-줄 옵션과 하위시스템 키워드는 약어로 표시될 수 있습니다. 이 아이디어는 단축된 키워드(예를 들어, STRINGRANGE에 대해 STRG, DECLARE에 대해 DCL)를 갖는 PL/I 프로그래밍 언어에서 파생된 것으로 보입니다. 예를 들어, Multics "포럼" 하위시스템에서, -long_subject 매개변수는 -lgsj로 축약될 수 있습니다. 역시 Multics 명령에 대해 축약되는 것이 공통적이고, 전형적으로 예를 들어 delete_iacl_dir에 대해 did의 사용과 같은 밑줄과 함께 연결되어 명령 이름을 형성하는 단어의 첫 글자에 해당합니다.

일부 다른 시스템에서, 축약은 명령 이름을 고유하게 식별하기 위해 그것의 첫 문자를 허용하는 것으로 충분하지만 (예를 들어 SUPERUSER에 대해 약어로 SU), 다른 시스템은 일부 특정 약어가 미리 프로그래밍되거나 (예를 들어, COMMAND.COM에서 MKDIR에 대해 MD) 배치 스크립트와 별칭을 통해 사용자-정의될 수 있습니다 (예를 들어, tcsh에서 alias md mkdir).

 

Option conventions in DOS, Windows, OS/2

DOS, OS/2 및 Windows에서, 그것들의 COMMAND.COM 또는 CMD.EXE (또는 내부 그것들의 명령)에서 호출된 다른 프로그램은 같은 운영 시스템 내에서 다른 구문을 사용할 수 있습니다. 예를 들어:

• 옵션은 "스위치 문자": /, - 중 하나로 표시되거나, 어느 하나가 허용될 수 있습니다. 아래를 참조하십시오.
• 그것들은 대소문자 구별될 수 있거나 구별되지 않을 수 있습니다.
• 때로는 옵션과 해당 인수가 함께 실행되고, 때로는 공백으로, 때로는 문자, 전형적으로 : 또는 =로 분리됩니다; 따라서 Prog -fFilename, Prog -f Filename, Prog -f:Filename, Prog -f=Filename.
• 일부 프로그램은 단일-문자 옵션을 결합되도록 허용합니다; 다른 것들은 그렇지 않습니다. 스위치 -fA는 -f -A과 같거나, 올바르지 않거나, 심지어 유효하지만 다른 매개변수일 수도 있음을 의미할 수 있습니다.

DOS, OS/2 및 Windows에서, 전방 슬래시 (/)가 가장 널리 사용되지만, 하이픈-빼기도 때때로 사용됩니다. 많은 버전의 DOS (MS-DOS/PC DOS 2.xx 이상, 5.0 이후의 모든 DR-DOS 버전과 마찬가지로, PTS-DOS, Embedded DOS, FreeDOS 및 RxDOS)에서, 사용될 스위치 문자 (때로는 switchar 또는 switchchar로 약칭됨)는 시스템 호출 (INT 21h/AX=3700h)에서 반환된 값에 의해 정의됩니다. 이 API에 의해 반환되는 기본 문자는 /이지만, 위에서 언급한 시스템에서 하이픈-빼기로 변경될 수 있으며, Datalight ROM-DOS 및 DOS/PC DOS 5.0 이상에서는 예외이며 항상 이 호출에서 /를 반환합니다 (SwitChar 기능을 다시 활성화하기 위해 사용 가능한 많은 TSR 중 하나가 로드되지 않는 한). 이들 시스템 중 일부 (MS-DOS/PC DOS 2.xx, DOS Plus 2.1, DR-DOS 7.02 이상, PTS-DOS, Embedded DOS, FreeDOS 및 RxDOS)는 CONFIG.SYS에서 SWITCHAR 지시문으로 사전-구성될 수도 있습니다. General Software의 Embedded DOS는 같은 목적으로 SWITCH 명령을 제공하고, 반면에 4DOS는 SETDOS /W:n을 통해 설정을 변경하는 것을 허용합니다. DR-DOS 아래에서, 설정이 /에서 변경되면, PROMPT 매개변수 $G의 표시에서 첫 번째 디렉토리 구분 기호 \가 전방 슬래시 /로 변경될 것이며 (이것은 역시 DOS, FlexOS, 4680 OS, 4690 OS, OS/2 및 Windows에서 유효한 디렉토리 구분자이기도 합니다) 따라서 변경 사항을 나타내는 시각적 단서 역할을 합니다. 역시, 현재 설정은 내장된 도움말 화면에도 반영됩니다. 일부 버전의 DR-DOS COMMAND.COM은 현재 설정을 표시하기 위해 PROMPT 토큰 $/도 지원합니다. DR-DOS 7.02 이후 COMMAND.COM은 이식 가능한 일괄작업을 작성할 수 있도록 %/%라는 유사-환경 변수도 제공합니다. 여러 외부 DR-DOS 명령은 시스템 설정을 재정의하기 위해 환경 변수 %SWITCHAR%를 추가적으로 지원합니다.

어쨌든, 많은 프로그램은 명령줄 인수를 구문 분석하기 전에 스위치 설정을 검색하는 대신 오직 / 사용하도록 고정되어 있습니다. 매우 적은 일부가, 주로 유닉스 계열 시스템의 포트, 스위치 문자가 설정되지 않음에도 "-"를 허용하도록 프로그래밍되어 있습니다 (예를 들어, Microsoft Windows와 함께 제공되는 netstat와 ping은 /? 옵션을 사용 가능한 옵션을 목록화하도록 허용하고, 여전히 그 목록은 "-" 관례를 지정할 것입니다.

 

Option conventions in Unix-like systems

유닉스-계열 시스템에서, ASCII 하이픈-빼기는 옵션을 시작합니다; 새로운 (및 GNU) 관례는 둘의 하이픈을 사용 뒤에 단어 (예를 들어, --create)를 옵션의 용도를 식별하기 위해 사용하고 반면 이전 관계 (및 여전히 자주 사용되는 옵션에 대한 옵션으로 사용 가능)은 하나의 하이픈 뒤에 하나의 문자를 사용하는 것입니다 (예를 들어, -c); 하나의 하이픈 다음에 두 개 이상의 문자가 오면 두 개의 옵션이 지정되고 있음을 의미하거나, 두 번째와 후속 문자가 첫 번째 옵션에 대한 매개변수 (예를 들어, 파일 이름 또는 날짜)임을 의미할 수 있습니다.

뒤에 오는 문자 없이 두 개의 하이픈-빼기 문자 (--)는 남아있는 인수가 옵션으로 처리되지 않아야 함을 나타낼 수 있으며, 이는 예를 들어 파일 이름 자체가 하이픈으로 시작하거나, 추가 인수가 내부 명령 (예를 들어, sudo)을 의미하는 경우에 유용합니다. 이중 하이픈-빼기는 더 설명적인 옵션 이름이 사용되는 "긴 옵션" 접두사로 사용되기도 합니다. 이것은 GNU 소프트웨어의 공통 특색입니다. getopt 함수와 프로그램, 및 getopts 명령은 보통 명령줄 옵션을 구문 분석하는 데 사용됩니다.

유닉스 명령 이름, 인수 및 옵션은 대소문자를 구분합니다 (주로 다른 운영 시스템에서 널리 사용되는 명령이 유닉스로 이식된 몇 가지 예시를 제외합니다).

 

Option conventions in other systems

FlexOS, 4680 OS 및 4690 OS는 -를 사용합니다.

CP/M는 전형적으로 [를 사용했습니다.

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

Data General의 RDOS, AOS, 등 운영 시스템 아래에서 CLI와 마찬가지로 Business Basic과 함께 제공된 CLI 버전은 스위치 문자로 /만 사용하고, 대소문자를 구분하지 않고, 일부 인수에서 "지역 스위치"를 MAC/U LIB/S A B C $LPT/L가 사용자 기호를 덧붙이기 위한 매크로 어셈블러 명령에 대한 전역 옵션 "U"를 가지고 있지만, LIB를 지정하는 하나는 전달 2로 건너뛰어야 하고 다른 하나는 프린터, $LPT에 직접 나열하는 것과 같은 그것들이 해석되는 방법을 제어하는 것을 허용합니다.

Built-in usage help

CLI에 대한 비판 중 하나는 사용 가능한 동작에 대해 사용자에게 단서가 없다는 것입니다. 대조적으로, GUI는 보통 메뉴, 아이콘, 또는 기타 시각적 단서를 갖는 사용 가능한 동작을 사용자에게 알려줍니다. 이 제한을 극복하기 위해, 많은 CLI 프로그램은 전형적으로 인수 없이 또는 ?, -?, -h, -H, /?, /h, /H, /Help, -help, 또는 --help 중 하나가 호출될 때 그것의 유효한 매개변수의 간략한 요약을 표시합니다.

어쨌든, 사용법 도움말을 표시하기 위해 매개변수 없이 프로그램 이름을 입력하는 것은 위험할 수 있는데, 왜냐하면 명령줄 인수가 선택 사항인 프로그램과 스크립트는 추가적인 알림 없이 실행되기 때문입니다.

비록 적어도 도움말 매개변수에 대해서 바람직하지만, 프로그램은 위에 예시된 모든 옵션 도입 문자를 지원하지 않을 수 있습니다. 기본 명령-줄 옵션 문자가 /에서 -로 변경될 수 있는 DOS 아래에서, 프로그램은 현재 설정을 결정하기 위해 SwitChar API를 질의할 수 있습니다. 따라서, 프로그램이 그것들 모두를 지원하도록 고정되어 있지 않으면, 사용자는 도움을 안정적으로 요청할 수 있기 위해서라도 현재 설정을 알아야 할 수 있습니다. SwitChar가 -로 변경되었고 따라서 / 문자가 DOS 명령줄에서도 대안적인 경로 구분 기호로 수용되면, 프로그램은 /h 또는 /H와 같은 옵션을 도움말 매개변수가 아닌 경로로 잘못 해석할 수 있습니다. 어쨌든, 첫 번째 또는 유일한 매개변수로 주어지면, 대부분의 DOS 프로그램은 관례에 따라 현재 SwitChar 설정에 관계없이 도움말 요청으로 이것을 수락합니다.

어떤 경우에서, 다른 수준의 도움말이 프로그램에 대해 선택될 수 있습니다. 이것을 지원하는 일부 프로그램은 (/H:1, /H:2, 등에서 처럼) 도움말 매개변수에 선택적 인수로 자세한 정보를 제공하는 것을 허용하거나 그것들이 단지 도움말 매개변수에 물음표를 갖는 짧은 도움말과 다른 도움말 옵션에 대해 더 긴 도움말 화면을 제공합니다.

프로그램에 따라, 허용된 매개변수에 대한 추가 또는 보다 구체적인 도움말은 문제에서 매개변수를 도움말 매개변수에 대한 인수로 제공하거나 그 반대의 경우에 사용할 수 있습니다 (예를 들어, /H:W 또는 /W:?, /W가 프로그램에 의해 또 다른 매개변수임을 가정합니다).

도움말 매개변수와 유사한 방식이지만, 훨씬 덜 공통적으로, 일부 프로그램은 -!, /!, -about, 또는 --about와 같은 "about" 매개변수와 함께 호출될 때 자체에 대한 (모드, 상태, 버전, 저자, 라이선스 또는 연락처 정보와 같은) 추가적인 정보를 제공합니다.

?와 ! 문자는 전형적으로 명령줄에서 다른 용도로도 사용되기 때문에, 그것들은 모든 시나리오에서 사용할 수 있는 것은 아니고, 따라서, 그것들은 해당 도움말 정보에 접근하기 위한 유일한 옵션은 아니어야 합니다.

프로그램의 내장 내부 도움말에 의해 제공하는 것보다 더 자세한 도움말이 필요하면, 많은 시스템은 전용 외부 "help command" 명령 (또는 이와 유사한 것)을 지원하며, 이 명령은 명령 이름을 호출 매개변수로 받아들이고 외부 도움말 시스템을 호출합니다.

DR-DOS 제품군에서, 명령 자체 대신 COMMAND.COM 프롬프트에서 /? 또는 /H를 입력하는 것은 동적으로 생성된 사용 가능한 내부 명령의 목록을 표시할 것입니다; 4DOS와 NDOS는 ?를 프롬프트에서 입력함으로써 같은 기능을 지원합니다 (이는 DR-DOS COMMAND.COM의 최신 버전에서도 수용됩니다); 내부 명령은 SETDOS /I를 통해 개별적으로 비활성화되거나 다시 활성화될 수 있습니다. 이 외에도, 일부 최신 버전의 DR-DOS COMMAND.COM은 ?% 명령을 사용 가능한 내장 유사-환경 변수의 목록을 표시하기 위해 수용합니다. 빠른 도움말 참조로서의 목적 외에도, 이것은 배치작업에서 놓여있는 명령-줄 프로세서의 기능을 질의하기 위해 사용될 수 있습니다.

Command description syntax

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

• 요구된 매개변수에 대해 꺾쇠 괄호: ping <hostname>
• 선택적 매개변수에 대해 대괄호: mkdir [-p] <dirname>
• 반복된 항목에 대해 줄임표: cp <source1> [source2…] <dest>
• 항목의 선택에 대해 수직 막대: netstat {-t|-u}

이들 문자는 쉘에서 직접 사용될 때와 의미가 다름을 주목하십시오. 꺾쇠 괄호는 매개변수 이름을 리터럴 문자열과 혼동할 가능성이 없을 때 생략될 수 있습니다.

The space character

많은 컴퓨팅 영역이지만, 특히 명령줄에서, 공백 문자는 명령이나 매개변수의 일부로, 또는 매개변수나 이름 구분 기호로 두 가지 고유하고 호환되지 않는 함수를 가지고 있기 때문에 문제를 일으킬 수 있습니다. 모호성은 처음 위치에서 파일과 디렉토리 이름에 삽입된 공백을 금지하거나 (예를 들어, 그것들을 밑줄 _로 대체함으로써), 이름을 따옴표 문자 사이에 포함된 공백으로 묶거나 공백 앞에 탈출 문자, 보통 백슬래시 (\)를 사용함으로써 방지될 수 있습니다. 예를 들어, 다음은

Long path/Long program name Parameter one Parameter two …

모호합니다 ("program nmae"은 프로그램 이름의 일부입니까?, 아니면 두 개의 매개변수입니까?); 어쨌든, 다음은

Long_path/Long_program_name Parameter_one Parameter_two …, LongPath/LongProgramName ParameterOne ParameterTwo …, "Long path/Long program name" "Parameter one" "Parameter two" …

및

Long\ path/Long\ program\ name Parameter\ one Parameter\ two …

모호하지 않습니다. 유닉스-기반 운영 시스템은 따옴표의 필요성을 최소화하기 위해 포함된 공백의 사용을 최소화합니다. Microsoft Windows에서, 우리는 종종 삽입된 공백 (예를 들어, 디렉토리 이름)이 공통적이기 때문에 따옴표를 사용해야 하는 경우가 많습니다.

Command-line interpreter

비록 대부분의 사용자는 쉘을 대화형 명령 해석기로 생각할지라도, 그것은 실제로는 각 문장이 명령을 실행하는 프로그래밍 언어입니다. 그것이 명령 실행의 대화형과 프로그래밍 측면을 모두 충족해야 하기 때문에, 그것은 디자인만큼이나 역사에 의해 형성된 이상한 언어입니다.

— Brian W. Kernighan & Rob Pike

용어 명령-줄 해석기 (CLI)는 사용자에 의해 입력되거나 파일 또는 다른 종류의 데이터 스트림에서 읽혀질 수 있는 일련의 텍스트를 해석하도록 설계된 컴퓨터 프로그램에 적용됩니다. 해석의 문맥은 보통 주어진 운영 시스템 또는 프로그래밍 언어 중 하나입니다.

명령-줄 인터프리터는 사용자에게 매우 효율적 (및 종종 간결한) 방법에서 다양한 명령을 실행하는 것을 허용합니다. 이것은 사용자에게 명령과 해당 매개변수의 이름과 해석되는 언어의 구문을 아는 것을 요구합니다.

유닉스 #! 메커니즘과 OS/2 EXTPROC 명령은 배치 파일을 외부 프로세서로 쉽게 전달하도록 기능합니다. 우리는 이들 메커니즘을 전용 용도로 특정 명령 프로세서를 작성하고, 배치 파일에 있는 외부 데이터 파일을 처리하기 위해 사용할 수 있습니다.

OS/2 Presentation Manager와 Microsoft Windows의 초기 버전과 같은 많은 그래픽 인터페이스는 명령-줄을 문서와 프로그램을 여는 도우미 프로그램을 호출하기 위해 사용합니다. 그 명령은 그래픽 쉘 또는 레지스트리 또는 OS/2 OS2USER.INI 파일과 같은 파일에 저장됩니다.

Early history

최초의 컴퓨터는 대화형 입/출력 장치를 지원하지 않았으며, 종종 감지 스위치와 조명에 의존하여 컴퓨터 운영자와 통신했습니다. 이것은 한 번에 하나의 프로그램을 실행하는 배치 시스템에 적합했으며, 종종 프로그래머가 운영자 역할을 했습니다. 이것은 역시 조명과 스위치를 하나의 기계 명령으로 테스트되고 설정될 수 있기 때문에 오버헤드가 낮다는 이점이 있었습니다. 나중에 단일 시스템 콘솔이 운영자에게 시스템과 통신할 수 있도록 추가되었습니다.

1960년대부터, 컴퓨터와 사용자의 상호 작용은 주로 명령-줄 인터페이스를 수단으로 이루어졌으며, 처음에는 Teletype Model 33 ASR과 같은 시스템에서 시작했지만, 그 다음에는 VT52와 같은 초기 CRT-기반 컴퓨터 터미널에서 이루어졌습니다.

이들 모든 장치는 그래픽이나 그림을 표시할 수 없는 순전히 텍스트 기반이었습니다. 영업 응용 프로그램에 대해, 텍스트-기반 메뉴가 사용되었지만, 보다 일반적인 상호 작용을 위해서는 명령줄이 인터페이스였습니다.

1964년경, Louis Pouzin은 Compatible Time-Sharing System (CTSS)에서 더 간단한 초기 기능을 기반으로 Multics에 개념과 이름 쉘을 도입했습니다.

1970년대 초부터, 유닉스 운영 시스템은 강력한 명령-줄 환경의 개념을 채택했고, 한 명령의 출력을 또 다른 명령의 입력으로 파이프하는 기능을 도입했습니다. 유닉스는 역시 사용자 지정 명령처럼 행동하는 "쉘 스크립트"로 명령의 문자열을 저장하고 다시 실행할 수 있는 기능을 가졌습니다.

명령-줄은 Commodore PET, Apple II 및 BBC Micro와 같은 초기 가정용 컴퓨터에 대해 주요 인터페이스이기도 했습니다 – 거의 항상 BASIC 해석기의 형식이었습니다. 보다 강력한 영업 지향 마이크로컴퓨터가 CP/M과 이후 IBM PC와 같은 DOS 컴퓨터와 함께 등장했을 때, 명령-줄은 출력의 글로빙(globbing)과 파이핑(piping)과 같은 유닉스 쉘의 일부 구문과 특색을 차용하기 시작했습니다.

명령-줄은 1983년 Apple Lisa와 1984년 Apple Macintosh에서 사용된 PARC GUI 접근 방식에 의해 처음으로 심각한 도전을 받았습니다. 소수의 컴퓨터 사용자는 GEOS와 Windows 3.1과 같은 GUI를 사용했지만 대다수의 IBM PC 사용자는 1995년 Windows 95가 출시될 때까지 그것들의 COMMAND.COM 쉘을 GUI로 교체하지 않았습니다.

Modern usage as an operating system shell

대부분의 비-전문가 컴퓨터 사용자는 이제 GUI를 거의 독점적으로 사용하지만, 고급 사용자는 강력한 명령-줄 환경으로의 접근법을 가집니다:

• DCL 언어를 사용하는 기본 VAX/VMS 명령 쉘은 PC-DCL와 Acceler8 DCL Lite를 포함하여 Windows 시스템에 최소 3번 이식되어 왔습니다. 유닉스 명령 쉘은 VMS, DOS/Windows 95와 Windows NT 유형의 운영 시스템으로 이식되어 왔습니다.
• COMMAND.COM은 MS-DOS, IBM PC DOS, 및 DR-DOS, SISNE plus, PTS-DOS, ROM-DOS, 및 FreeDOS와 같은 클론의 명령-줄 해석기입니다.
• 윈도우 자원 키트와 유닉스에 대해 윈도우 서비스는 Perl 해석기와 함께 Korn과 본 쉘을 포함합니다 (유닉스에 대한 서비스에는 이후 버전의 ActiveState ActivePerl과 버전 1와 2에 대해 Interix와 Microsoft에 의해 컴파일된 쉘을 포함합니다).
• IBM OS/2 (및 eComStation와 ArcaOS와 같은 파생물)은 cmd.exe 프로세스를 가집니다. 이것은 REXX 확장자와 함께 COMMAND.COM 명령을 복사합니다.
• cmd.exe은 운영 시스템의 Windows NT 스트림의 일부입니다.
• 여전히 또 다른 cmd.exe는 Windows CE 3.0을 위한 제거된 쉘입니다.
• PocketDOS라고 하는 MS-DOS 유형 해석기가 Windows CE 기계에 이식되어 왔습니다; 대부분의 최신 릴리스는 MS-DOS 6.22와 거의 동일하고 역시 Windows 1, 2 및 3.0, QBasic과 기타 개발 도구, 4NT와 4DOS도 실행할 수 있습니다. 최신 릴리스는 MS-DOS 6.22, PC DOS 7, DR DOS 3.xx, 등의 여러 쉘을 포함하고 있습니다.
• Windows 사용자는 CScript 인터페이스를 명령줄에서 프로그램을 대체하기 위해 사용할 수 있습니다. PowerShell은 명령-줄 인터페이스를 제공하지만, 해당 애플릿은 Shell 스크립트로 작성되지 않습니다. 유닉스 쉘의 구현은 POSIX 하위-시스템, Cygwin, MKS Toolkit, UWIN, Hamilton C shell 및 기타 소프트웨어 패키지의 일부로도 사용할 수 있습니다. 이들 상호 운용성 도구에 사용 가능한 쉘은 csh, ksh, sh, Bash, rsh, tclsh 및 덜 공통적으로 zsh, psh를 포함합니다.
• PHP의 구현은 php-cli라는 대화식 사용을 위한 쉘을 가집니다.
• 표준 Tcl/Tk은 둘의 쉘, Tclsh와 Wish을 가지며, 후자는 GUI 버전입니다.
• Python, Ruby, Lua, XLNT, 및 기타 해석기는 역시 대화형 사용을 위해 명령을 가집니다.
• FreeBSD는 tcsh를 superuser에 대해 그것의 기본 대화형 쉘로 사용하고, 기본 스크립팅 쉘로 ash를 사용합니다.
• 많은 리눅스 배포판은 유닉스 쉘의 Bash 구현을 가집니다.
• Apple macOS와 일부 리눅스 배포판은 zsh를 사용합니다. 이전에, macOS는 tcsh와 Bash를 사용했습니다.
• Embedded Linux (및 기타 embedded 유닉스-계열) 장치는 종종 Busybox의 일부로 유닉스 쉘의 Ash 구현을 사용합니다.
• Android는 이전 안드로이드 버전에서 사용된 ash에서 파생된 쉘을 대체하고 별도의 도구 상자 바이너리의 명령으로 보완되는 mksh 쉘을 사용합니다.
• Cisco IOS, Junos 및 기타 많은 것과 함께 라우터는 공통적으로 명령줄에서 구성됩니다.
• Plan 9 운영 시스템은 Bourne 쉘과 디자인에서 유사한 rc 셸을 사용합니다.

Scripting

대부분의 명령-줄 해석기는 다양한 범위에서 스크립팅을 지원합니다. (많은 경우에서 언어가 특정 명령-줄 해석기에 고유하지만, 그것들은, 결국, 해석된 프로그래밍 언어의 해석기입니다.) 그것들은 자신이 해석하는 언어로 작성된 스크립트 (쉘 스크립트 또는 배치 파일이라고도 함)를 해석할 것입니다. 일부 명령-줄 해석기는 자체 엔진 외에도 REXX와 같은 다른 언어의 해석기 엔진을 통합하여, 직접 명령-줄 해석기 자체 내에서 해당 언어로 스크립트의 실행을 허용합니다.

반대로, 스크립팅 프로그래밍 언어, 특히 평가 함수를 갖는 언어 (예를 들어, REXX, Perl, Python, Ruby 또는 Jython)는 명령줄 해석기와 필터를 구현하기 위해 사용될 수 있습니다. 몇몇 운영 시스템, 특히 DOS에 대해, 그러한 명령 해석기는 제공된 것보다 더 유연한 명령-줄 인터페이스를 제공합니다. 다른 경우에서, 그러한 명령 해석기는 언어의 사용자 인터페이스와 입력/출력 기능을 사용하여 고도로 사용자-정의된 사용자 인터페이스를 제공할 수 있습니다.

Other command-line interfaces

명령 줄은 프로그램과 마찬가지로 사용자 사이의 인터페이스를 제공합니다. 이러한 의미에서, 명령 줄은 대화 상자의 대안입니다. 편집기와 데이터베이스는 대안 명령 프로세서가 실행할 수 있는 명령줄을 제공합니다. 다른 한편으로, 대화 상자를 여는 명령줄에 옵션을 가질 수 있습니다. 'Take Command' 최신 버전은 이 특색을 가집니다. DBase는 대화 상자를 명령줄을 구성하기 위해 사용했으며, 사용 전에 추가로 편집될 수 있습니다.

BASIC, diskpart, Edlin. 및 QBASIC과 같은 프로그램은 모두 명령줄 인터페이스를 제공하며, 그 중 일부는 시스템 쉘을 사용합니다. Basic은 8-비트 인텔 컴퓨터의 기본 인터페이스를 모델로 합니다. 계산기는 명령줄 또는 대화 상자 인터페이스로 실행될 수 있습니다.

Emacs는 미니버퍼 형식으로 명령줄 인터페이스를 제공합니다. Emacs 표준 텍스트 편집 지원을 사용하여 명령과 인수는 입력될 수 있고, 출력은 또 다른 버퍼에 표시됩니다.

Adventure 또는 King's Quest 1-3과 같은 많은 텍스트 모드 게임이 있으며, 화면 하단에 명령을 입력하는 사용자에 의존했습니다. 우리는 'get ring' 또는 'look'과 같은 명령을 입력함으로써 캐릭터를 제어합니다. 그 프로그램은 캐릭터가 그것을 어떻게 보거나, 행동을 발생시키는지를 설명하는 텍스트를 반환합니다. 텍스트 어드벤처 The Hitchhiker's Guide to the Galaxy는, Douglas Adam의 같은 이름의 책을 기반으로 한 인터랙티브 픽션으로, 텔레타이프-스타일의 명령줄 게임입니다.

이들 인터페이스 중 가장 주목할만한 것은 표준 스트림 인터페이스로, 한 명령의 출력을 또 다른 명령의 입력으로 전달할 수 있습니다. 텍스트 파일도 두 가지 용도로 사용할 수 있습니다. 이것은 파이핑, 필터 및 리다이렉션의 인터페이스를 제공합니다. 유닉스 아래에서, 장치도 파일이므로, stdin, stdout 및 stderr에 사용되는 쉘에 대한 일반 유형 파일은 tty 장치 파일입니다.

또 다른 명령-줄 인터페이스는 쉘 프로그램에게 도우미 프로그램을 시작하는 것을, 문서를 시작하거나 프로그램을 시작하는 것을 허용합니다. 그 명령은 쉘에 의해 내부적으로 처리되고 그런-다음 문서를 실행하기 위해 또 다른 프로그램으로 전달됩니다. Windows와 OS/2의 그래픽 인터페이스는 다른 프로그램 – 콘솔 또는 그래픽 – 으로 전달되는 명령줄에 크게 의존하며, 보통 사용자 콘솔을 표시 없이 명령줄을 처리합니다.

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

웹 브라우저의 URL 입력 필드는 명령줄로 사용될 수 있습니다. 그것은 웹 앱을 "실행"하고, 브라우저 구성에 접근하고, 마찬가지로 검색을 수행하기 위해 사용될 수 있습니다. "인터넷의 명령줄"이라고 불리는 Google은 알려진 형식의 검색 매개변수를 감지할 때 도메인-별 검색을 수행합니다. 이 기능성은 검색이 브라우저 필드 또는 Google의 웹사이트에서 트리거되는지 여부에 따라 제공됩니다.

브라우저에서 독립형 웹 앱이나 더 큰 응용 프로그램의 일부로 명령줄 응용 프로그램을 작성할 수 있는 JavaScript 라이브러리가 있습니다. 그러한 웹사이트의 예는 DuckDuckGo에 대한 CLI 인터페이스입니다. 브라우저에서 서버 명령-줄 인터페이스에 접근할 수 있는 웹-기반 SSH 응용 프로그램도 있습니다.

PC의 많은 비디오 게임은 종종 콘솔이라고 하는 명령줄 인터페이스가 있습니다. 그것은 전형적으로 개발 중 게임 개발자와 디버깅 목적으로 모드 개발자에 의해 게임의 일부를 속이거나 건너뛰기 위해 사용됩니다.

External links

• The Roots of DOS David Hunter, Softalk for the IBM Personal Computer March 1983. Archived at Patersontech.com since 2000.
• Command-Line Reference: Microsoft TechNet Database "Command-Line Reference"