유닉스 계열 시스템에 여러 개의 쉘이있는 이유는 무엇입니까?

나는 유닉스의 기초를 배우기 시작했고 유닉스와 같은 시스템에 왜 그렇게 많은 쉘이 있는지 궁금해하기 시작했다. 유닉스 환경의 고급 프로그래밍 책 에서 :

쉘은 사용자 입력을 읽고 명령을 실행하는 명령 행 인터프리터입니다. 쉘에 대한 사용자 입력은 보통 터미널 (대화식 쉘) 또는 때로는 파일 (쉘 스크립트)에서옵니다.

그리고 그 책은 Bourne shell, Bourne-again shell, Cshell 등과 같은 많은 쉘 프로그램을 나열합니다. 내 질문은 기본적으로 여러 개의 쉘이 필요한 이유는 무엇입니까?

최신 UNIX 환경에서 사용되는 대부분의 셸은 POSIX sh 사양을 준수합니다. POSIX sh는 원래 Bourn 쉘에서 파생 된 원래 Korn 쉘 (ksh88)에서 파생되었지만 POSIX sh는 심지어 ksh88 기능의 작은 서브 세트 만 지정합니다. 최소 요구 사항 만 구현하는 셸에는 가장 사소한 스크립트를 제외한 모든 스크립트를 안전하고 합리적인 방식으로 작성하는 데 필요한 많은 기능이 없습니다. 예를 들어, 지역 변수와 배열은 비표준 엑스트라입니다.

따라서 첫 번째 이유는 추가 기능으로 셸을 확장하는 것입니다. 다른 껍질은 다른 것들에 중점을 둡니다. 예를 들어 Zsh는 고급 대화식 기능에 중점을두고 있으며 ksh93 (현재 "원래"korn 쉘)은 강력한 프로그래밍 기능 및 성능에 중점을 둡니다. Dash와 같은 매우 작은 쉘조차도 로컬 변수와 같은 비표준 엑스트라를 최소한 몇 개 추가합니다.

추가 기능은 거의 상호 운용성이 거의 없습니다. ksh88 기능 세트의 대부분은 확장 된 글 로빙 구문과 같이 상호 운용성이 뛰어나지 만 비표준 기능에서는 보장 할 수 없으며 이식 가능한 방식으로 사용하기 위해 무엇을하고 있는지 실제로 알아야합니다.

두 번째 이유는 레거시입니다. / bin / sh에 대해 고대 비표준 구현을 사용하는 독점 유닉스가 여전히 많이 있습니다. 최근까지도 솔라리스는 여전히 Bourne을 디퓨 트로 사용했으며 현대적인 것으로 업그레이드하기보다는 가보 쉘을 유지하기로 결정했습니다. 이러한 시스템은 일반적으로 PATH 변수를 변경하거나 개별 스크립트 내에서 shebang을 변경하여 전환 할 수있는 다른 쉘과 함께 제공됩니다.

요약하자면. 종종 기본적으로 여러 쉘이 있습니다.

• 추가 기능, 특히 비 휴대용 추가 기능을 처리합니다.
• 종종 유지 관리되지 않는 레거시 스크립트를 처리합니다.
• 크기 / 성능. 임베디드 시스템에는 종종 mksh 또는 busybox sh와 같은 작은 쉘이 필요합니다.
• 라이센스 이유. AT & T ksh는 약 2000 년 전까지 독점 소프트웨어였습니다. 이것은 주로 Zsh 및 Bash와 같은 모든 ksh 유사 클론을 일으켰습니다.
• 다른 역사적 이유. 오늘날 인기가 높지는 않지만 scsh 및 es와 같은 언어를 다시 디자인하려는 급격한 시도가있었습니다. 많은 셸의 프로세스 대체 기능은 원래 rc (비트가 다른 구문)에서 왔으며 csh에서 괄호 확장입니다. 각기 다른 쉘은 일반적으로 미묘한 차이가 있거나 미묘한 차이가 있지만 사용 가능한 기능의 조합이 다릅니다.

사람들은 요구가 다르기 때문에 주어진 상황에서 귀하의 요구에 맞는 대안을 갖는 것이 좋습니다. 쉘은 그 자체로 도구 일 뿐이며 다른 의견으로는 대체 할 수 있어야합니다. 이것이 바로 Microsoft Windows가 선택한 것과는 달리 Unix / Linux의 힘입니다.

마찬가지로 ... 왜 이렇게 많은 텍스트 편집기가 있습니까? 이미 브라우저가있는 경우 사람들이 새로운 브라우저를 개발하는 이유는 무엇입니까? 왜 그놈, KDE, Xfce, LXDE, E17 등이 있습니까?

짧은 답변

이상한 라이센스 이력으로 인해 단일 엔티티가 Unix를 개발하지 않았습니다. 자원 봉사자와 기업 모두가 참여한 커뮤니티 프로세스였습니다. 이 엔티티는 항상 모든 도구를 공유하지는 않았으므로 별도의 쉘이 발생했습니다. 우리는 이것이 생산성에 반하는 것을 깨달았을 때, 사용중인 모든 쉘을 통합하기에는 너무 늦었습니다. 대신이 모든 쉘이 (이론적으로) 서로 호환 되도록하기위한 작업이 수행되었습니다 .

긴 대답은 복잡하고 유닉스 자체의 역사와 밀접한 관련이 있습니다. 이 페이지에서 단일 답변을 유지할 방법은 없지만 널리 문서화되어 있습니다. 유닉스 역사를 다루는 웹과 서적을 살펴보면 더 자세하고 정확한 답변을 찾을 수 있습니다.

다른 웹 브라우저가 존재하는 것과 같은 이유로 다른 쉘이 존재합니다. 모든 사람이 선호하고 일부 쉘에는 역사적인 수하물이나 운동량이 있습니다. 각각 다른 기능과 특유의 특징이 있습니다.

대부분 역사는 ...

Bourne은 (적절한) SysV Unix의 일부로 개발되었으며, BSD는 다음을 사용했습니다 csh. 나중에 bash는 Bourne 쉘 (및 ksh와 같은 개선 된 버전)의 오픈 소스 대안으로 개발되었습니다. POSIX 표준에서는 Bourne과 같은 쉘이 채택되었습니다. ksh는 호환되며 bash는 호환 될 수 있습니다.

쉘 좋아 csh하고 tcsh(명령 완료 등 부족)하지만, 원래 Bourne 쉘보다 대화 형으로 사용하는 것이 훨씬 쉽다 스크립트에 대한 끔찍한 ...

Unix 기반 임베디드 시스템과 같은 일부 환경에서는 스크립팅 기능, 크기 및 속도가 명령 완료와 같은 대화식 기능보다 중요하며 다양한 셸 유형이 사용되는 경향이 있습니다.

이식 가능한 스크립팅의 경우 POSIX 호환 Bourne-variant를 사용하고 확장을 피해야합니다.