원 라이너 vs 스크립트

나는 한 줄짜리 스크립트 대신 스크립트를 작성하는 것에 대한 경멸을 표현하는 많은 질문과 답변과 의견을 발견했습니다. 그래서 알고 싶습니다.

• 언제 그리고 왜 "한 줄짜리"가 아닌 독립형 스크립트를 작성해야합니까? 혹은 그 반대로도?

• 둘의 유스 케이스와 장단점은 무엇입니까?

• 일부 언어 (예 : awk 또는 perl)가 다른 언어 (예 : python)보다 한 줄짜리에 더 적합합니까? 그렇다면 왜 그렇습니까?

• 개인적인 취향의 문제일까요, 아니면 특정 상황에서 하나 또는 다른 것을 쓸 좋은 이유가 있습니까? 그 이유는 무엇입니까?

정의

• one-liner: 쉘 명령 행에 직접 입력하거나 붙여 넣은 명령 시퀀스 . 종종 관련된 파이프 라인 및 / 또는 같은 언어의 사용 sed, awk, perl, 및 / 또는 도구와 같은 grep또는 cut나 sort.

  길이와 형식은 관련이없는 것이 정의 특성 인 명령 줄에서 직접 실행됩니다. "한 줄짜리"는 모두 한 줄에있을 수도 있고 여러 줄을 가질 수도 있습니다 (예 : 가독성을 높이기 위해 줄 바꿈 및 들여 쓰기가있는 sh for loop 또는 내장 awk 또는 sed 코드).

• script: 해석 된 언어로 된 명령 시퀀스를 파일에 저장 한 다음 실행합니다. 스크립트는 한 언어로만 작성되거나 다른 언어를 사용하는 여러 "한 줄짜리"주위의 셸 스크립트 래퍼 일 수 있습니다.

나는 (나중에 게시 할) 나 자신의 대답을 가지고 있지만, 이것이 내 개인적인 의견이 아니라 주제에 대한 정식 Q & A가되기를 원합니다.

실제 경험을 바탕으로 한 또 다른 반응.

프롬프트에서 바로 작성할 수있는 "버려지는"코드 인 경우 하나의 라이너를 사용합니다. 예를 들어, 나는 이것을 사용할 수 있습니다 :

for h in host1 host2 host3; do printf "%s\t%s\n" "$h" "$(ssh "$h" uptime)"; done

코드를 저장할 가치가 있다고 판단되면 스크립트를 사용합니다. 이 시점에서 파일 상단에 설명을 추가하고, 오류 검사를 추가하고, 버전 관리를 위해 코드 저장소에서 확인할 수도 있습니다. 예를 들어, 서버 집합의 가동 시간을 확인하는 것이 여러 번 반복해서 사용할 유용한 기능이라고 결정한 경우 위의 한 줄짜리가 다음과 같이 확장 될 수 있습니다.

#!/bin/bash
# Check the uptime for each of the known set of hosts
########################################################################
#
hosts=(host1 host2 host3)

for h in "${hosts[@]}"
do
    printf "%s\t" "$h"
    uptime=$(ssh -o ConnectTimeout=5 -n "$h" uptime 2>/dev/null)
    printf "%s\n" "${uptime:-(unreachable)}"
done

일반화, 말할 수

• 짧막 한 농담

  • 특정 일회성 목적으로 작성된 간단한 코드 (예 : "몇 가지"문)
  • 필요할 때마다 빠르고 쉽게 작성할 수있는 코드
  • 일회용 코드

• 스크립트

  • (아마도) 한두 번 이상 사용될 코드
  • "몇 가지"이상의 문장이 필요한 복잡한 코드
  • 다른 사람이 관리해야하는 코드
  • 다른 사람들이 이해할 수있는 코드
  • 무인으로 실행할 코드 (예 : from cron)

유닉스 SE 에 대한 많은 질문이 하나의 라이너로 특정 작업을 수행하도록 요청합니다. 위의 예제를 사용하면 두 번째는 첫 번째보다 훨씬 이해하기 쉬우므로 독자는 더 많은 것을 배울 수 있습니다. 하나의 솔루션은 다른 솔루션에서 쉽게 파생 될 수 있으므로 가독성을 높이기 위해 (미래의 독자를 위해) 가장 간단한 솔루션 이외의 코드를 한 줄에 넣지 말아야 할 것입니다.

다음과 같은 경우에 스크립트를 작성하십시오 .

