PATH에 물결표(~)를 넣지 마세요

아니면 그냥… 물결표를 인용하지 않으면 된다. 사람들은 Bash에서 "문자열"을 습관적으로 인용하면서도 (거의) 모든 것이 문자열이고 대부분의 문자열은 인용되지 않으며 인용하는 게 이상할 것이라는 점을 깨닫지 못하는 것 같다 (예: 아무도 `"ls" "-a" "foo"`라고 하지 않는다).

그냥 이렇게 하면 된다:

PATH=~/.local/bin:$PATH

PATH는 이미 export되어 있다. 할당에서는 따옴표도 필요 없다.

~/.local/bin PATH가 작동하지 않는 걸 보고 눈치챘어야 했던 것 같은데?

물결표에 대한 건 아니고 큰 조직에서 bash로 인해 생길 수 있는 몇 가지 미친 상황에 대한 이야기:

예전 직장에서, 내 bashrc의 어느 부분이 특정 환경 변수를 설정하는지 알아내려고 했다. 사용자 프로필에 설치된 일종의 기본값이거나 /etc/<something>에서 상속받은 것이라고 생각했다.

내 bashrc가 다른 파일들을 import하고 있다는 걸 금방 알아챘다. 역시 import 깊이가 한 단계일 거라고 가정했다.

알고 보니 "ur-bashrc"에서 시작해서 점점 더 많은 import가 층층이 쌓여 최종적으로 사용자 레벨 프로필에 도달하기까지 10단계 이상의 import가 있었다.

너무 뒤엉켜 있어서 미칠 지경이었는데, 이 Stack Exchange 글을 찾고 나서야 해결됐다: https://unix.stackexchange.com/questions/813/how-to-determin...

bash import에 "추적"을 켜서 환경 변수가 어디서 설정되는지 좁혀나갈 수 있게 해준다.

“나한테는 항상 잘 작동하는 것 같다”고 말하려던 참이었는데, 그 다음에 “… 실제로는 Bash와 Zsh에서 작동한다, 왜냐하면 …”이라는 걸 봤다.

이식성을 고려할 때 조심해야 할 또 하나의 Bash-ism이다.

많은 시스템에서 /bin/sh가 bash(또는 zsh)가 아니라는 점은 주목할 가치가 있다. 따라서 Bashism에 의존하고 싶다면(또는 그것들을 찾아볼 생각조차 없다면) 해시뱅에 “#!/bin/bash”를 명시적으로 사용하라. 예를 들어 Debian 및 유사 배포판에서는 보통 dash이다.

리눅스 배포판들이 스크립팅 언어와 분리된 "터미널"/"CLI" 프로그램 같은 걸 제공했으면 좋겠다. 특정 셸에 묶이지 않은 범용 Path 환경 변수를 가지는 것이다. cd 명령 실행, python/git/cargo/임의의 애플리케이션 실행 등을 할 수 있고, 좋은 북마크 + 자동완성 시스템도 갖추는 것이다. 스크립팅 언어와 CLI 애플리케이션을 혼동하는 것이 이런 복잡함과 미묘함의 근원인 것 같다.

셸 스크립팅을 사용한다면(그리고 Python보다 Bash 등을 선호한다면), 계속 Bash/Fish/Zsh 등을 쓰면 된다. GUI가 없는 애플리케이션을 실행하고, 디렉터리를 탐색하고, 파일 시스템 작업을 수행하기 위해 CLI를 사용한다면, 일반 터미널을 사용하면 된다.

그냥 홈으로 향하는 심볼릭 링크인 ~ 파일을 만들면 된다 :)

엄청난 두뇌 활용이다