OpenCode와 불완전한 PATH: 왜 도구들이 에이전트 셸에 없었나요?
게시: 21 April 2026
당신은 터미널에서 OpenCode를 실행하고, 모든 것이 정상적으로 작동합니다. 에이전트는 시도합니다`gh`— 찾을 수 없음. 하나`java -version`— 부재한. 하나`node`— 어디에도 없습니다. 하지만,これらのツール들은 votre shell 안에 분명히 있습니다. 문제는? OpenCode는 셸을 실행합니다.비상호적당신의 것을 절대 읽지 않는`.zshrc`. 여기서 진단하고 깔끔하게 수정하는 방법입니다.
- 똑
-
[]
장면: 도구의 세계에서 눈먼 에이전트
그것은 화요일 저녁이었고, 나는 방금 설치하고 있었다.https://opencode.ai[OpenCode], 코딩 방식을 바꿔줄 것을 약속했던 AI 에이전트. 첫 번째 테스트 : 그것을 이용해 나의 GitHub 저장소 목록을 요청하기.
$ opencode
> Utilise gh pour lister mes repos
❌ bash: gh: command not found
이상하다`gh`내 터미널에서 완벽하게 작동했습니다. 다른 것을 시도해 보고 있습니다 :
> Vérifie la version de Java
❌ bash: java: command not found
그리고:
> Lance le build Gradle
❌ bash: gradle: command not found
Java, Gradle, Node,gh— 모든 것이 요원에게 보이지 않았다. 내 터미널은 모든 것을 볼 수 있었다. 요원과 내가 두 개의 평행 세계에 살고 있는 것처럼.
이해하는 데 몇 시간이 걸렸습니다. 몇 시간의`echo $PATH`, de which java, 점점 커지는 불만. 나는 결국 이해했다 — 문제는 도구가 아니었고, 그것이쉘. OpenCode은 모든 하위 프로세스를 실행하는 에이전트처럼, 쉘에서 작업합니다.비대화식. 그리고 Zsh는 이러한 셸에서 단순히 당신의`.zshrc`.
다음은 진단, 해결 방법, 그리고 제가 배운 교훈에 대한 전체적인 설명입니다. — OpenCode, Aider, Cursor, 또는 cron 스크립트와 같은 AI 에이전트를 사용한다면 언젠가 이 문제에 직면하게 될 것입니다. — 이 문제는 언젠가 당신에게 영향을 미칠 것입니다.
버그의 해부 : 두 개의 쉘, 두 개의 세계
터미널을 열면 Zsh는 이를 쉘로 처리합니다.대화형. 그의 충전한다`.zshrc`, 이 모든 것을 초기화합니다: SDKMAN, NVM, pnpm, 별칭, 멋진 프롬프트. 환경을 완성했습니다.
하지만 OpenCode가 명령을 실행할 때, 대화형 터미널을 실행하지 않습니다. 셸을 실행합니다.비대화형— 작업 셸, 화면 뒤에 인간이 없는. 그리고 Zsh는 이 상황에서 점프한다..zshrc. 그는 다만 읽는다..zshenv.
왜 이 구분이 존재하는가? 왜냐하면 비대화형 셸은 스크립트를 실행하도록 설계되었고, 인간 사용자를 위해 설계된 것이 아니기 때문이다. 백그라운드에서 실행되는 스크립트에 별칭, 프롬프트, 자동완성을 로드하는 것은 낭비이다. 문제는, 실행 가능한 파일을 찾는 데 가장 중요한 정보인 사용자의 PATH가 자주 초기화되는 곳에`.zshrc`, 안에 있지 않아`.zshenv`.
@startuml skinparam backgroundColor #FEFEFE actor "당신" as user actor "OpenCode (에이전트)" as agent participant "셸 대화형 (.zshrc 소스된)" as ishell participant "Shell 비대화형 (.zshrc 무시됨)" as nshell user -> ishell : gh, java, node ✅ agent -> nshell : gh, java, node ❌ note right of ishell Source .zshrc : - SDKMAN init - NVM init - ~/apps dans PATH - pnpm dans PATH end note note right of nshell .zshrc ignoré ! PATH = /usr/bin:/bin + quelques répertoires défaut end note @enduml
문제의 근원 :Zsh는 대화형 셸에서만 .zshrc`를 소스합니다. OpenCode, 모든 IA 에이전트가 서브프로세스를 시작할 때와 마찬가지로, 비대화형 셸을 사용합니다. 이 셸은 오직 읽습니다..zshenv`.
범인들: .zshrc vs `.zshenv
Zsh는 가지고 있습니다네 개의 초기화 파일, 각kak 특정 역활을 가진. 세련된 디자인이다 — 이것도 문제의 핵심:
파일 |
소싱된 때 |
역할 |
PATH를 수정해? |
|
항상(대화형 + 비대화형 + 로그인) |
필수 환경 변수, PATH |
✅ 예 — 이것이 SA의 자리다. |
|
로그인 셸만 |
느린 명령어 (세션당 한 번) |
가능한 |
|
대화형 쉘만 |
별명, 프롬프트, 자동 완성, 대화형 도구 |
❌ 중요한 변수에는 사용하지 마세요 |
|
로그인 셸(.zshrc 이후) |
환영 메시지, 완료 |
드물게 |
표는 힌트를 주지만, 깊이 이해해야 합니다. 집의 방처럼 생각해 보세요:
-
`.zshenv`은/는로비— 모두가 여기서 지나갑니다, 방문자든 거주자든. 여기에 무언가를 놓으면, 모든 셸이 이를 볼 수 있습니다.
-
`.zshrc`은/는거실— 단지 주민(대화형 셸)만 들어갑니다. 방문자(비대화형 셸)는 로비에 머무릅니다.
-
.zprofileet `.zlogin`로그인 셸을 위한 특수 구성 요소이며 (SSH로 연결할 때처럼).
비극은 우리 대부분이 PATH를 거실에 두는 것이라는 점이다. 그리고 AI 에이전트는 거실에 들어갈 수 없다.
문제를 다이어그램으로 표현하면 :
@startuml
skinparam backgroundColor #FEFEFE
start
if (Shell interactif ?) then (Oui)
:Source .zshenv;
:Source .zprofile;
:Source .zshrc;
:Source .zlogin;
note right
SDKMAN ✅
NVM ✅
~/apps ✅
pnpm ✅
end note
else (Non — shell non-interactif)
:Source .zshenv uniquement;
note right
SDKMAN ❌
NVM ❌
~/apps ❌
pnpm ❌
end note
endif
stop
@enduml
터미널을 열면, Zsh는 대화형입니다: 읽습니다`.zshrc`, 모든 것이 작동합니다. OpenCode가 셸을 실행하여 명령을 실행할 때, Zsh는 비대화형입니다:それは 건너뜁니다..zshrc, 읽기만`.zshenv`. Et si `.zshenv`존재하지 않거나 PATH를 포함하지 않습니다 — 이것이 황무지입니다.
|
왜 Zsh가 그렇게 하는가?이것은 Unix에서 상속받은 설계 선택이다. 비대화형 쉘이어야 한다빠른 et 재현 가능한. 별칭, 색이 있는 프롬프트, SDKMAN의 무거운 초기화를 크론 스크립트나 AI 에이전트에 로드하면 느리고 취약할 것입니다. 따라서 분리는 논리적 :`.zshenv`principalement (변수, PATH),`.zshrc`편안함을 위해 (aliases, prompt, complétons). 문제는 핵심 을 편안함에 두면 발생한다. |
단계별 진단
수정하기 전에 정확히 무엇이 부족한지 이해해야 합니다. 다음은 재현 가능한 진단 방법입니다 — AI 에이전트와 작업한다면 즐겨찾기에 저장하세요.
1. 에이전트 PATH 확인
대화형 터미널이 보는 내용과 비대화형 셸이 보는 내용을 비교합니다 — 즉, OpenCode가 보는 내용입니다.
# Dans votre terminal interactif (tout fonctionne)
echo $PATH | tr ':' '\n' | grep -v '^/usr' | sort
일반적인 결과 :
/home/cheroliv/apps
/home/cheroliv/.nvm/versions/node/v22.19.0/bin
/home/cheroliv/.sdkman/candidates/java/current/bin
/home/cheroliv/.sdkman/candidates/gradle/current/bin
/home/cheroliv/.local/share/pnpm
/home/cheroliv/.local/bin
이제 에이전트가 보는 것을 시뮬레이션해 봅시다 — 비대화형 셸 :
# Shell non-interactif : pas de .zshrc
zsh -c 'echo $PATH' | tr ':' '\n' | grep -v '^/usr' | sort
결과 :
/home/cheroliv/.local/bin
여섯 길 중 다섯이 사라졌다.에이전트는 환경의 83%를 잃었습니다. 마치 당신이 절반의 조리 도구 없이 요리하라고 요청받은 것과 같습니다 — 물을 끓일 수는 있지만, 그 외에는 거의 할 수 있는 게 없습니다.
|
명령`zsh -c 'echo $PATH'`당신의1등 진단 도구. 매일 사용하는 도구가 결과에 포함되지 않으면, AI 에이전트도 그것을 볼 수 없습니다. 수정 전과 후에 테스트해 보세요. de`.zshenv`. |
2. .zshrc에 있지만 .zshenv에 없는 것을 식별한다
이제, 우리는 범인을 찾고 있는 에서`.zshrc`. 우리는 우리 도구를 언급하는 줄을 필터링합니다 :
grep -n 'apps\|SDKMAN\|NVM\|PNPM\|PATH' ~/.zshrc
일반적으로 발견됩니다:
119: PATH="/usr/bin/python3:$HOME/apps:$PATH" # ← pas exporté !
171: export NVM_DIR="$HOME/.nvm"
172: [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # ← NVM init
176: nvm use --lts --silent # ← active une version
179: export PNPM_HOME="/home/cheroliv/.local/share/pnpm"
187: export SDKMAN_DIR="$HOME/.sdkman"
188: [[ -s "$HOME/.sdkman/bin/sdkman-init.sh" ]] && source "$HOME/.sdkman/bin/sdkman-init.sh"
그 모든 것이보이지 않는OpenCode를 위해. 그리고 그`PATH`119번째 줄조차도 아닌`export`é — 현재 셸을 절대 떠나지 않습니다. 이것은 중요한 기술적 세부 사항입니다: 변수 없이`export`이 변수는 해당 셸에 국소적이다. 서브셸 — OpenCode에 의해 시작된 것들처럼 — 은 이를 결코 상속받지 않는다.
3. .zshenv 파일이 존재하는지 확인
cat ~/.zshenv 2>/dev/null || echo "FICHIER ABSENT"
답변이 « FICHIER ABSENT »이면, 여기서 모든 것이 결정된다.
해결책 : .zshenv + 올바른 경로
전략은 간단하지만 정밀함이 필요합니다: 안에 넣기`.zshenv` 오직필수 경로는, 무거운 초기화 스크립트를 소싱하지 않고. 우리는 이동하지 않습니다`.zshrc`안에`.zshenv`— 핵심 내용을 추출합니다.
필수적인 모든 경로를 포함한 .zshenv 파일을 만드세요.
`.zshenv`은/는단일 파일Zsh가 소스를 보장하는모두문맥들. PATH가 가야 할 곳은 여기입니다.
export SDKMAN_DIR="$HOME/.sdkman"
export NVM_DIR="$HOME/.nvm"
export PNPM_HOME="$HOME/.local/share/pnpm"
export PATH="$HOME/apps:$HOME/.sdkman/candidates/java/current/bin:$HOME/.sdkman/candidates/gradle/current/bin:$HOME/.nvm/current/bin:$PNPM_HOME:$HOME/.local/bin:$HOME/.local/share/JetBrains/Toolbox/scripts:/usr/bin/python3:$PATH"
|
사용합니다`$HOME/.nvm/current/bin`그리고 안`$HOME/.nvm/versions/node/v22.19.0/bin`. 이유 : Node 버전이 변경됩니다. 고정된 경로가 다음에 잘못됩니다. |
왜 .zshenv에서 `source sdkman-init.sh`를 사용하지 않을까?
가장 유혹적인 접근법은 단순히 그곳에 재현하는 것이다`.zshenv`우리가 하는 것 안에`.zshrc`— 초기화 스크립트를 소스로 실행하다. 우리는할 수 있을하고 싶은 유혹이 있다:
# ❌ MAUVAISE IDÉE
[[ -s "$HOME/.sdkman/bin/sdkman-init.sh" ]] && source "$HOME/.sdkman/bin/sdkman-init.sh"
문제 :
-
느린:`sdkman-init.sh`각 셸마다 네트워크 해결 및 검사를 수행합니다. 비대화형 셸에서는 이는 불필요한 비용입니다.
-
취약한: SDKMAN은 대화형 환경을 기대합니다. 초기화가 파이프 또는 서브셸에서 조용히 실패할 수 있습니다.
-
쓸모없는: SDKMAN은 후보자들을`~/.sdkman/candidates/<tool>/current/bin`— 안정적인 심볼릭 링크가 활성 버전을 가리키고 있습니다. 이를 사용할 수 있습니다.직접.
올바른 접근 방식: SDKMAN 초기화를 우회하고 심볼릭 링크를 직접 가리키기`current`. 이것은 전체 해결책의 열쇠 :파일 구조를 계약으로 사용하고, 초기화 코드 대신 사용하라.
@startuml
skinparam backgroundColor #FEFEFE
rectangle "느린 접근
(source sdkman-init.sh)" as slow {
card ".zshenv에서 sdkman-init.sh 소스
쉘당 2-3초
네트워크 점검
실패 위험" as s1 #FDEDEC
}
rectangle "빠른 접근
(직접 심볼릭 링크)" as fast {
card ".zshenv export PATH=...current/bin\n0 ms\nPas de réseau\nPas d'initialisation" as s2 #E8F8E8
}
slow --> fast : Même résultat final\nLe PATH pointe sur current/bin\ndans les deux cas
@enduml
NVM 케이스: 버전 관리자가 흔적을 남기는 것을 잊을 때
NVM 문제
이곳이 조사가 나를 가장 멀리 이끌어간 곳입니다. SDKMAN은 세련된 디자인을 가지고 있습니다: 당신이 할 때`sdk install java 25.0.2-tem`, 심볼릭 링크를 생성합니다 :
~/.sdkman/candidates/java/current -> ~/.sdkman/candidates/java/25.0.2-tem
이 심볼릭 링크는항상 최신. 이 안에 가리키세요`.zshenv`그리고 당신은 보호받고, 어떤 셸이든 상관 없습니다. Beautiful.
신경 쓰지 마, 그는 만들지 않아아무것도텔의. 심볼릭 링크 없음`current`. 안정된 앵커 포인트가 없습니다. 우리는 하드코딩된 버전된 경로를 가리켜야 하며, 그것은 다음과 같이 보입니다 :
~/.nvm/versions/node/v22.19.0/bin/node
다음에`nvm install 24`, 이 길은 죽었습니다. 당신의`.zshenv`더 이상 활성 버전이 아닌 버전을 가리키게 됩니다. 이것은 시한 폭탄입니다.
|
NVM은 왜 그렇게 하는가?NVM은 PATH를 동적으로 수정하여 매번`nvm use`. 이는 버전을 자주 바꾸는 개발자를 위해 설계되었으며, 대화형 셸에서 사용됩니다. 심볼릭 링크`current`처음 사양에 들어 있지 않았습니다 — 이것은 우리가 직접 수정할 설계상의 실수입니다. |
@startuml
skinparam backgroundColor #FEFEFE
package "SDKMAN ✅" {
[~/.sdkman/candidates/java/current] as sdk_current
[~/.sdkman/candidates/java/25.0.2-tem/] as java_25
[~/.sdkman/candidates/java/21.0.7-tem/] as java_21
sdk_current --> java_25 : symlink
}
package "NVM ❌ (수정 전)" as nvm_before {
[~/.nvm/versions/node/v22.19.0/] as node_22
[~/.nvm/versions/node/v20.16.0/] as node_20
note right of node_22
Pas de symlink current !
.zshenv doit pointer en dur
Cassé au prochain nvm install
end note
}
package "NVM ✅ (수정 후)" as nvm_after {
[~/.nvm/current] as nvm_current
[~/.nvm/versions/node/v22.19.0/] as node_22b
[~/.nvm/versions/node/v20.16.0/] as node_20b
nvm_current --> node_22b : symlink\n(mis à jour auto)
}
@enduml
해결책: current 심볼릭 링크를 NVM용으로 생성
NVM이 그것을 하지 않기 때문에, 우리가 직접 합니다. 원리는 SDKMAN과 동일합니다 — 심볼릭 링크`current`항상 활성 버전을 가리키는. 한 번 생성한 후 자동화하여 스스로 업데이트되도록 합니다.
# Créer le symlink initial
ln -sfn "$HOME/.nvm/versions/node/v22.19.0" "$HOME/.nvm/current"
지금, 안에서`.zshenv`, 사용합니다 :
$HOME/.nvm/current/bin
대신에:
# ❌ Chemin en dur — cassé au prochain changement de version
$HOME/.nvm/versions/node/v22.19.0/bin
심볼릭 링크 업데이트 자동화
심볼릭 링크는 갱신되지 않으면 쓸모가 없다. 심볼릭 링크`current`업데이트해야 할 때`nvm use` ou nvm install. 해결책 : 하나래퍼— 진짜 명령을 감싸는 함수`nvm`그리고 각 호출 후에 심볼릭 링크를 업데이트합니다.
# À la fin de .zshrc, APRÈS le chargement de NVM
nvm use --lts --silent
ln -sfn "$(nvm_version_path "$(nvm current)")" "$NVM_DIR/current"
_nvm() {
command nvm "$@"
local rc=$?
ln -sfn "$(nvm_version_path "$(nvm current)")" "$NVM_DIR/current"
return $rc
}
alias nvm='_nvm'
작동 방식, 자세히 :
@startuml skinparam backgroundColor #FEFEFE actor Développeur participant "nvm 래퍼\n(_nvm)" as wrapper participant "nvm 실제 (command nvm)" as realnvm participant "~/.nvm/current\n(심볼릭 링크)" as symlink Développeur -> wrapper : nvm use 20 wrapper -> realnvm : command nvm use 20 realnvm --> wrapper : version activée wrapper -> symlink : ln -sfn .../v20.16.0 ~/.nvm/current wrapper --> Développeur : retour note right of symlink Toujours à jour ! Utilisé par .zshenv → accessible par OpenCode end note @enduml
래퍼`_nvm`실제 명령을 호출한다`nvm`, 그리고 심볼릭 링크를 업데이트합니다. 별칭`nvm='_nvm'`입력할 때 그렇게 되도록`nvm`, 우리는 래퍼를 통해 진행합니다. 그리고 셸 초기화 시에도 동일한 작업을 수행합니다.nvm use --lts.
|
`nvm_version_path`는 NVM의 내부 기능으로, 버전의 전체 경로를 해결합니다. 이로 인해 경로를 수동으로 다시 구성할 필요가 없습니다. |
경로 요약 표
트랩으로 넘어가기 전에, 변환의 시각적 요약. 좌측에, 당신이 가졌던 (모든 것`.zshrc`, 에이전트에게 보이지 않음). 오른쪽에서, 당신이 지금 가지고 있는 것 (필수 경로 내`.zshenv`, 모든 곳에 보이는).
| 도구 | 이전 (.zshrc만) | 이후에 (.zshenv + symlink) | OpenCode에서 보이는가? |
|---|---|---|---|
|
PATH가 .zshrc에서 내보내지지 않음 |
|
✅ |
SDKMAN 자바 |
|
|
✅ |
SDKMAN 그레이들 |
|
|
✅ |
NVM 노드 |
|
|
✅ |
pnpm |
|
|
✅ |
JetBrains Toolbox |
Toolbox에 의해 `.zshrc`에 자동으로 추가됨 |
|
✅ |
파이썬 3 |
`/usr/bin/python3`PATH .zshrc 안에 |
.zshenv에서 명시적으로 |
✅ |
함정과 완화
이 접근 방식에서는 모든 것이 완벽하지 않습니다. 제가 겪은 문제점과 이를 우회하는 방법을 소개합니다.
| 함정 | 설명 | 완화 |
|---|---|---|
중복된 PATH |
.zshenv과 .zshrc가 동일한 경로를 추가하면, 그 경로가 두 번 나타납니다 |
`.zshenv`소싱되었습니다이전.zshrc. 두 파일이 대화형 셸에서 읽힙니다. PATH가 중복될 수 있습니다. 이것은 미적인 문제일 뿐 기능적인 문제는 아닙니다. 이를 방지하려면 .zshenv에 기본 PATH에 없는 absents 경로만 넣으세요. |
NVM: .zshenv에 하드코딩된 버전 |
놓다`~/.nvm/versions/node/v22.19.0/bin`콘크리트에서 다음에 거짓이 된다`nvm install` |
심볼릭 링크 사용`$HOME/.nvm/current/bin`+ 래퍼`_nvm`안 .zshrc |
SDKMAN : .zshenv에서 sdkman-init.sh 소스하기 |
느리고, 취약하며, 비대화형 쉘에서는 쓸모가 없습니다. |
심볼릭 링크 사용`candidates/<tool>/current/bin`직접적으로 |
수정 후 누락된 별칭 |
래퍼`nvm='_nvm'`.zshrc에서 는 다시 로드한 후에만 적용됩니다 |
쉘을 다시 시작하거나`source ~/.zshrc` |
OpenCode는 변경사항을 보지 않는다. |
에이전트는 이미 기존 .zshenv을 사용해 하위 셸을 실행했습니다. |
OpenCode 수정한 .zshenv 후 다시 시작 |
.zshenv이 과도하게 로드됨 |
무거운 함수나 대화형 초기화를 .zshenv에 넣으세요. |
.zshenv = 환경 변수 + PATH만. 없습니다`source`, 무거운 함수 없음, 프롬프트 없음. |
배운 교훈
-
.zshrc`는 대화형입니다,
.zshenv`은 범용입니다— 변수가 모든 셸(에이전트 AI, cron, 스크립트, IDE)에 존재해야 한다면, 그것은.zshenv`. 거실은 편안하지만, 입구 홀은 모두가 지나가는 유일한 장소입니다. -
버전 관리자들은 동일하지 않다.— SDKMAN은 심볼릭 링크를 생성합니다.`current`설계상. NVM 아니오. 이 부족함을 수동으로 채워야 합니다. 이것은 중요한 교훈입니다: PATH를 설정하기 전에, 관리자가 안정적인 고정점을 제공하는지 확인하세요.
-
.zshenv에서 init 스크립트를 소스하지 마세요 —
sdkman-init.shet `nvm.sh`대화형 셸을 위해 설계되었습니다. 비대화형 컨텍스트에서는 느리고 취약합니다. 심볼릭 링크`current`그들은 충분하고 즉각적이다. -
비대화형 쉘에서 항상 테스트—`zsh -c 'echo $PATH'`에이전트가 보는 것을 정확히 시뮬레이션합니다. 이것은 검증 테스트입니다. 이 테스트가 없으면, 에이전트에 대해 구성이 작동하는지 알 수 없습니다.
-
래퍼 패턴은 재사용 가능합니다.— 같은 패턴`_nvm`+`alias nvm='_nvm'`모든 PATH를 동적으로 수정하지만 흔적을 남기지 않는 도구에 적용됩니다. 이것은 당신의 아이디어 상자에 하나 더 추가되는 도구입니다.
@startuml
skinparam backgroundColor #FEFEFE
rectangle "전에" as avant {
card "대화형 셸 : ✅
비대화형 셸 : ❌
OpenCode : ❌
Cron : ❌
스크립트 : ❌" as av1 #FDEDEC
}
rectangle "후에" as apres {
card "대화형 셸 : ✅\n비대화형 셸 : ✅\nOpenCode : ✅\nCron : ✅\nScripts : ✅" as ap1 #E8F8E8
}
avant --> apres : .zshenv +\nsymlink ~/.nvm/current
@enduml
최종 검증
생성한 후`.zshenv`그리고 NVM 심볼릭 링크, 모든 것이 작동하는지 확인하세요 — 두 가지 컨텍스트 모두에서 :
# Shell interactif (votre terminal)
gh --version && java -version && node --version
# Shell non-interactif (simulation OpenCode)
zsh -c 'gh --version && java -version && node --version'
둘 다 성공해야 합니다. 그렇게 된다면, 귀하의 IA 에이전트가 귀하와 동일한 도구를 볼 것입니다. 그렇지 않다면, 단계별 진단으로 돌아가세요 — 아마도 경로를 잊었거나 NVM 심링크가 최신이 아닐 것입니다.
|
이 테스트를 자동화하세요.이 검사를 도구 업데이트 후에 실행하는 healthcheck 스크립트에 추가하세요. 하나`zsh -c 'which java && which node && which gh'`CI에서는 예상치 못한 상황에 대비하는 보험입니다. |
_ 대화형이 아닌 셸은 침묵하는 손님과 같다: 그것은 입구에 표시된 것만 읽는다. PATH가 거실에 있으면, 그것을 결코 볼 수 없다. _
링크
공식 문서
-
Zsh 문서 : 시작 파일— Zsh 초기화 파일에 대한 공식 참조입니다. 여기가 모든 것이 설명되는 곳이지만, 종종 잊혀지기도 합니다.
-
OpenCode : 구성— OpenCode 및 실행 환경 설정 방법.
언급된 도구
-
GitHub의 NVM— Node Version Manager. Node.js 버전 관리자.
-
SDKMAN — 공식 사이트— SDKMAN! JVM(Java, Kotlin, Gradle 등)의 버전 관리자
-
SDKMAN: 설치— SDKMAN 설치 가이드.
-
gh` — 깃허브 CLI— GitHub 커맨드라인 도구, 모든 개발자에게 필수적인
-
Gradle — 공식 사이트— SDKMAN을 통해 설치하는 빌드 시스템.
-
pnpm — 공식 사이트— 빠르고 공간을 절약하는 Node.js 패키지 관리자.
-
JetBrains 툴박스— JetBrains IDE 관리자, PATH에 스크립트를 추가합니다.
더 깊이
-
Zsh dotfiles : 완전한 가이드Zsh dotfiles 관리에 대한 심도 있는 기사
-
ArchWiki에서 Zsh— Zsh에 대한 최고의 커뮤니티 문서 중 하나.
-
NVM 이슈 GitHub— 심볼릭 링크 주변의 토론을 보려면`current`그리고 PATH 문제를 포함합니다.
관련 기사
31 May 2026
14 May 2026