• 더 많은 코드가 필요합니다
• 당신은 가독성을 중요하게 생각합니다
• 코드의 기능을 보여주기 위해 주석을 추가하는 것이 필요 / 유용하다
• 당신은 매개 변수를 전달해야합니다
• 스크립트가 자체 환경 (변수 등)에서 실행되기를 원합니다.
• 좀 더 복잡한 목적으로 코드를 재사용하거나 적응시킬 것입니다.

다음과 같은 경우 하나의 라이너를 작성하십시오 .

• 적은 양의 코드 만 필요
• 현재 쉘에 정의 된 변수에 액세스하려고합니다
• 빠르고 더러운 솔루션이 필요합니다

필요한 일련의 명령이 상당히 짧거나 더 큰 파이프 라인 또는 명령 별칭의 일부로 사용할 수있는 결과를 생성하는 경우 좋은 단일 라이너 일 수 있습니다.

기본적으로 원 라이너는 일반적으로 노련한 시스템 관리자가 문제와 사용 된 명령 모두에 익숙해 져 너무 많은 생각없이 그 자리에서 쓸 수 있다고 생각합니다.

하나의 라이너가 너무 길어 지거나 매우 단순한 조건부 또는 루프보다 많은 경우 일반적으로 가독성을 위해 여러 줄 스크립트 또는 셸 함수로 작성하는 것이 좋습니다. 또한 반복해서 사용하기 위해 작성하거나 다른 사람들이 사용하고 문제가 될 수있는 경우 솔루션을 명확한 (er)에 작성하는 데 시간을 투자해야합니다. 스크립트 양식.

파이썬에서 들여 쓰기는 구문의 일부이므로, 하나의 라이너를 작성하면 문자의 언어 기능을 완전히 사용할 수 없습니다.

Perl과 awk one-linner는 종종 정규 표현식의 원시 힘을 사용하는 것에 관한 것입니다. 그러나 일부는 정규 표현식을 쓰기 전용 언어라고 부릅니다. 여러 줄로 된 스크립트를 작성하면 주석에 특정 정규식이 수행해야하는 작업을 설명 할 수 있습니다. 이는 6 개월 동안 다른 작업을 수행 한 후 스크립트를 다시 볼 때 매우 유용합니다.

이것은 본질적으로 매우 의견에 근거한 질문입니다. 수용 가능한 복잡성의 양과 가독성과 압축성 간의 균형을 측정하는 것과 관련이 있기 때문입니다. 이 모든 것은 개인적인 판단의 문제입니다. 언어의 선택조차도 개인적인 문제에 따라 달라질 수 있습니다. 이론적으로 특정 언어가 특정 문제에 대해 최적 일 수 있지만 익숙하지 않고 다른 언어로 문제를 해결하는 방법을 이미 알고 있다면 솔루션은 기술적으로 다소 비효율적 일 수 있지만 작업을 신속하고 최소의 노력으로 수행하기 위해 익숙한 언어.

최고 는 종종 선의 원수이며 , 이것은 여기에 매우 많이 적용됩니다.

그리고 Perl에 익숙하다면 이미 TMTOWTDI에 대해 들어 보셨을 것입니다.

이것은 개인적인 의견입니다. 소금 한알로 가져 가라.

1. 명령이 80 자 이내 인 경우 한 줄짜리 줄을 사용하십시오. 긴 명령 행은 작업하기가 어렵습니다. 재발의 문제도 있습니다. # 2 참조

2. 명령을 두 번 이상 실행해야하는 경우 스크립트를 사용하십시오. 그렇지 않으면 조건 # 1이 충족되면 하나의 라이너를 사용하십시오.

3. 이것은 매우 주관적이지만 그렇습니다. 쉘, Perl 또는 awk가 원 라이너 용 도구로 간주됩니다.
4. # 1, # 2, # 3을 참조하십시오.

하나의 라이너를 임시 개발 도구로보고 원하는대로 할 때까지 반복적으로 편집하거나 하위 명령의 미묘한 작동 방식을 이해합니다.

그런 다음 조사중인 주제의 텍스트 파일에 주석을 달고 주석을 추가하거나 개인 저장소 PATH에 넣을 스크립트로 정리하여 추가 수정, 매개 변수화 등을 할 수 있습니다. 일반적으로 다른 변경 사항이 없거나 스크립트를 다시 사용하지 않더라도 한 줄은 더 읽기 쉽습니다.

쉘 히스토리를 5000 라인 이상으로 설정했으며 터미널마다 별도의 히스토리를 사용하고 원격으로 로그인 할 때마다 로그인했습니다. 나는이 역사에서 몇 주 전에 개발 한 단 한 줄의 명령을 찾지 못하고 다시 전략이 필요하다고 생각하지 않았습니다.

