배치 파일로 실행하면 오류, 더블클릭하면 정상. 원인은 탐색기가 몰래 맞춰주던 현재 디렉터리

링크된 예전 글 보니까 '클릭한 것'이 꼭 exe일 필요는 없더라. 문서를 더블클릭하면 그 문서가 있는 디렉터리가 현재 디렉터리가 된다는 거고, 셸 네임스페이스 항목이나 링크는 어떻게 처리하는지 궁금하네.

이런 걸 1차 지원에서 못 걸러내고 Raymond Chen한테까지 올라간 게 신기함. 초기 지원 단계가 얼마나 엉망이면 배치 파일 디버깅이 저기까지 가냐.

아니면 그냥 그 프로젝트에 직접 붙어 있어서 자연스럽게 처리한 걸 수도 있지.

레이먼드 첸 같은 사람들은 일부러 제일 아래 단계 티켓도 훑으면서 전체 스택 감각을 유지한다더라. 저 사람이 열린 티켓 보다가 재밌어 보여서 집어갔을 가능성이 큼.

이거 1997년 글 아님? 요즘 글 중에 AI가 안 쓴 티가 이렇게 나는 것도 드물다.

탐색기 UI에는 cmd나 bash 같은 '현재 디렉터리' 개념이 없음. 창 여러 개 띄워놓고 그중 하나가 우선하지 않으니까. 프로그램이 특정 디렉터리에 사는 것처럼 쓰는 node 생태계랑 대비되는 지점임.

애초에 CLI가 경로 문자열 대신 이미 열린 파일 핸들을 받았으면 현재 디렉터리 개념 자체가 필요 없었을 거임. 셸 내부 상태로 두면 그만이지.

탐색기에서 클릭한 창의 폴더가 그 UI의 현재 디렉터리인 셈이라 오히려 cmd보다 깔끔한 형태임. cmd는 드라이브마다 따로 있잖아.

드라이브 문자별로 현재 디렉터리가 따로 있는 DOS/Windows 기능 쓰면 C:ffmpeg.exe -i D:scene1.mp4 output-scene1.mp4 같은 게 됨. 드라이브를 넘나들면서 경로를 안 써도 되니까 편하긴 한데.

그건 끔찍함. 보이지 않는 상태가 너무 많아. 절대 경로로 cd 한 다음 현재 디렉터리에서 대량 삭제 같은 걸 하면 다른 드라이브까지 날아갈 수 있음.

비슷한 걸로 자동화 스크립트를 테스트한 사용자와 다른 권한으로 돌렸을 때 터지는 경우가 있음. '내 컴에서는 되는데'에서 '되게'로 넘어갈 때 늘 나오는 문제임.