개발자를 위한 명령줄 도구

오늘날의 온라인 세계에서는 앱 제조업체가 모바일 또는 웹 앱을 선호함에 따라 사용자를 유치하기 위한 싸움이 계속되고 있습니다. 데스크톱 응용 프로그램의 관련성은 점점 줄어들고 있습니다. 게다가 그들은 또한 웹 앱에 대한 풍부한 클라이언트에 지나지 않는 경향이 있습니다. Electron은 인기 있는 플랫폼입니다.

이것은 곧 데스크톱을 플랫폼으로 포기한다는 의미입니까? 아뇨, 당연히 아닙니다. 저는 그렇게 말하지 않을 것입니다. 게다가 최근 GUI 앱이 정체된 것처럼 보이지만 계속해서 성장하는 데스크톱 앱 부문이 있습니다.

해커가 등장하는 영화를 본 적이 있습니까? 종종 이 사람들은 일종의 터미널(보통 어두운 배경과 밝은 전경)을 표시하는 모니터 앞에서 작업하는 것으로 표시됩니다. 이 터미널은 차례로 그것을 보는 사람에게 분명히 어떤 의미가 있는 지나가는 문자로 넘쳐나는 경향이 있습니다.

이러한 해커의 행동 표현은 종종 전문 개발자에 의해 조롱되며, 재미를 위해 다양한 "해커" 효과를 시뮬레이션하는 프로그램도 있습니다.

그러나 현실 세계에서 명령줄 도구는 엔터테인먼트 가치를 위해 사용되지 않습니다.

우리가 여전히 명령줄 인터페이스 도구를 사용하는 이유

이 문서에서는 명령줄 인터페이스(CLI) 도구 사용의 실용적인 측면에 중점을 둡니다. CLI 명령을 알고 고품질 도구를 사용하면 생산성을 높일 수 있으며 GUI 앱보다 텍스트 인터페이스에서 훨씬 더 실용적인 자동화에 대한 다양한 접근 방식의 문을 열 수 있습니다.

여러 번의 클릭이 하나의 긴 클릭으로 들릴 정도로 GUI에서 반복적인 작업을 더 잘 수행할 수 있습니다. 문제는 이것이 여전히 특수 스크립트의 효율성을 능가하지 못한다는 것입니다. 게다가 동일한 작업을 수동으로 수행하면 인지 부하가 ​​추가되고 인적 오류가 발생할 가능성이 높아집니다. 평소와 같이 우리는 인간이 지루하고 반복적이거나 압도적이라고 생각할 수 있는 작업을 처리하기 위해 컴퓨터에 의존합니다.

터미널 도구가 여러 유형의 인터페이스를 제공할 수 있다는 것을 아는 것은 가치가 있습니다. 단순히 매개변수를 취하고 출력을 제공하는 ls와 같은 비대화형 것들이 있습니다. 패키지 관리자에서 가장 흔히 볼 수 있는 대화형 또는 반 대화형 인터페이스가 있습니다. ("확인되지 않은 소스에서 설치를 계속하시겠습니까?") 그런 다음 터미널의 한계에 맞게 설계된 대화형 GUI 앱인 TUI(텍스트 사용자 인터페이스)가 있습니다. 아마도 가장 유명한 것은 90년대에 매우 유명했던 Norton Commander의 클론인 Midnight Commander(mc)일 것입니다.

필수 명령줄 도구

콘솔 거주자가 되려면 최소한의 필수 명령줄 개발자 도구를 갖추어야 합니다. 가장 확실히 없이는 살 수 없는 것은 대화형 쉘 (편리한 탭 완성으로 현대적인 것을 목표로 함)과 텍스트 편집기 입니다.

이제 저는 의식적이든 아니든 도구 작성자가 내리는 설계 결정의 기초가 되는 UNIX 철학 에 대해 언급하겠습니다. 몇 가지 핵심 사항은 다음과 같이 요약할 수 있습니다.