때로는 전체 명령 그룹이 일부 하드웨어 구성과 같은 작업을 수행해야합니다. 결국 나는 그것들을 역사에서 모두 복사하고, 최소한으로 정리하고, RUNME내가 한 일에 대한 메모처럼 셸 스크립트에 추가 할 뿐만 아니라 다른 사람들이 다시 사용할 수 있도록 거의 준비했습니다. (그래서 나는 그러한 고통을 구성하기 위해 GUI 만 제공하는 도구를 찾는 이유입니다.) 나는 종종 한 번만 할 것으로 예상되는 것과 같이 효율성이 엄청나게 향상되어 5 번 더 수행해야한다는 것을 알았습니다. .

팀원들이 한 번 이상 수행해야하는 작업 (예 : "워크 플로"또는 "파이프 라인")과 문서화해야하는 일회성 작업 (일반적으로)에 대한 스크립트를 작성하고 싶습니다. 예를 들어 "일부 데이터 세트에서 특정 항목을 수정하여 잘못 제공된 데이터를 수정하십시오"). 그 외에도 "한 줄짜리"또는 스크립트는 그다지 중요하지 않습니다.

워크 플로를 제대로 문서화하지 않으면 (스크립트 또는 이와 동등한 방식으로) 프로젝트에 새로운 직원을 소개하기가 어려워지고 사람들을 프로젝트 외부로 전환하기가 더 어려워집니다. 또한 모든 유형의 감사를 어렵게 만들고 버그를 추적하는 것이 불가능할 수 있습니다.

프로그래밍에 사용되는 언어에 관계없이 적용됩니다.

다른 작업장에서는 비슷하거나 다른 관습이나 기대치가있을 수 있으며 심지어 적어 두었을 수도 있습니다.

집에서는 자신이 느끼는대로 행동합니다.

내가 뭔가 할 예를 들어, 나는 빨리 스크립트를 작성 적지 않은 U & L 질문하거나 답변을 제출하기 전에 같은 쉘에서 난은 "실행하기 전에 명령의 명령이나 세트의 개별 구성 요소를 테스트해야 할 때마다 레알".

또한 반복 작업에 대한 스크립트를 작성합니다.

• 내 OpenBSD 시스템 및 설치된 모든 패키지 업데이트 (이것은 간단한 명령으로 수집 된 세 개의 짧은 명령과 정리를위한 다른 것들 중 일부에 해당함) 또는
• 내 시스템을 오프 사이트 스토리지에 백업 (본질적으로 단일 명령이지만 상당히 많은 하우스 키핑 및 스크립트를 사용하여 스냅 샷 등에서 차이점을 처리 할 수 ​​있으며 다른 시스템에서 미묘하게 다르게 작동해야합니다. cron 작업에서 실행) 또는
• 메일 가져 오기 (기본적으로 단일 명령이지만 cron 작업으로 호출 할 때와 명령 줄에서 사용할 때 다르게 작동하기를 원하며 어떤 상황에서는 메일을 가져 오려고 시도해서는 안되며 파일에 대한 짧은 로그 메시지).

나는에 대한 쉘 기능 (매우 드물게 별칭)을 사용 편의를 (기본적으로 특정 명령에 옵션을 추가 할 예를 들어, 대화 형 쉘에 -F대한 ls) 또는 일부 명령의 전문 변화를 만들기위한 ( pman여기하는 것은입니다 man명령이 예를 들어, POSIX 매뉴얼에서만 보이는) .

이것에 대해 소수의 견해를 가지고있는 것 같습니다.

"스크립트"라는 용어는 의도적으로 혼동됩니다. 제거하십시오. 이 소프트웨어 는 당신이 단독으로 사용하는 경우에도이 작성하는 bash과 awk.

팀 내에서 도구 (github / gitlab / gerrit)로 시행되는 코드 검토 프로세스를 사용하여 소프트웨어를 작성하는 것을 선호합니다. 이것은 버전 제어를 보너스로 제공합니다. 시스템이 여러 개인 경우 연속 배포 도구를 추가하십시오. 대상 시스템이 중요한 경우 일부 테스트 스위트. 나는 이것에 대해 종교적이지 않지만 혜택과 비용을 평가합니다.

관리자 팀이있는 경우 가장 간단한 vim /root/bin/x.sh것은 변경 관련 통신, 코드 가독성 및 시스템 간 배포 측면에서 재난입니다. 하나의 심각한 오작동은 "무거운"프로세스보다 시간 / 비용이 더 많이 듭니다.

