2. Philosophy

셸 스크립트 프로그래밍은 일부 Unix 시스템 관리자들 사이에서 좋지 않은 평가를 받고 있습니다. 이는 보통 두 가지 이유 중 하나 때문입니다:

• 해석된 프로그램이 실행되는 속도를 C 프로그램이나 심지어 해석된 Perl 프로그램과 비교하여 나타냅니다.
• 간단한 배치 작업 유형의 셸 스크립트는 쉽게 작성할 수 있기 때문에 품질이 떨어지는 셸 스크립트가 많이 있습니다.

이 때문에 좋은 셸 스크립트를 만드는 것과 관련된 특정 마초주의가 존재합니다. 예를 들어, Perl에 비해 속도 면에서 크게 뒤지지 않으면서도 CGI 프로그램으로 사용할 수 있는 스크립트(많은 경우 속도만이 유일한 기준이기는 하지만, 둘 다 C에 비해서는 떨어집니다). 훌륭하고 깔끔하며 빠른 셸 스크립트에는 여러 가지 요소가 있습니다.

•  가장 중요한 기준은 명확하고 가독성 있는 레이아웃이어야 합니다.
• 두 번째는 불필요한 명령어를 피하는 것입니다.

명확한 레이아웃은 "흑마법"처럼 보이는 셸 스크립트와 쉽게 유지 관리하고 이해할 수 있는 스크립트의 차이를 만듭니다.
간단한 스크립트라면 큰 문제가 되지 않는다고 생각할 수도 있지만, 다음 두 가지 사항을 염두에 두어야 합니다.

1. 첫째, 간단한 스크립트는 예상보다 더 자주 크고 복잡한 스크립트로 커질 수 있습니다.
2. 둘째, 스크립트가 어떻게 작동하는지 아무도 이해하지 못하면 남은 기간 동안 남은 평생 동안 직접 유지 관리해야 합니다!

셸 스크립트는 특히 들여쓰기가 잘 안 되는 경우가 많은데, 주요 제어 구조가 if/then/else와 루프이기 때문에 스크립트의 동작을 이해하려면 들여쓰기가 매우 중요합니다.

많은 셸 스크립트의 주요 약점 중 하나는 다음과 같은 줄입니다:

cat /tmp/myfile | grep "mystring"

로 훨씬 빠르게 실행됩니다:

grep "mystring" /tmp/myfile

제 시스템에서는 75600바이트의 비교적 작은 /bin/grep 실행 파일을 로드하고, 전송을 위해 메모리에서 파이프를 열고, 이보다 더 작은 9528바이트의 /bin/cat 실행 파일을 로드하여 실행하고, 파이프의 입력에 연결하여 실행해야 합니다.

물론 이런 종류의 작업은 OS가 존재하는 이유이며 일반적으로 매우 효율적으로 수행됩니다. 하지만 이 명령이 여러 번 반복 실행되는 경우, 특히 스크립트 자체에 큰 문제가 없으면서도 다른 요인으로 인해 속도가 느려지는 CGI 환경에서는 cat 실행 파일을 찾아서 로드하고 파이프를 설정했다가 해제하지 않아도 되기 때문에 약간의 차이를 만들 수 있습니다. 일부 유니티는 프로세스를 로드하고 실행한 후 다시 지우는 이른바 '프로세스 구축 및 해체'에 다른 유니티보다 더 효율적입니다. 하지만 이 작업을 아무리 잘 수행하는 유닉스라고 해도 이 작업을 전혀 수행하지 않는 것이 좋습니다.

그 결과, 일부 커뮤니티에서는 '심각한 셸 스크립트에서 cat이라는 단어를 가장 무분별하게 사용한 사람에게 주는 상(The Award For The Most Gratuitous Use Of The Word Cat In A Serious Shell Script)'으로도 알려진 Useless Use of Cat Award (UUoC)에 대한 언급이 comp.unix.shell 뉴스 그룹에서 가끔씩 언급되는 것을 볼 수 있습니다. 이것은 순전히 동료들이 서로를 견제하고 일이 제대로 이루어지도록 하기 위한 방법입니다.

이제 다른 이야기로 넘어가죠: 셸 스크립트는 그 특성상 소스를 닫을 수 없으므로 너무 가깝게 느끼지 마세요. 고객에게 셸 스크립트를 제공하면 고객은 이를 아주 쉽게 검사할 수 있습니다. 따라서 셸 스크립트를 넘겨주는 사람이 누구든 검사할 수 있다는 것을 받아들이는 것이 좋으며, GPL2를 활용하여 사람들이 무료로 피드백과 버그 수정을 제공하도록 장려하세요!