~/.bashrc
내 Bash 에 대화형으로 사용하는 데 도움이 될 뿐만 아니라 스크립팅(별칭, 함수, 변수 등)에도 도움이 되는 광범위한 사용자 정의 기능이 있다고 가정해 보겠습니다 . 내 모든 스크립트에서 이 기능을 사용할 수 있기를 바라기 때문에 BASH_ENV
( ~/.bashrc
이렇게 하면 되는 것 같습니다.)
내 질문은 이것에 문제가 있습니까?
- 한 가지 문제는 내가 사용하는 타사 쉘 스크립트가 내 것과 작동할 수 있다는 것입니다
~/.bashrc
. 그러나 어쨌든 사용하기 전에 검토하기 때문에 관리 가능한 문제라고 생각합니다(또는 Github Stars 난해한 통계와 같은 것을 맹목적으로 신뢰하여 안전하다고 생각합니다).BASH_ENV
오작동할 수 있는 스크립트를 삭제하기 위해 가끔씩만 몸을 낮추십시오 . - 또 다른 문제는 속도이지만 솔직히 말해서 내 것은
~/.bashrc
그렇게 무겁지 않으며 속도를 원한다면 쉘 스크립트를 사용하지 않을 것입니다. - 또 다른 문제는 보안이다. 그러나 내가 어떤 setuid 또는 특권적 지위를 가지고 악성 스크립트를 실행한다면 나는 이미 YOLO 라이프스타일을 살고 있는 것이며 내 인생은
~/.bashrc
나의 완전한 갱킹의 메인 코스에서 그저 순한 조미료가 됩니다. - 또 다른 질문은 순수주의자의 관점에서 볼 때
~/.bashrc
내 파일을 두 개의 파일, 즉 대화형 사용을 위한 파일과 스크립팅용 파일로 분할하고 대화형 파일이 . 하지만 그 막연한 순수함을 넘어선 너무 적은 노력에 너무 많은 노력을 쏟는 것처럼 들립니다. - 또 다른 문제는 이식성이지만 저는 대부분 직접 스크립트를 작성합니다. 나중에 다른 사람들과 공유하고 싶다면 일반화하는 것은 그리 어렵지 않을 것입니다. 최악의 상황이 발생하면
~/.bashrc
사용 중인 기능이 무엇이든 자동으로 인라인되도록 스크립트를 작성할 수 있습니다 . NP 문제는 아닌 것 같습니다. - 내 비표준 기능의 이점을 누릴 수 있는 스크립트는
~/.bashrc
그러한 스크립트를 먼저 다른 언어로 작성해야 한다고 제안하기 때문에 내 접근 방식에 결함이 있다고 주장할 수도 있습니다. - 반면에 Unix/Linux 철학은 단순한 표준 세트가 아니라 환경을 요구 사항에 맞게 조정하는 도구 세트이므로 안 될 이유가 없습니다.
답변1
IMO, 아니요, 이것은 좋은 생각이 아닙니다.
이를 사용하는 모든 스크립트의 상단에 함수 및 변수 라이브러리를 명시적으로 가져오는 것이 좋습니다 expand_aliases
(별칭은 셸 옵션이 설정되지 않은 한 비대화형 셸에서 작동하지 않음). 이렇게 하면 손상될 위험이 없습니다(큰 소리로, 분명히 또는 더 나쁘게는 미묘하게) 시스템에 있는 수백 또는 수천 개의 기존 스크립트 중 하나입니다.
그러나 항상 그렇듯이 최종 규칙은 다음과 같습니다. 이는 귀하의 시스템이며 원하는 경우 이를 깨뜨릴 수 있습니다.