• 모든 것을 파일로 취급하십시오.
• 한 가지만 하되 잘 하십시오.
• 표준 입력에서 읽고, 표준 출력에 쓰고, 표준 오류 스트림에 오류를 전달합니다.
• 성공하면 코드 0을 반환합니다. 0이 아닌 값은 오류를 의미합니다(정확한 반환 코드로 지정할 수 있음).
• 명령 체인 및 스크립팅을 허용합니다.

껍데기

터미널을 열면 가장 먼저 보이는 것은 쉘입니다. 사용자와 기계의 상호작용을 가능하게 하는 부분입니다. 명령을 해석하고 프로그램 이름과 인수로 분할하고 사용자가 던진 모든 쉘 명령을 실행합니다.

역사적으로 다양한 종류의 껍질이 있었습니다. 가장 인기 있는 것 중에는 csh (C Shell)와 Bourne Shell의 다양한 구현(보통 단순히 sh 로 알려짐)이 있습니다. Bourne Shell은 Korn Shell로 확장되어 약간의 관심을 얻었고 여전히 매니아들이 사용하고 있습니다. Csh는 현재 일부 BSD 시스템의 기본 셸이지만 거의 모든 다른 UNIX 계열 운영 체제는 일종의 Bourne 셸을 선호합니다. Linux 배포판은 bash를 선호하는 경향이 있지만 Mac OS X에는 zsh가 기본 선택으로 제공됩니다.

다른 가능성이 있지만 Windows 시스템의 Microsoft PowerShell을 제외하고는 훨씬 덜 유명합니다. PowerShell은 부분적으로 zsh와 같은 대화형 UNIX 셸과 부분적으로 .NET 런타임에서 영감을 받았습니다. UNIX 세계에서 일반적인 개념인 모든 것을 텍스트로 취급하는 대신 데이터의 객체 지향 조작을 허용합니다.

Microsoft PowerShell이 ​​Windows 영역에서 상당히 인기가 있지만 UNIX 기원의 많은 프로그램(가장 주목할만한 Git, Autotools 또는 Make)은 Bourne Shell의 일부 변형을 선호하는 경향이 있습니다. 이 때문에 msys(Git for Windows와 함께 번들로 제공됨), Cygwin 또는 Microsoft의 최근 WSL과 같은 프로젝트가 탄생했습니다. Windows에서 Linux와 같은 느낌을 원한다면 MSys가 여기에서 최고의 선택입니다. 표준 Linux 바이너리를 실행할 수 있는 완전한 기능을 갖춘 Linux 환경을 원한다면 WSL이 최선입니다. UNIX API이지만 Windows 실행 파일로 컴파일된 경우(필요한 이유를 실제로 알고 있는 경우에만 사용) Cygwin이 답입니다.

편집자

쉘에 익숙해지면 몇 가지 유용한 기술을 배우고 싶을 것입니다. 대부분의 코딩 작업은 텍스트(코드, README, 커밋 메시지) 작성을 중심으로 이루어지므로 대화형 텍스트 편집기에 대한 충분한 지식이 필수적입니다. 선택할 수 있는 것이 많고 편집기는 모든 개발자에게 가장 필요한 도구 중 하나이기 때문에 어떤 편집기가 가장 좋은지에 대한 의견도 많을 것입니다.

가장 널리 사용되는 텍스트 편집기는 단순 텍스트 편집기 와 프로그래밍 가능한 텍스트 편집기 의 두 가지 기본 그룹으로 나눌 수 있습니다.

둘 다 코드 작성에 적합할 수 있지만 이름에서 알 수 있듯이 프로그래밍 가능한 기능은 필요에 맞게 편집기를 구성하고 사용자 지정할 수 있는 기능을 제공합니다. 그러나 학습 곡선이 더 가파르고 설정하는 데 더 많은 시간이 필요할 수 있기 때문에 대가가 따릅니다.

기본 텍스트 편집기

간단한 텍스트 편집기 중 GNU Nano가 가장 널리 보급되어 있습니다. 실제로, 이것은 Pico 편집기의 복제본이므로 시스템에서 사용할 수 없는 경우 다른 것을 시도할 수 있습니다. 둘 다에 대한 더 현대적인 또 다른 대안은 마이크로 편집기입니다. 단순하고 확장 가능한 것을 동시에 원하는 경우 여기에서 시작하는 것이 좋습니다.