나는 그 "무거운"프로세스를받을 자격이없는 것을 위해 실제로 하나의 라이너를 선호 합니다. 쉘 히스토리를 효과적으로 사용하는 방법을 알고 있다면 몇 번의 키 조작으로 빠르게 재사용 할 수 있습니다. 관련없는 시스템 (예 : 다른 고객)간에 쉽게 붙여 넣기

1 개의 라이너와 검토 된 소프트웨어 ( "스크립트")의 중요한 차이점 : 하나의 라이너를 실행할 때 책임은 전적으로 귀하에게 있습니다. 당신은 "무엇을 따라하는 것은 내 잘못이 아니야, 내가 이해하지 않고 그것을 실행, 난 그냥이 한 줄의 어딘가에 발견"자신에게 말할 수 없다 - 당신이 있도록, 미 검토 및 검증되지 않은 비트의-소프트웨어를 실행하는 것을 알고 있다 당신의 잘못. 결과를 예측할 수있을 정도로 작아야합니다. 그렇지 않으면 저주를 받으십시오.

때로는이 단순한 접근 방식이 필요하며 한 줄의 텍스트에 막대를 설정하면 실제로 (검토 된 코드와 검토되지 않은 코드의 경계) 잘 작동합니다. 내 원 라이너 중 일부는 끔찍하게 길어 보이지만 효과적으로 나를 위해 일합니다. 내가 그들을 움켜 쥐고 더 많은 후배들에게 밀리지 않는 한, 괜찮습니다. 공유해야하는 순간-표준 소프트웨어 개발 프로세스를 거칩니다.

나는 질문의 첫 부분이 내포 한 의미에 다소 충격을 받았다고 말해야한다. 유닉스 스크립팅 언어는 본격적인 프로그래밍 언어이며, 프로그래밍 언어는 언어입니다 . 즉, 인간 언어와 마찬가지로 무한히 유연하고 유연합니다. 그리고 "무한한 가단성과 유연성"의 특징 중 하나는 무언가를 표현할 수있는 "올바른 방법"이 거의 없다는 것입니다. 그래서, 그래, 물론 그것은 개인적인 취향의 문제, 그리고 아무것도 잘못은 그와 함께있다. 무언가를하는 유일한 방법이 있다고 말하는 사람은

옛날 옛적에, 내 자신 ~/bin은 내가 쓴 "유용한"작은 스크립트들 로 가득했습니다 . 그러나 나는 그들 대부분이 내가 쓴 날에 사용되었다는 것을 깨달았습니다. 따라서 시간이 지날수록 bin디렉토리가 작아 집니다.

스크립트 작성에 문제 가 있다고 생각하지 않습니다 . 본인이나 다른 사람이 다시 사용할 수 있다고 생각되면 반드시 스크립트를 작성하십시오. 이를 위해 지원 가능한 스크립트를 "적절하게 엔지니어링"하려면 반드시 그렇게하십시오. (아무도 사용하지 않더라도 작성하는 것이 좋습니다.)

이유는 더 이상 스크립트를 작성하지 않습니다 (그리고 "한 줄짜리"를 선호합니다).

• bin디렉토리 혼란은 비용이 든다. 나는 그들이 실제로 거기에 속하지 않는 한 더 이상 물건을 넣지 않습니다.
• 내가 사용하는 스크립트 언어는 내가하는 것이 언어입니다 사용 ; 나는 지금까지 그들과 함께 정말 쉬워요. 필요할 때마다 한 줄짜리를 바꾸는 것이 일처럼 느껴지지 않습니다. 나는 (재) 타이핑 부담을 줄이기 위해 스크립트를 유지하고 저장하고 사용하라는 명령을 느끼지 않습니다. (어떤 시점에서 재 입력 부담은 스크립트가 무엇인지 기억하는 기억 부담보다 적습니다.)
• 사물을 바꾸는 것이 부담처럼 느껴지지 않는 또 다른 이유는 명령 기록입니다. 스크립트를 매일 사용하더라도 스크립트로 작성하지 않은 하나의 라이너가 많이 있지만 다시 입력 할 필요는 없습니다. 나는 단지 역사에서 그들을 회상한다. 그런 식으로 그들은 일종의 가난한 사람의 스크립트 또는 별칭입니다.

나는 "한 줄짜리 (one-liner)"에 대한 요청이 사실 "소리 물린"에 대한 요청이라고 믿습니다.

