/etc/profile.d의 스크립트는 무엇을 합니까?

이러한 파일이 Bash 시작에도 중요하다면 왜 /etc/profile의 일부가 아닌가?

"왜 그것들을 하나의 거대한 스크립트로 결합하지 않습니까?"를 의미한다면 대답은 다음과 같습니다.

1. 왜냐하면 스크립트를 담당하는 사람에게는 유지 관리가 악몽이 될 것이기 때문입니다.
2. 스크립트를 독립 모듈로 로드하면 전체 시스템이 보다 동적으로 조정될 수 있으므로 다른 스크립트에 영향을 주지 않고 개별 스크립트를 추가하고 제거할 수 있습니다. 등.
3. /etc/profile을 통해 로드되기 때문에 동일한 방식으로 bash "프로필"의 일부가 됩니다.

이러한 파일이 Bash 시작에 중요하지 않은 응용 프로그램별 시작 파일인 경우 왜 시작 프로세스의 일부입니까? 설정이 포함된 특정 응용 프로그램이 실행될 때만 실행되지 않는 이유는 무엇입니까?

제 생각에는 이것은 더 넓은 디자인 철학에 관한 질문이므로 두 가지로 나누어 보겠습니다. 첫 번째 질문은 쉘 환경 사용의 가치와 적절성에 관한 것입니다. 긍정적인 가치가 있나요? 예, 유용합니다. 모든 구성 문제에 대한 최상의 솔루션입니까? 아니요, 하지만 간단한 매개변수를 관리하는 데 매우 효과적이며 널리 인식되고 이해되고 있습니다. 대조적으로, 이러한 것들을 이기종으로 구성하기로 결정하면 $PATH는 별도의 독립 실행형 도구로 관리될 수 있고, 선호하는 도구(예: $EDITOR)는 sqlite 파일 어딘가에 있을 수 있으며, $LC lang 항목은 sqlite 파일에 있을 수 있습니다. 장소 등에서 다른 사용자 정의 형식을 사용합니다. 환경 변수만 사용하고 /etc/profile.d갑자기 더 단순해 보이지 않나요 ? 환경 변수의 5가지 공통 측면을 이해하기 위해 완전히 다른 5가지 메커니즘을 배우는 대신 환경 변수가 무엇인지, 어떻게 작동하고 사용하는지 이미 알고 있을 것입니다.이름을 적절하게 지정하세요."환경".

두 번째 질문은 "스타트업은 적절한 시기인가?"로, 그다지 효율적이지 않다는(사용할 수도 있고 사용하지 않을 수도 있는 모든 데이터 등) 반론을 제기한다. 하지만:

• 실제로는 그렇게 많은 데이터가 아닙니다. 부분적으로는 올바른 생각을 가진 사람이 몇 가지 간단한 매개변수를 처리하는 데 데이터를 사용하지 않을 것이기 때문입니다(애플리케이션을 구성하는 다른 방법이 있기 때문입니다).
• 현명하게 사용한다면 자주 호출되는 항목에 대해 호출될 때마다 일부 파일에서 기본 $CFLAGS 등을 설정하는 것은 gcc비효율적입니다. 관련된 메모리 양도 극소량이라는 점을 명심하세요.
• 시스템적인 내용이 포함될 수도 있고, 여러 응용 프로그램이 포함될 수도 있으며, 셸은공통점.

이 목록에 더 많은 것을 추가할 수 있지만, 이를 통해 이 문제의 장단점에 대한 아이디어를 얻을 수 있기를 바랍니다. 주요 "장점"과 주요 "단점"은 전역 네임스페이스라는 것입니다.

이러한 파일은 애플리케이션별로 다르지만 애플리케이션이 시작될 때가 아니라 셸이 시작될 때 생성됩니다. 구성 디렉토리는 다른 많은 곳에서 찾을 수 있는 것과 동일한 이유로 여기에서 사용됩니다. 이를 통해 애플리케이션이나 소프트웨어 패키지가 구성을 수정할 수 있습니다. 분할 구성이 없으면 사용자가 수정할 수도 있는 단일 구성 파일의 여러 패키지를 관리/업데이트하려고 하면 오류가 발생하기 쉽고 혼란스럽기 때문에 이는 불가능합니다.

또한 /etc/profile이것은 bash뿐만 아니라 모든 쉘에서 제공된다는 점에 유의하십시오. Bash 관련 구성 파일은 bashrc이며 대화형 셸에서만 사용할 수 있습니다.

조던의 대답부정확하다. /etc/profile모든 껍질이 여기에서 유래하는 것은 아닙니다. 지적하신 대로 에서 만든 것이 아닙니다 csh. tcsh- 잘 모르겠습니다 zsh. Korn Shell( ), BASH( ) sh등 Bourne Shell( ) 파생물에서 파생되었습니다 . Borne Shell 파생 제품만 사용하는 사람들은 다른 쉘이 존재한다는 사실을 잊어버리는 경향이 있습니다 . 그들은 "모든 사용자"에게 작동할 것으로 기대하는 것을 추가한 다음 이상한 C Shell 사용자(우리는 이상한 사람입니다)가 .kshbashcsh/etc/login/etc/profile/etc/profile

그럼에도 불구하고 사람들은 다른 Borne Shell 파생 상품이 존재한다는 사실을 잊어버리는 경향이 있습니다. bash또는 를 사용하면 변수를 정의하고 같은 줄에 내보내는 등 Bourne Shell에서 유효하지 않은 구문을 ksh자유롭게 추가할 수 있습니다 . /etc/profile그런 다음 실행 가능한 스크립트를 얻었 #!/bin/sh지만 해당 구문이 엉망입니다. /etc/profileBourne Shell 호환 구문을 준수해야 합니다.

다시 말하지만, 직접 사용해야 한다고 주장해야 합니다 .profile( .bash_profilebash 구문을 원하면 사용하세요). 추가 입력이 필요할 수 있지만 한 번에 추가 입력이 필요합니다. 참조 ${HOME}이며 같지 않습니다 ~. 특정 Unix 버전에서는 cron 작업이 각 sh라인 아래에서 실행되므로 다양한 UNIX 버전에서 작업하는 경우 Bourne 쉘 호환성을 유지하는 것이 실제로 도움이 됩니다. 시스템 관리자로서 저는 다른 사람들이 Bourne Shell 호환성 문제를 해결하도록 몇 번이나 도왔는지 모릅니다 .Makefilesh.profile.profile

Linux에서는 실행 시 실행에 사용된 경로를 찾고 (이론적으로) Bourne Shell이 ​​지원하는 경로로만 제한되는 /bin/sh링크입니다 . /bin/bash다시 말하지만, viLinux에서는 vim자신을 제한합니다. 때때로 기능이 "흘려지는" 것을 볼 수 있습니다. 때때로 지원되는 작업을 수행하는 vim척 하지만 작성자가 "vi 하위 호환성" 모드에서 비활성화하는 것을 잊어버렸기 때문에 지원되지 않습니다 . Pretend에 유사한 "침투" 기능이 있다고 해도 나는 놀라지 않을 것입니다. 일부 기능이 "Linux의 Borne Shell에서 작동"하지만 System V 또는 BSD 기반 UNIX(AIX, OpenBSD 등)에서는 작동하지 않더라도 놀라지 마십시오.vivimvivimbashsh