프로그래밍 가능한 텍스트 편집기

많은 개발자는 Vim 및 GNU Emacs와 같은 다양한 진영의 프로그래밍 가능한 편집기에 의존합니다. 두 편집기 모두 콘솔 또는 GUI 모드에서 실행할 수 있으며 둘 다 다른 소프트웨어에서 발견되는 키 바인딩에 영향을 미쳤습니다. 둘 다 API뿐만 아니라 내장된 실제 프로그래밍 언어도 제공합니다. Emacs는 LISP에 중점을 두고 Vim은 자체 VimL를 사용하지만 다른 인기 있는 스크립팅 언어(예: Lua, Perl, Python 또는 Ruby)에 대한 인터페이스도 제공합니다. Neovim이라고 하는 Vim에 대한 보다 최근의 접근 방식도 언급할 가치가 있습니다.

다소 혼란스러울 수 있지만 Vim의 전신인 vi 라는 편집기도 있습니다 . Vim보다 훨씬 간단하지만 Vim으로 작성하는 데 충분한 자신감이 있다면 vi를 사용해야 하는 경우 어려움이 없을 것입니다.

pico/GNU Nano 및 vi/Vim은 일반적으로 다양한 시스템에 사전 설치되어 있으므로 최소한 기본 사항은 이해하는 것이 좋습니다(Vim을 종료하는 것은 초보자에게 매우 어려운 문제입니다). 이렇게 하면 원격 시스템에서 무언가를 편집해야 하는 경우 이미 있는 편집기에 관계없이 준비가 됩니다. 개인 장치에서 가장 편안하다고 생각되는 편집기를 자유롭게 사용하십시오.

기본 시스템 편집기

마지막으로 주의할 사항은 시스템에 기본 편집기 라는 것이 있을 수 있다는 것입니다.

$EDITOR 환경 변수는 기본 편집기를 가리키며 Bourne 호환 쉘(sh, bash, ksh, zsh)에서는 echo $EDITOR 를 입력하여 이를 볼 수 있습니다. 값이 개인 선택과 다른 경우 셸의 런타임 구성( ~/.profile , ~./bashrc , ~/.zshrc 등)에 export EDITOR=my-awesome-editor 를 추가하여 직접 설정할 수 있습니다.

버전 제어 시스템 및 메일 클라이언트와 같은 다른 프로그램은 더 긴 텍스트 입력이 필요할 때 이 편집기를 사용합니다.

멀티플렉서

CLI에서 진지한 작업을 시작하자마자 주어진 시간에 하나의 응용 프로그램만 열어 둘 수 있다는 한계에 직면하게 됩니다. 코딩할 때 코드를 편집하고 실행하고 실수를 수정하고 다시 실행할 수 있습니다. 버그를 찾을 때 로그를 나열하고 서버에 요청을 보낼 때 기록되는 내용을 볼 수 있습니다. 일반적으로 이는 두 응용 프로그램 간에 지속적으로 전환하거나 여러 터미널 창을 여는 것을 의미합니다.

여기에서 터미널 멀티플렉서가 도움이 될 수 있습니다. 멀티플렉서에 대해 말할 때 어떤 사람들은 즉시 주제가 GNU 화면이라고 가정합니다. 그것은 동종 최초의 널리 퍼진 도구였으며 오늘날에도 여전히 매우 인기가 있습니다(종종 기본적으로 설치됨). 현대적인 대체품은 당연히 "터미널 다중 x er" 를 의미하는 tmux 입니다.

이 두 가지를 사용하면 주어진 터미널 세션에서 둘 이상의 창을 열고 해당 세션 사이를 자유롭게 전환할 수 있습니다. 창을 분할하여 여러 응용 프로그램을 동시에 실행하고 실시간으로 출력을 관찰하는 데 도움이 됩니다(창 전환 없이). 또한 클라이언트-서버 모드에서 작동합니다. 즉, 언제든지 분리했다가 나중에 다시 돌아와서 중단했던 바로 그 부분에서 작업을 계속할 수 있습니다. 이 마지막 기능은 사람들이 지속적인 IRC 세션을 원할 때 Screen의 인기로 이어졌습니다.

