왜 .bashrc 대신 원격 Bash 소스 .bash_profile을 사용합니까?


24

배쉬 매뉴얼 은 말한다 :

Bash는 원격 쉘 데몬 (일반적으로 rshd) 또는 보안 쉘 데몬 (sshd)에 의해 실행될 때와 같이 표준 입력이 네트워크 연결에 연결된 상태에서 언제 실행되고 있는지 확인합니다. Bash가 이런 방식으로 실행되고 있다고 판단되면 파일이 존재하고 읽을 수있는 경우 ~ / .bashrc에서 명령을 읽고 실행합니다.

이 배쉬 소스 ~/.bashrc:

ssh user@host :

그러나이 배쉬 소스 ~/.bash_profile:

ssh user@host

사양에 따라이 두 명령에서 차이가 보이지 않습니다. 두 경우 모두 네트워크 연결에 연결되어 있지 않습니까?


2
그것은 당신이 요구하는 것이 아니지만, .bash_profile에서 .bashrc소스로 만드는 것이 좋은 습관으로 간주됩니다 . 이런 식으로 .bashrc의 설정은 bash가 로그인 쉘 또는 비 로그인 쉘로 시작되는지 여부에 관계없이 적용됩니다.
Ilmari Karonen

답변:


44

로그인 쉘은 먼저 읽고 /etc/profile다음 ~/.bash_profile.

비 로그인 쉘에서 읽고 /etc/bash.bashrc다음 ~/.bashrc.

왜 중요한가요?

이 줄로 인해 man ssh:

경우 명령이 지정되어, 그 대신 로그인 쉘의 원격 호스트에서 실행됩니다.

즉, ssh 명령에 다음과 같은 옵션 만있는 경우 (명령이 아님) :

ssh user@host

로그인 쉘이 시작되고 로그인 쉘이 읽습니다 ~/.bash_profile.

다음 과 같은 command 가있는 ssh 명령

ssh user@host :

명령이있는 곳 :(또는 아무것도하지 마십시오).
그것은 것입니다 하지 따라서 로그인 쉘을 시작 ~/.bashrc으로 판독 될 수 있습니다.


원격 표준 입력

원격 컴퓨터에서 / dev / stdin에 제공된 tty 연결은 실제 tty이거나 다른 것일 수 있습니다.

에 대한:

$ ssh sorontar@localhost
/etc/profile sourced

$ ls -la /dev/stdin
lrwxrwxrwx 1 root root 15 Dec 24 03:35 /dev/stdin -> /proc/self/fd/0

$ ls -la /proc/self/fd/0
lrwx------ 1 sorontar sorontar 64 Dec 24 19:34 /proc/self/fd/0 -> /dev/pts/3

$ ls -la /dev/pts/3
crw--w---- 1 sorontar tty 136, 3 Dec 24 19:35 /dev/pts/3

시작된 bash가 볼 때 TTY (네트워크 연결이 아님)로 끝나는 것.

명령으로 ssh 연결의 경우 :

$ ssh sorontar@localhost 'ls -la /dev/stdin'
sorontar@localhost's password: 
lrwxrwxrwx 1 root root 15 Dec 24 03:35 /dev/stdin -> /proc/self/fd/0

TTY의 목록은 동일하게 시작되지만 / etc / profile은 소스되지 않았습니다.

$ ssh sorontar@localhost 'ls -la /proc/self/fd/0'
sorontar@localhost's password:
lr-x------ 1 sorontar sorontar 64 Dec 24 19:39 /proc/self/fd/0 -> pipe:[6579259]

연결이 네트워크 연결이 아닌 파이프임을 쉘에 알려줍니다.

따라서 두 테스트 사례 모두에서 셸은 연결이 네트워크에서 온 것임을 알 수 없으므로 읽을 수 없습니다 ~/.bashrc(네트워크 연결에 대해서만 이야기하는 경우). ~ / .bashrc를 읽지 만 다른 이유가 있습니다.


인수 없음의 경우는 해당되지 않을까요 네트워크 연결에 연결된 표준 입력으로 실행되고 있다, 따라서 및 ~/.bashrc읽기?
Cyker

@Cyker 쉘이 stdin 네트워크에 연결되어 있다고 가정한다 . 왜 그렇게 가정합니까? (답변은 편집하십시오.)
sorontar

편집 된 부분은 흥미입니다. ssh는 단순히 명령을 실행할 때 pty를 신경 쓰지 않는 것처럼 보입니다.
Cyker

8

"어떻게"가 "어떻게"가 아닌지에 대한 질문을하므로 그 관점에서 대답하려고합니다. 다음은 왜 과거에 일이 일어 났으며 오늘날의 일이 어떻게 발생하는지에 대한 합리적인 근거가 될 것입니다.


서로 다른 두 개의 시작 파일 ( "profile"및 "rc")이있는 이유는 과거에 머신에서 작업하는 일반적인 방법이 다음과 같기 때문입니다.

  1. 실제 터미널이나 다른 워크 스테이션에서 로그인 하여 로그인 쉘을 얻습니다 . 이 쉘은 사용자 환경을 호출 /etc/profile하고 ~/.profile설정합니다.

  2. 사용자가 입력하려는 환경을 호출하십시오. 이 환경은 Xorg 일 수 있지만 대부분의 경우 GNU 화면과 같은 멀티플렉서였습니다.

  3. 그런 다음 환경 (예 : GNU 화면)은 부모 로그인 셸에서 환경을 상속하는 추가 (비 로그인) 셸을 호출합니다.

이는 개발 당시 cshbash개발 중에 UNIX 시스템에 로그인하는 일반적인 방법이었습니다 . 그러므로 어쨌든 환경을 물려받은 조개 껍데기를 다시 읽는 것은 낭비적인 것으로 여겨졌다~/.profile .

bash그런 ~/.bashrc다음 비 로그인 쉘 에 대한 추가 구성을 위해 추가 되었습니다 . csh(및 tcsh)는 비 로그인 쉘에 대해 어떤 종류의 "rc"파일도 추가하지 않았습니다. 참고 csh/가 tcsh(POSIX의 일부입니다) Bourne 쉘 호환 쉘이없는 동안은 bash입니다. 다른 Bourne 호환 쉘 ksh은 환경 변수 ( ENV)를 추가했습니다.이 변수 는 정의 된 경우 비 로그인에 대한 실행 명령 ( "rc") 파일로 사용됩니다 ksh.

따라서 bourne 쉘의 최신 버전은 추가 구성 파일을 별칭과 편의를 위해 편의상 추가했으며 GNU 화면에 의해 muxed 쉘 (또는 이와 유사한 것)에 있지만 쉘을 처음 입력 할 때 나타나는 쉘에는 없습니다 기계.

그래픽 디스플레이 관리자 (GDM)가 등장함에 따라 GDM은 자체 초기화 파일 (예 : ~/.xinit~/.xsession)을 갖기 때문에 "프로필"파일과 "rc"파일의 구분이 무의미 해졌습니다 . 그런 다음 GDM 내부에서 언급 된 쉘은 사용자의 변덕에 따라 로그인 또는 비 로그인 쉘일 수 있으며, 비 로그인 쉘이 항상 로그인 쉘인 상위를 갖는 경우는 더 이상 사실이 아닙니다.

특별한

쉘 시작 파일 비교 에서 내가 좋아하는 표 중 하나는 bourne 쉘 호환 쉘이 profile파일을 사용하는 반면 다른 쉘은 사용하지 않는 방법을 보여줍니다 . 과거에는 초기 쉘 (muxer를 시작한 쉘)이 Bourne 호환 쉘이어야했기 때문입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.