저널리즘의 맥락에서, 소리 바이트는 말하는 사람의 말의 본질을 포착하고 정보를 요약하는 데 사용되는 짧은 문구 또는 문장으로 특징 지어집니다 ...

사람들은 질문에 대한 해결책을 보여주는 가장 짧은 코드를 원하고 요청합니다.

때때로, 말을 "소리 물린"으로 줄일 수있는 방법이없고 스크립트를 짧은 "한 줄짜리"로 줄이는 것이 불가능할 수도 있습니다. 이러한 경우 가능한 유일한 대답은 스크립트입니다.

그리고 일반적으로 "소리 물린"은 전체 연설의 좋은 대체물이 아닙니다. 따라서 "하나의 라이너"는 일반적으로 아이디어를 전달하거나 그 아이디어의 실제적인 예를 제공하는 것만으로도 좋습니다. 그런 다음 아이디어가 이해되면 스크립트에서 아이디어를 확장 (적용)해야합니다.

따라서 아이디어 나 개념을 전달하기 위해 "한 줄짜리"를 작성하십시오.

일반 코드를 단일 라이너가 아닌 전체 스크립트로 작성하십시오.

당신은 "스크립트에 대한 두려움과 경멸"에 대해 묻습니다. 이것은 종종 대답이 말하는 Q + A 상황 때문입니다. 이 단계와 이것이 필요하지만 한 줄에 넣을 수도 있습니다 (따라서 붙여 넣기하여 긴 간단한 명령으로 사용할 수 있습니다).

빠르고 더러운 복사 붙여 넣기 솔루션으로 Q가 더 잘 제공되는지 또는 "좋은"스크립트가 Q가 정확히 이해해야하는 것인지 추측 할 수 있습니다.

여기에 많은 장단점이 사실이지만 여전히 요점을 놓치고 있습니다. 심지어 Q의 정의가 도움이되지 않는다고 말하고 싶습니다.

쉘 히스토리 파일은 "하나의 라이너"이지만 여전히 저장됩니다. bash 기능 operate-and-get-next (C-o)을 사용하면 반자동으로 반복 할 수도 있습니다.

나는 언급 된 단어 기능을 거의 볼 수 없다 . 이것이 "스크립트"와 "하나의 라이너"를 모두 저장하는 방법입니다. 그리고 몇 번의 키 입력으로 두 형식간에 전환 할 수 있습니다. 복합 명령은 종종 양쪽에 맞게 할 수 있습니다.

history -r file기본 히스토리 파일뿐만 아니라 모든 파일에서 하나 이상의 명령 행 (및 주석)을 읽는 방법입니다. 최소한의 정리 만하면됩니다. 명령 행의 (일부) 버전을 검색하기 위해 큰 히스토리 파일 크기 및 히스토리 검색에 의존해서는 안됩니다.

기능은 비슷한 방식으로 정의해야합니다. 우선, thisfunc() {...}홈 디렉토리에 "functions"파일을 넣고 소싱하십시오. 예, 이것은 약간의 오버 헤드이지만 일반적인 솔루션입니다.

모든 명령 줄과 모든 스크립트 변형을 별도의 파일에 저장하면 파일 시스템 블록의 (이론적이지만 객관적인) 낭비입니다.

하나의 라이너는 그 자체로 빠르고 더러운 것이 없습니다. 그것은 조금 찡그린 복사-붙여 넣기 부분과 우리를 위해 명령 기록에 의존하는 방법입니다.

@sitaram : 하나의 라이너는 실제로 하나의 비선형적인 기능을 가지고 있습니다 : 세방 라인, 개행, 4 개의 유틸리티 호출 – 그중 2 개는 "프로그램"sed. 나는 원래의 펄 스크립트가 더 멋지게 보이고 더 빨리 달렸으며 60 줄로 퍼져서 바이트를 낭비하지 않았다고 생각합니다. 그리고 펄은 또한 당신이 꽤 짜낼 수 있습니다.

나를 위해, 그것은 피해야 할 일종의 라이너입니다. 커맨드 라인에 붙여 넣기를 원하십니까? 아니요, 스크립트 나 함수에 상관없이 파일에 파일을 저장하면 2 줄 또는 3 줄짜리 줄 바꿈을 사용하여 멋지게 보이게 할 수 있습니다.

10 분. 나중에 : 나는 "두 sed 프로그램"이라고 말할 수 있는지 또는 "두 sed 대체 / 호출"인지 확인하고 싶었습니다. 그러나 시타 람의 대답은 사라졌습니다. 내 대답은 여전히 ​​희망적입니다.