대부분의 사용 사례에서 GNU Screen 또는 tmux가 유용해야 하지만 어떤 이유로 리소스가 너무 무겁다고 생각한다면 더 가벼운 대안도 있습니다. dtach/atach와 abduco가 있습니다. 그들은 의도적으로 범위가 제한되어 있지만 각자의 임무를 잘 수행할 수 있습니다.

패키지 관리자

이 시점에서 앞서 언급한 모든 소프트웨어를 컴퓨터에 설치하는 것에 대해 생각할 수 있습니다. 한 가지 문제는 도구마다 설치 지침이 다르다는 것입니다. 때로는 소스를 다운로드하여 직접 컴파일해야 하고, 때로는 자체 포함된 바이너리를 얻고, 때로는 바이너리 패키지 라고 하는 것을 얻을 수 있습니다. 이는 일반적으로 일부 메타데이터와 함께 압축된 실행 파일을 의미합니다.

소프트웨어 설치 프로세스를 쉽게 하기 위해 운영 체제 작성자는 패키지 관리자 개념을 도입했습니다. 간단히 말해서 패키지 관리자는 CLI 및 데스크톱 앱용 앱 스토어와 같습니다. 실제 앱 스토어보다 수십 년 앞서 있습니다. 문제는 거의 모든 시스템에 자체 패키지 관리자가 있다는 것입니다. Debian, Ubuntu 및 파생된 GNU/Linux 배포판은 APT를 사용하고 Red Hat 기반 배포판은 yum 또는 DNF를 선호하며 다른 Linux 배포판은 소프트웨어를 설치하는 더 이국적인 방법을 사용하므로 다른 BSD 복제본도 마찬가지입니다. 기본 제공 패키지 관리자 외에도 MS Windows용 Chocolatey 및 Mac OS X/macOS용 Homebrew와 같은 사용자 설치 관리자도 있습니다. 프로그램 설치 방법에 대한 지침을 작성하려는 경우 각 시스템에 대한 사례를 작성하게 될 수 있습니다. 좀 너무한 것 같죠?

다행히도 언급된 시스템 중 마지막인 Homebrew는 Homebrew를 GNU/Linux 시스템으로 이식한 Linuxbrew 덕분에 가장 이식성이 뛰어난 시스템일 수 있습니다. 재미있는 점은 Microsoft Windows에서 유사한 사용자 경험을 원할 경우 WSL에서도 작동한다는 것입니다. 그러나 WSL은 공식적으로 지원되지 않습니다.

그렇다면 이식성 외에 Homebrew는 무엇을 제공할 수 있습니까? 우선, 시스템 패키지를 방해하지 않으므로 설치하는 모든 것이 운영 체제의 별도 계층에 있습니다. 게다가 일반적으로 패키지를 설치하는 데 루트 권한이 필요하지 않습니다. 따라서 안정적이고 테스트된 시스템 패키지를 가질 수 있지만 동시에 시스템의 안정성을 희생하지 않고 최신 버전을 확인할 수 있습니다.

편집기를 테스트하려면 Homebrew 또는 Linuxbrew가 있는 시스템에서 다음 명령을 실행하기만 하면 된다고 앞서 언급했습니다.

brew install emacs micro nano vim neovim .

빛나는 물건

우리가 이미 논의한 것은 의심 할 여지없이 작업에 유용합니다. 그러나 필요하지는 않지만 여전히 일상 생활에 편안함을 가져다주는 응용 프로그램도 있습니다. 필요하지 않을 수도 있지만 항상 알 가치가 있습니다.

인터랙티브 필터

명령 기록을 검색하는 것은 지루할 수 있습니다. bash와 zsh는 모두 Ctrl+R 키 바인딩을 제공하지만 한 번에 하나의 대체만 표시합니다. 또한 이전에 사용한 정확한 텍스트를 입력해야 합니다. 이것은 매우 일반적인 작업이기 때문에 명령줄을 사용하기 시작하면 개선하기에 좋은 위치처럼 보입니다.

