셸의 유틸리티 종속성

나는 모든 *nix 운영 체제의 "레이어" 아키텍처가 커널 셸 유틸리티("인사이드 아웃")라는 것을 알고 있습니다.

그러나 실제로는 그렇지 않습니다. 모든 것이 커널 위에서 실행되며, 쉘이 아닌 스크립트 "유틸리티"에는 쉘이 필요하지 않으므로 특정 쉘에 의존하지 않습니다.

일부 프로그램에는 Wayland 합성기가 필요한 Wayland 클라이언트와 같은 다른 프로그램이 필요합니다. 그러나 관련된 껍질의 일반적인 계층화는 없습니다.

나는 "shell"이 Unix 시스템에서 로그인 쉘로 사용되는 특정 쉘을 참조한다고 가정합니다.

컴퓨터의 소프트웨어는 특정 셸에 의존할 가능성이 높지만 개인 로그인 셸로 사용하는 셸에는 의존하지 않습니다(즉, 로그인 셸에만 의존하지 않습니다).왜냐하면이것이 로그인 쉘입니다).

스크립트로(또는 부분적으로 스크립트로) 구현되는 유틸리티는 예를 들어 다른 쉘을 사용하여 작업을 수행할 수 있지만 로그인 쉘이 예를 들어 더 난해한 쉘인 경우 /bin/shPython 스크립트와 마찬가지로 완전히 동일하게 작동합니다. 어떤 쉘을 사용하든 관계없이 모든 사람에게 동일합니다.bashzshyash

Unix는 다중 사용자 운영 체제이므로 명령줄 유틸리티와 그래픽 응용 프로그램은 사용자가 어떤 명령줄 셸을 사용하든 관계없이 동일한 방식("파이프라인", 즉 유틸리티 실행 구문)으로 작동합니다. 약간 다를 수 있지만 모든 사용자의 셸에서 일관됩니다.)

유틸리티 프로그램의 예를 들어보자사용쉘 스크립트, firefox일부 시스템의 실행 파일을 참조하십시오(부팅 파일일 수 있음).실제 firefox바이너리). OpenMPI와 같은 일부 유형의 컴파일러는 실제 컴파일러 주변의 쉘 스크립트 래퍼로 구현됩니다. 마찬가지로, 이를 수행하는 프로그램은 사용자가 로그인 쉘로 사용하는 쉘에 관계없이 동일한 방식으로 작동합니다.

반면에, 예를 들어 작성된 쉘 스크립트는 다음과 같습니다.zsh ~하지 않을 것이다다른 쉘에서 실행될 때 안정적으로 작동합니다. 스크립트의 인터프리터를 다른 스크립트로 바꾸면 스크립트가 손상될 가능성이 높으므로 이는 놀라운 일이 아닙니다(예를 들어 Ruby 인터프리터를 사용하여 Perl 스크립트를 실행하는 것은 실패할 수 있음).