fzy, percol, peco 또는 fzf와 같은 대화형 필터는 긴 텍스트 줄을 필터링하는 데 도움이 됩니다. 이것은 앞서 언급한 명령 기록, 프로젝트 디렉토리의 모든 코드 행 또는 find . . 여기서 일반적인 아이디어는 사용 가능한 모든 라인을 먼저 제공한 다음 퍼지 찾기 알고리즘에 의존하여 일치하지 않는 모든 것을 필터링하는 것입니다.

예를 들어, Ctrl+R을 fzf에 바인딩하면 화살표를 사용하여 위아래로 탐색할 수 있는 가장 최근 명령 목록이 표시됩니다. 또는 git 을 입력하여 내부 어딘가에 Git 기능이 있는 명령만 표시할 수 있습니다. 개인적으로 인터랙티브 필터가 없는 쉘로 작업을 하다보면 갑자기 조금 헤매는 느낌이 듭니다. 이 기능은 정말 매력적입니다!

또한 프로그래밍 가능한 텍스트 편집기 내에서 대화형 필터를 사용할 수 있습니다. 이렇게 하면 셸과 편집기 간에 통합된 검색 기능을 갖게 됩니다.

인터랙티브 네비게이터

Facebook PathPicker는 주로 C++ 프로젝트로 작업할 때 큰 도움이 되었습니다. 컴파일러에 의해 생성된 오류 로그는 상당히 크고 보기 흉할 수 있으며 해당 로그 내에서 실제 경로를 찾는 기능은 생산성에 도움이 되었습니다.

주어진 텍스트 파일에서 또는 tmux와 함께 사용할 때 화면의 내용에서 fpp는 파일 경로를 제외한 모든 것을 필터링합니다. 그런 다음 해당 경로 중 하나 이상을 선택하고 해당 경로로 명령을 실행할 수 있는 UI를 제공합니다. 가장 일반적인 응답은 물론 기본 작업인 편집기에서 파일을 여는 것입니다.

힘내 UI

당신이 작업하는 프로젝트 중 적어도 하나는 Git을 버전 제어 시스템으로 사용하는 가능성이 있습니다. Git CLI는 완전히 강력하지만 뛰어난 사용자 경험의 정점은 아닙니다. Git 도움말 $SUBCOMMAND 의 모든 옵션을 읽는 스트레스를 줄이려면 tig를 확인하는 것이 좋습니다. log 또는 blame 과 같이 이점이 있는 작업에 대한 멋진 콘솔 UI를 제공합니다.

Git 사용자를 돕기 위한 또 다른 도구는 Fix All Conflicts 의 약어인 fac입니다. 짐작할 수 있듯이 병합 또는 리베이스를 수행하는 동안 충돌이 발생할 때 유용합니다. vimdiff와 같은 다른 병합 도구의 대안입니다.

파일 관리자

90년대에는 모두가 두 개의 창으로 된 파일 관리자를 원했습니다. 이러한 추세는 Norton Commander와 함께 시작되었습니다. 다른 많은 사람들이 같은 길을 갔지만 여전히 안정적인 사용자 기반을 보고 있는 것은 Midnight Commander입니다. 가장 명백한 사용 사례는 mc를 사용하여 로컬 파일을 조작하는 것이지만 원격 시스템으로 작업할 때도 매우 유용합니다.

대부분의 명령줄 프로그램과 마찬가지로 매우 가벼우므로 ssh를 통해 실행하는 데 문제가 없으며 FTP 및 FISH 프로토콜 지원 덕분에 로컬 파일 시스템을 한 창에 표시하고 원격 파일 시스템을 다른 창에 표시할 수 있습니다. 파일 이름을 scp에 대한 인수로 입력하거나 복사하지 않으려는 경우에 이 기능을 사용하십시오.

재미를 위한 CLI 도구

"일만 하고 놀지 않으면 Jack이 둔감해집니다."라고 그들은 말합니다. 당신의 즐거움만을 위한 많은 프로그램, 명령줄 등이 있습니다. Rogue 비디오 게임이 이 범주에 속합니다. 그것은 심지어 게임의 전체 장르에 이름을 붙였습니다! 다른 인기 있는 장난감은 예를 들어 CI 스크립트의 어딘가에서 사용하면 하루를 조금 덜 지루하게 만들 수 있는 운과 카우세이입니다.

그러나 우리 중 일부에게는 콘솔을 사용하는 주된 매력이 영화에서 해커처럼 느껴지는 것입니다. No More Secrets와 Hollywood Hacker가 이 그룹을 잘 대표합니다. 누군가 당신이 일하는 것을 지켜보고 있을 때 시도해보세요. 그러면 당신의 해커 신용은 확실히 올라갈 것입니다!

실제 명령줄

그렇다면 쉘, 편집기 및 다양한 앱의 모든 스위치를 사용하는 방법을 배우는 데 소요되는 시간을 상쇄하는 명령줄의 매력은 무엇입니까? 짧은 대답은 다음 두 가지에서 비롯된 생산성 입니다.

• 하나는 터미널 창만 표시되고 더 이상 아무것도 표시되지 않을 때 주의를 산만하게 할 것이 별로 없기 때문에 더 집중적으로 집중할 수 있다는 것입니다. 알림 팝업도, 광고도, 예쁜 고양이 사진도 없습니다. 당신과 당신의 목표.

• 두 번째는 자동화입니다. 자주 결합되는 여러 작업을 스크립트에 넣고 매번 손으로 일일이 입력하는 대신 나중에 전체적으로 호출할 수 있습니다. 셸 기록을 검색하여 한 번 작성한 특히 복잡한 명령으로 빠르게 돌아갈 수 있습니다. 기본적으로 무엇이든 기록하고 재생할 수 있으며 코드는 수행한 작업에 대한 문서로 제공됩니다.

별칭을 추가하는 기능도 이점에 기여합니다. 예를 들어, (당분간) 완벽할 때까지 동일한 커밋을 업데이트하여 Git에서 커밋을 만드는 경우가 종종 있습니다. 원하는 파일을 준비하고 나면 git carmh 를 실행합니다. commit --amend --reuse-message=HEAD 의미하는 내 개인 별칭이므로 매뉴얼에서 찾으려고 하지 마십시오. 그것은 확실히 약간의 타이핑을 저장합니다.

문제는 사람들이 같은 행동을 반복하는 데 지루해하고 지루해지면 집중력이 떨어진다는 것입니다. 이것은 실수와 오류로 이어질 수 있습니다. 그것들을 피하는 유일한 방법은 높은 초점과 낮은 초점 동작을 인터레이스하지 않는 것입니다. 코드를 작성하는 것은 집중도가 높고 커밋 메시지와 내용을 검토하는 것도 중요하지만 커밋 검토 단계에 도달하기 위해 여기 저기를 기계적 클릭을 몇 번 반복해야 하는 경우 포커스가 낮아질 가능성이 있습니다. 물론 명령줄에 이러한 기계적 활동이 없는 것은 아니지만 자동화 덕분에 대부분의 작업을 피할 수 있습니다.

추가 탐색

이 기사에서 언급한 일부 또는 모든 명령줄 도구에 대해 이미 알고 있을 수 있습니다. 읽으면서 새롭고 유용한 것을 배웠을 수 있습니다. 그렇다면 훌륭합니다. 여기에서 제 목표는 다양한 도구에 대한 포괄적인 개요와 비교를 제공하는 것이 아니라 일상 업무에 도움이 되는 몇 가지 중요한 도구를 보여주고 그 중 일부가 유용할 수 있기를 바라는 것입니다. 도.

훨씬 더 흥미로운 명령줄 프로그램이 있으며 관심이 있다면 현재 사용 가능한 최고의 명령줄 도구 중 일부를 선별한 Awesome Shell 목록을 확인하는 것이 좋습니다.

대부분의 GUI 앱에는 터미널 대응이 있습니다. 여기에는 웹 브라우저, 이메일 클라이언트, 채팅 클라이언트(IRC, Slack, XMPP), PIM 제품군 또는 스프레드시트가 포함됩니다. 제가 언급하지 않은 좋은 프로그램이 있다면 댓글로 알려주세요.