|
4. 시그윈 사용
4.1. 왜 내 응용 프로그램에서 cygncurses-8.dll? 또는 cygintl-3.dll? 또는 cygreadline6.dll? 또는 ...을 찾을 수 없나요?
4.2. 새 터미널 창을 시작하는 속도가 느립니다. 무슨 문제인가요?
4.3. 시그윈이 갑자기 느려지는 이유는 무엇인가요?
4.4. 내 서비스가 네트워크 공유에 액세스할 수 없는 이유는 무엇인가요?
4.5. 경로를 어떻게 설정해야 하나요?
4.6. Bash(또는 다른 셸)에 "명령을 찾을 수 없습니다"라고 표시되지만 바로 거기에 있습니다!
4.7. 윈도우 경로와 유닉스 경로 사이를 어떻게 변환하나요?
4.8. 시작 시 bash가 내 .bashrc 파일을 읽지 않는 이유는 무엇인가요?
4.9. 대소문자를 구분하지 않도록 bash 파일 이름을 완성하려면 어떻게 해야 하나요?
4.10. 공백이 포함된 경로/파일 이름을 사용할 수 있나요?
4.11. 디렉토리의 바로 가기로 CD할 수 없는 이유는 무엇인가요?
4.12. 찾기 기능에 기본적인 문제가 있습니다. 왜 그런가요?
4.13. 왜 su가 작동하지 않나요?
4.14. man -k, apropos 또는 whatis가 작동하지 않는 이유는 무엇인가요?
4.15. 왜 chmod가 작동하지 않나요?
4.16. 셸 스크립트가 작동하지 않는 이유는 무엇인가요?
4.17. 시그윈에서 인쇄하려면 어떻게 하나요?
4.18. 국제(유니코드) 문자가 작동하지 않는 이유는 무엇인가요?
4.19. 내 애플리케이션에서 국제 문자를 인쇄하는데 회색 상자만 표시됩니다.
4.20. 디엘엘의 사본을 여러 개 보유해도 되나요?
4.21. 위의 내용을 읽었지만 시그윈을 제품과 함께 번들로 제공하여 고객 사이트에 배송하고 싶습니다. 사용자가 설치한 시그윈과 충돌하지 않고 이렇게 하려면 어떻게 해야 하나요?
4.22. 시그윈을 내 제품에 무료로 번들링할 수 있나요?
4.23. 하지만 일부 애플리케이션이 최신 디엘엘 위에 이전 시그윈 DLL을 설치하면 내 애플리케이션이 손상되지 않나요?
4.24. 시그윈에서 패키지 XYZ를 사용할 수 없는 이유는 무엇인가요?
4.25. 시그윈의 XYZ 패키지가 왜 그렇게 오래되었나요?
4.26. 다른 드라이브에 액세스하려면 어떻게 해야 하나요?
4.27. 시그윈 콘솔 창에 복사하여 붙여넣으려면 어떻게 해야 하나요?
4.28. 시그윈과 함께 어떤 방화벽을 사용해야 하나요?
4.29. 유닉스와 윈도우 간에 파일을 공유하려면 어떻게 해야 하나요?
4.30. 시그윈은 대소문자를 구분하나요?
4.31. 도스 특수 파일명은 어떻게 하나요?
4.32. 중단되면 어떻게 다시 복구하나요?
4.33. 왜 이상한 디렉토리 구조인가요?
4.34. 시그윈과 같은 바이러스 백신 프로그램은 어떻게 작동하나요?
4.35. GNU 이맥스의 시그윈 포트가 있나요?
4.36. 이맥스의 시그윈 포트가 있나요?
4.37. 이전 심볼릭 링크 중 일부가 더 이상 작동하지 않는 이유는 무엇인가요?
4.38. 삼바 마운트 파일 시스템에서 심볼릭 링크가 작동하지 않는 이유는 무엇인가요?
4.39. 시그윈 1.7.34 이상으로 업데이트한 후 ssh를 사용한 공개 키 인증이 실패하는 이유는 무엇인가요?
4.40. 시그윈 1.7.34로 업데이트한 후 내 .rhosts 파일이 더 이상 r로그인에서 인식되지 않는 이유는 무엇인가요?
4.41. 시그윈 1.7.34로 업데이트한 후 내 파일에 추가 권한이 있는 이유는 무엇인가요?
4.42. 내 Tk 프로그램이 더 이상 작동하지 않는 이유는 무엇입니까?
4.43. 시그윈을 방해하는 것으로 밝혀진 애플리케이션은 무엇인가요?
4.44. 포크() 실패를 어떻게 수정하나요?
4.45. find_fast_cwd 경고를 어떻게 수정하나요?
4.1. 왜 내 응용 프로그램에서 cygncurses-8.dll? 또는 cygintl-3.dll? 또는 cygreadline6.dll? 또는 ... 을 찾을 수 없나요?
뭔가 잘못되었습니다...
손상을 복구하려면 시그윈 설치 프로그램을 다시 실행하고 누락된 디엘엘 패키지를 제공하는 패키지를 다시 설치해야 합니다.
이미 한 번 패키지를 설치한 경우 시그윈 설치 프로그램에서 기본적으로 패키지 설치 옵션이 표시되지 않습니다. '설치할 패키지 선택' 대화 상자의 보기 드롭다운 메뉴에서 '전체'를 선택합니다. 그러면 이미 설치된 패키지를 포함한 모든 패키지가 나열됩니다. 아래로 스크롤하여 누락된 패키지를 찾습니다(예: libncurses8). '새로 만들기' 열의 드롭다운 메뉴에서 '다시 설치' 작업을 선택합니다. 설치를 계속 진행합니다.
일반적인 문제에 대한 자세한 설명과 누락된 다른 디엘엘로 확장하고 포함된 패키지를 식별하는 방법은 https://cygwin.com/ml/시그윈/2002-01/msg01619.html 을 참조하세요.
4.2. 새 터미널 창을 시작하는 속도가 느립니다. 무슨 문제인가요?
여러 가지 원인이 있을 수 있습니다.
시그윈 업그레이드 후 터미널 창이 갑자기 느리게 시작되기 시작했다면 인증 설정에 문제가 있는 것일 수 있습니다.
시그윈은 거의 모든 기간 동안 유닉스와 유사한 /etc/passwd 및 /etc/group 파일을 사용하여 윈도우 SAM 및 AD 데이터베이스의 내용을 미러링해 왔습니다. 이러한 파일은 여전히 사용할 수 있지만, 시그윈 1.7.34부터 새로 설치하는 경우 SAM/AD 데이터베이스를 직접 사용합니다.
새 방식으로 전환하려면 이 두 파일을 다른 곳으로 옮기고 시그윈 터미널을 다시 시작하세요. 그러면 시그윈이 새로운 기본 모드로 실행됩니다.
AD 도메인 로그인을 사용하지 않는 시스템을 사용하는 경우, 이렇게 하면 시그윈이 기본 윈도우 SAM 데이터베이스를 직접 사용하므로 /etc/passwd 등을 사용하는 이전 방법보다 더 빠를 수 있습니다. 최악의 경우 약간 느려질 수 있습니다. (속도 차이는 실행하는 벤치마크에 따라 달라집니다.) AD의 경우 로컬 파일 읽기를 네트워크 요청과 교환하기 때문에 이전 방법보다 느릴 수 있습니다. 1.7.35 버전은 1.7.34 버전에 비해 디엘엘의 AD 서버 요청 횟수를 줄였으며, 그 결과 시그윈 홈 디렉터리를 변경하려면 이제 AD 구성에서 변경할 수 있는 대신 /etc/nsswitch.conf를 변경해야 합니다.
여전히 셸 시작이 매우 느리다면 다른 여러 가지 원인을 살펴볼 수 있습니다:
시그윈 터미널 시작이 느려지는 일반적인 원인 중 하나는 잘못된 DNS 설정입니다. 이는 특히 AD 클라이언트에 영향을 미치지만, 네트워크 서버로부터 빠른 응답을 받는 데 의존하는 시그윈 시작에 다른 문제가 있을 수도 있습니다.
도메인 컨트롤러가 시그윈과 같은 컴퓨터에 있거나 가까운 서버에 있는 경우에도 시그윈에 영향을 줄 수 있습니다. 예를 들어, DNS 서버 IP가 잘못되면 존재하지 않는 서버에 연결할 때 로컬 TCP/IP 스택이 시간 초과되는 동안 긴 지연이 발생할 수 있습니다.
AD 클라이언트 시스템의 또 다른 원인은 원격 DC 액세스가 있는 구성에서 일반적으로 관찰되는 느린 DC 응답입니다. 시그윈 디엘엘은 시작 시 로컬 캐시를 채우기 위해 사용자가 속한 모든 그룹에 대한 정보를 쿼리합니다. 로컬 파일에 자신의 정보를 캐싱하면 이 프로세스의 속도를 조금 높일 수 있습니다. 등에 대한 쓰기 권한이 있는 시그윈 터미널에서 다음 명령을 실행하세요:
getent passwd $(id -u) > /etc/passwd
getent group $(id -G) > /etc/group
또한 /etc/nsswitch.conf를 다음과 같이 설정합니다:
passwd: 파일 DB
그룹: 파일 DB
이렇게 하면 시그윈이 AD 도메인 컨트롤러(DC)에 연결할 필요가 제한되지만 원격 디렉터리를 나열할 때와 같이 DC에서 추가 정보를 검색할 수 있습니다.
이전 항목과 함께 또는 이 항목 대신 로컬 캐싱 서비스로 cygserver를 실행하여 DC 요청 속도를 높일 수 있습니다.
시그윈 프로그램은 DC에 직접 쿼리를 시도하기 전에 cygserver를 확인합니다.
덜 선호되는 옵션은 인증 데이터의 정적 읽기 전용 캐시를 만드는 것입니다. 이 방법은 1.7.34 이전 릴리스에서 사용할 수 있는 유일한 방법인 시그윈을 AD와 통합하는 구식 방법입니다. 이렇게 하려면 mkpasswd 및 mkgroup을 실행한 다음 /etc/nsswitch.conf에 다음을 넣어 시그윈이 이 파일을 사용자 및 그룹 정보의 유일한 소스로 취급하도록 합니다:
passwd: 파일
그룹: 파일
db 옵션을 생략하면 시그윈 디엘엘이 AD 조회를 시도하지 않도록 지시하는 것입니다. AD 서버가 느린 경우 이 로컬 캐시를 사용하면 속도가 빨라집니다. 단점은 오래된 캐시 문제에 노출된다는 것입니다. AD 데이터베이스가 변경될 때마다 파일을 수동으로 업데이트할 때까지 로컬 캐시는 오래된 상태가 됩니다.
위의 방법이 도움이 되지 않는다면 디버그 모드에서 시작 스크립트를 실행하는 것이 가장 좋은 문제 해결 방법입니다. 시그윈 터미널 아이콘을 마우스 오른쪽 버튼으로 클릭하고 속성으로 이동한 다음 명령을 편집합니다. C:\시그윈\bin\mintty.exe -i /cygwin-Terminal.ico -와 같은 형식이어야 합니다. 로그인 셸로 Bash를 사용 중이라고 가정하고 C:\시그윈\bin\mintty /bin/bash -lx로 변경한 다음 Cygwin 터미널을 다시 실행해 보세요. -x 옵션은 실행하기 전에 실행하는 모든 명령을 터미널에 기록하도록 Bash에 지시합니다. 터미널이 즉시 텍스트 줄로 채워지기 시작하다가 일시 중지되는 경우, 출력이 일시 중지된 줄이 무슨 일이 일어나고 있는지 알 수 있는 단서입니다. 이러한 지연은 터미널에 첫 번째 텍스트 줄이 나타나기 전에 발생하므로 이 경우 Cygwin 디엘엘 자체는 속도 저하의 원인이 아닐 수 있습니다.
4.3. 시그윈이 갑자기 느려지는 이유는 무엇인가요?
갑자기 모든 명령에 매우 오랜 시간이 걸린다면 네트워크 공유에 액세스하려고 시도하는 것이 원인일 수 있습니다. PATH 또는 시작 파일에 더 이상 사용되지 않는 //c 표기법이 있을 수 있습니다. c를 사용한다는 것은 네트워크 서버 c에 접속한다는 의미인데, 이 서버가 존재하지 않으면 속도가 엄청나게 느려집니다.
4.4. 내 서비스가 네트워크 공유에 액세스할 수 없는 이유는 무엇인가요?
서비스가 사용자 컨텍스트를 전환하는 서비스(sshd, inetd 등)인 경우 다른 사용자로 전환하는 데 사용되는 방법에 따라 다릅니다. 이 문제와 해결 방법은 시그윈 사용자 가이드(https://cygwin.com/cygwin-ug-net/ntsec.html 참조)에 자세히 설명되어 있습니다.
해결 방법으로는 인증이 필요하지 않은 공용 네트워크 공유를 사용하거나(중요하지 않은 파일의 경우), net 사용 명령에 비밀번호를 제공하거나, cygrunsrv -u를 사용하여 고유 사용자로 서비스를 실행하는 방법이 있습니다(자세한 내용은 /usr/share/doc/시그윈/cygrunsrv.README 참조).
4.5. PATH는 어떻게 설정해야 하나요?
이 설정은 바탕화면 또는 시작 메뉴 바로 가기에서 시그윈 설치 프로그램으로 만든 /etc/profile 파일에서 수행되며, 이 파일은 bash로 시작됩니다. 줄은 다음과 같습니다.
PATH="/usr/local/bin:/usr/bin:/bin:$PATH"
이렇게 하면 윈도우 시스템 경로에 /usr/local/bin과 /usr/bin이 추가됩니다. HOME/.bashrc에서 또는 등/프로필을 직접 편집하여 PATH를 재설정하는 경우 이 규칙을 따라야 합니다. PATH에 Windows 시스템 디렉터리 앞에 /usr/bin이 있어야 합니다. (Windows 시스템 디렉터리를 생략해서는 안 됩니다!) 그렇지 않으면 시그윈 애플리케이션을 실행할 때 온갖 종류의 문제가 발생할 수 있습니다.
bash가 아닌 다른 셸(예: tcsh)을 사용하는 경우, 로그인 스크립트의 이름만 다를 뿐 메커니즘은 동일합니다.
4.6. Bash(또는 다른 셸)에 "명령을 찾을 수 없습니다"라는 메시지가 표시되지만 바로 거기에 있습니다!
프로그램을 컴파일하면 실행할 수 없는 경우가 있습니다:
bash$ gcc -o hello hello.c
bash$ hello
bash: hello: 명령을 찾을 수 없습니다.
윈도우의 기본 동작과 달리 bash와 같은 유닉스 셸은 기본적으로 .(현재 디렉터리)에서 프로그램을 찾지 않습니다. 경로에 .을 추가할 수 있지만(위 참조), 보안상의 이유로 (적어도 유닉스에서는) 권장하지 않습니다. 명령줄에 입력할 때 bash에게 위치를 알려주기만 하면 됩니다:
bash$ gcc -o hello hello.c
bash$ ./hello
안녕하세요!
4.7. 윈도우 경로와 유닉스 경로 사이를 어떻게 변환하나요?
'cygpath' 유틸리티를 사용합니다. 정보를 보려면 'cygpath --help'를 입력하세요. 예를 들어 (내 설치에서)
bash$ cygpath --windows ~/.bashrc
D:\starksb\.bashrc
bash$ cygpath --unix C:/시그윈/bin/ls.exe
/usr/bin/ls.exe
bash$ cygpath --unix C:\\시그윈\\bin\\ls.exe
/usr/bin/ls.exe
bash는 백슬래시 '\'를 이스케이프 문자로 해석하므로 이스케이프 문자로 인식하려면 bash 셸에 두 번 입력해야 합니다.
4.8. 시작 시 bash가 내 .bashrc 파일을 읽지 않는 이유는 무엇인가요?
.bashrc는 HOME 환경 변수로 지정된 홈 디렉토리에서 읽습니다. HOME이 설정되지 않은 경우 /.bashrc를 사용합니다. 따라서 HOME(및 passwd 계정 정보에 있는 홈 디렉터리)을 올바르게 설정해야 합니다.
4.9. 대소문자를 구분하지 않는 bash 파일 이름 완성을 사용하려면 어떻게 해야 하나요?
.bashrc 파일에 다음을 추가합니다:
shopt -s nocaseglob
를 실행하고 ~/.inputrc 파일에 다음을 추가합니다:
완료-대소문자 무시 설정
4.10. 공백이 포함된 경로/파일명을 사용할 수 있나요?
시그윈은 파일 이름과 경로에 공백을 지원합니다. 하지만 라이브러리를 사용하는 일부 유틸리티는 그렇지 않을 수 있는데, 이는 일반적으로 유닉스에서 파일에 공백이 포함되지 않기 때문입니다. 이 문제가 발생하면 해당 유틸리티를 수정하거나 시그윈 도구에서 사용하는 파일 이름에 공백 사용을 중지해야 합니다.
특히 bash는 공백을 단어 구분 기호로 해석합니다. 따라서 공백이 포함된 파일명을 인용하거나 공백 문자를 이스케이프 처리해야 합니다. 예를 들어
bash-2.03$ cd '/cygdrive/c/Program Files'
또는
bash-2.03$ cd /cygdrive/c/Program\ Files
4.11. 디렉터리 바로 가기로 복사할 수 없는 이유는 무엇인가요?
시그윈은 MS 윈도우 탐색기 바로 가기(*.lnk 파일)를 따르지 않습니다. 바로가기를 일반 파일로 인식하므로 이 파일로 "cd"할 수 없습니다.
시그윈은 POSIX 심볼릭 링크를 윈도우 바로 가기로 만들 수도 있지만(CYGWIN 환경 변수 옵션 "winsymlinks" 참조), 이러한 바로 가기는 기본 Windows 애플리케이션에서 만든 바로 가기와는 다릅니다. Windows 애플리케이션은 일반적으로 시그윈 바로가기를 사용할 수 있지만 그 반대는 불가능합니다. 이는 선택에 의한 것입니다. 그 이유는 예를 들어 Cygwin이 심볼릭 링크로 아카이브하고 추출하는 경우 Windows 바로가기에 손실될 수 있는 추가 정보가 많이 포함될 수 있기 때문입니다.
윈도우 탐색기에서 시그윈 바로가기를 변경하면 일반적으로 시그윈 바로가기가 Windows 기본 바로가기로 변경됩니다. 그 이후에는 Cygwin이 더 이상 심볼릭 링크로 인식하지 않습니다.
4.12. 찾기 기능에 기본적인 문제가 있습니다. 왜 그럴까요?
시그윈과 함께 제공된 찾기 기능을 사용하고 있는지, 대신 Win32 찾기 명령을 선택하지 않았는지 확인하세요. bash에서 "type find"를 실행하여 올바른 명령을 받고 있는지 확인할 수 있습니다.
현재 디렉터리(기본값)를 포함하여 찾을 경로 인수가 심볼릭 링크인 경우 -follow 옵션을 지정하지 않는 한 find는 해당 디렉터리를 트래버스하지 않습니다. 이 동작은 대부분의 다른 유닉스 구현과 다르지만 변경될 가능성은 높지 않습니다.
find가 충분한 결과를 생성하지 못하거나 일부 디렉터리가 누락되는 것 같다면 find의 최적화 중 하나에 문제가 있는 것일 수 있습니다. DVD-R UDF와 같은 일부 파일 시스템에는 . 및 .. 디렉터리가 없기 때문에 찾기가 혼동될 수 있습니다. 매뉴얼 페이지에서 -noleaf 옵션에 대한 설명서를 참조하십시오.
4.13. su가 작동하지 않는 이유는 무엇인가요?
su 명령은 시그윈 배포판 안팎에서 사용되었지만 시그윈으로 포팅되지 않았으며 작동한 적이 없습니다. 현재 sh-utils의 일부로 설치되어 있지만 다시 한 번 작동하지 않습니다.
차라리 sshd를 설치하고 su 대신 ssh username@localhost를 사용해야 합니다.
su가 작동하지 않는 이유에 대한 기술적 배경은 https://www.cygwin.com/ml/시그윈/2003-06/msg00897.html 및 관련 메시지를 참조하세요.
4.14. man -k, apropos 또는 whatis가 작동하지 않는 이유는 무엇인가요?
man -k, apropos 또는 whatis를 사용하려면 먼저 whatis 데이터베이스를 만들어야 합니다. 다음 명령을 실행하면 됩니다.
mandb
명령을 실행하세요(완료하는 데 몇 분 정도 걸릴 수 있습니다).
4.15. chmod가 작동하지 않는 이유는 무엇인가요?
NTFS 대신 FAT32를 사용하는 경우, FAT32는 권한 정보를 제공하지 않기 때문에 chmod가 실패합니다. CONVERT.EXE를 사용하여 드라이브를 NTFS로 변환하는 것을 고려해야 합니다. FAT와 FAT32는 메모리 카드나 USB 스틱에 사진을 교환하기에 충분하지 않습니다...
다른 경우에는 시그윈이 윈도우의 보안 기능에 따라 유닉스 권한을 표시하려고 시도하므로 Windows ACL이 문제의 원인일 수 있습니다. 시그윈이 Windows 권한을 매핑하는 방법에 대한 자세한 내용은 Cygwin 사용자 가이드(https://cygwin.com/cygwin-ug-net/ntsec.html)를 참조하십시오.
4.16. 셸 스크립트가 작동하지 않는 이유는 무엇인가요?
두 가지 기본적인 문제가 발생할 수 있습니다. 하나는 /bin/sh가 실제로 bash라는 사실입니다. 실제로 /bin/sh가 zsh(MacOS X "Panther") 또는 ksh(Tru64)인 것에 익숙하다면 /bin/sh에서 기대할 수 있는 일부 기능이 누락되어 있을 수 있습니다.
또는 권한 문제일 수 있으며 시그윈이 스크립트가 실행 가능한 스크립트라는 것을 이해하지 못할 수도 있습니다. NTFS 또는 NFS에서는 chmod +x를 사용하여 스크립트를 실행 가능하게 만드세요. 그러나 파일 시스템의 제한으로 인해 chmod가 작동하지 않을 수 있습니다(위의 자주 묻는 질문 항목 참조). 이 경우 시그윈은 파일 내용을 읽어 실행 가능한지 확인해야 합니다. 스크립트가 다음과 같이 시작하지 않는 경우
#! /bin/sh
(또는 스크립트 인터프리터의 경로가 /bin/sh일 필요는 없음)로 시작하지 않으면 시그윈은 실행 가능한 스크립트라는 것을 알지 못합니다. 본 셸 관용구
:
# 이것은 두 번째 줄이며, /bin/sh로 처리한다고 가정합니다.
로 처리한다고 가정합니다.
etc/fstab에서 파일 시스템 플래그 cygexec을 사용하면 시그윈이 마운트 지점 아래의 모든 파일을 실행 파일로 처리하도록 강제할 수 있습니다. 이 플래그는 디렉터리뿐만 아니라 개별 파일에도 사용할 수 있습니다. 그러면 시그윈은 파일이 실행 가능한지 여부를 확인하기 위해 파일을 읽지 않습니다.
4.17. 시그윈에서 인쇄하려면 어떻게 하나요?
lpr은 cygutils 패키지에서 사용할 수 있습니다. 일부 사용 힌트는 Rodrigo Medina가 제공했습니다.
제이슨 티슬러가 a2ps(포스트스크립트에서 멋진 형식의 텍스트를 인쇄하기 위한)와 고스트스크립트(포스트스크립트가 아닌 윈도우 프린터에서 포스트스크립트 파일을 인쇄하기 위한)를 사용하는 방법을 설명하는 몇 가지 메시지를 작성했습니다. https://cygwin.com/ml/시그윈/2001-04/msg00657.html 에서 시작하세요. 이 메일은 오래된 메일이며 a2ps와 파일은 시그윈 배포의 일부로 오랫동안 제공되어 왔습니다.
또는 윈도우 인쇄 명령을 사용할 수도 있습니다. 다음과 같이 입력하세요.
bash$ print /\?
를 입력하면 사용법을 확인할 수 있습니다(셸에서 ?을 이스케이프 처리해야 함).
마지막으로, 파일을 프린터의 공유 이름으로 간단히 cat할 수 있습니다:
bash$ cat myfile > //host/printer
프린터의 양식 피드 버튼을 누르거나 파일에 양식 피드 문자를 추가해야 할 수도 있습니다.
4.18. 국제(유니코드) 문자가 작동하지 않는 이유는 무엇인가요?
국제화는 복잡한 문제입니다. 짧은 대답은 시그윈이 LANG/LC_xxx 환경 변수의 설정에 의존한다는 것입니다. 자세한 답변은 사용자 가이드의 국제화 섹션에서 찾을 수 있습니다.
시그윈은 기본적으로 UTF-8을 사용합니다. 다른 문자 집합을 사용하려면 LC_ALL, LC_CTYPE 또는 LANG 환경 변수를 설정해야 합니다.
4.19. 내 응용 프로그램이 국제 문자를 인쇄하지만 회색 상자만 표시됩니다.
시그윈 프로그램의 경우 LC_ALL, LC_CTYPE 또는 LANG 환경 변수에 의해 결정된 문자 집합이 시그윈 터미널 옵션의 텍스트 페이지에 설정된 문자 집합과 일치하지 않을 가능성이 높습니다. 터미널의 옵션에서 로케일을 설정하면 LANG 변수가 그에 따라 설정됩니다.
시그윈 터미널에서 시그윈이 아닌 프로그램은 일반적으로 로캘 환경 변수에 주의하지 않습니다. 대신 소위 콘솔 코드페이지를 사용하는 경우가 많은데, 이 코드페이지 번호는 cmd /c chcp 명령 뒤에 적절한 윈도우 코드페이지 번호를 붙여 확인할 수 있습니다. Cygwin의 기본 UTF-8 문자 집합에 대한 코드 페이지 번호는 65001입니다.
4.20. 디엘엘의 사본을 여러 개 가져도 되나요?
예, 엄격하게 분리된 설치에서 사용한다면 가능합니다.
시그윈 디엘엘은 여러 프로세스 간의 다양한 공유 상황을 처리해야 합니다. 프로세스 테이블을 유지해야 합니다. 시그윈 DLL의 설치 경로를 기반으로 하는 마운트 테이블을 유지해야 합니다.
이러한 이유로 시그윈 디엘엘은 자체 설치 경로에서 생성된 해시 값을 기반으로 공유 리소스를 유지 관리합니다. 컴퓨터의 각 시그윈 DLL은 Cygwin 설치를 구성하며, Cygwin DLL이 있는 디렉터리는 "/bin"으로, 상위 디렉터리는 "/"로 취급됩니다.
따라서 단일 머신에 두 개 이상의 개별 시그윈 배포판을 설치할 수 있습니다. 이러한 각 설치는 고유한 시그윈 디엘엘을 사용하며 기본 POSIX 경로, 프로세스 테이블 또는 설치를 유지 관리하는 데 사용되는 기타 공유 리소스를 공유하지 않습니다.
그러나 깔끔한 분리를 위해서는 한 시그윈 설치의 실행 파일을 다른 시그윈 설치에서 실행 중인 프로세스에서 실행하려고 시도하지 않아야 합니다. 이 방법은 효과가 있을 수도 있고 없을 수도 있지만, 결과가 예상과 다를 가능성이 매우 높습니다.
"공유 영역이 손상되었습니다" 또는 "공유 영역 버전 불일치" 오류가 발생하면 서로 충돌하는 여러 버전의 cygwin1.dll이(가) 동시에 실행되고 있다는 뜻입니다. 서로 다른 시그윈 설치의 실행 파일을 혼합하는 것 외에도, 예를 들어 모든 시그윈 앱(sshd와 같은 서비스 포함)을 미리 종료하지 않고 Cygwin 패키지를 업데이트하는 경우와 같이 단일 Cygwin 설치가 있는 경우에도 이 오류가 발생할 수 있습니다.
시그윈 프로젝트에 의해 승인된 유일한 디엘엘은 이 프로그램에 의해 제어되는 디렉터리에 설치된 시그윈 설치 프로그램을 실행하여 얻을 수 있는 DLL입니다. 시스템에 다른 버전이 설치되어 있고 Cygwin 프로젝트의 도움을 받으려면 Cygwin 설치 프로그램에 의해 설치되지 않은 모든 DLL을 삭제하거나 이름을 바꿔야 합니다.
이 문제를 일으키는 여러 버전의 디엘엘을 찾으려는 경우, 메모리에 여전히 로드된 DLL이 원인일 수 있으므로 먼저 재부팅하세요. 그런 다음 윈도우 시스템 찾기 유틸리티를 사용하여 경로의 구성 요소('type'이 하는 것처럼) 또는 시그윈 마운트 파일 시스템('find'가 하는 것처럼)뿐만 아니라 전체 시스템을 검색하세요.
4.21. 위의 내용을 읽었지만 시그윈을 제품과 함께 번들로 제공하여 고객 사이트에 배송하고 싶습니다. 사용자가 설치한 시그윈과 충돌하지 않고 이 작업을 수행하려면 어떻게 해야 하나요?
일반적으로 설치를 별도로 유지하면 아무런 문제가 발생하지 않습니다. 그러나 사용자의 편의를 위해, 그리고 여전히 발생할 수 있는 잠재적인 문제를 피하기 위해 사용자 컴퓨터에 이미 설치되어 있는 시그윈과 제품을 통합하거나, 설치되어 있지 않은 경우 사용자를 대신하여 공식 시그윈 배포판을 설치하고 거기에서 도구를 통합하는 것을 고려하세요. (이 작업을 쉽게 할 수 있는 도구를 작성했다면 다른 사람들이 사용할 수 있도록 기여하는 것도 고려하세요).
4.22. 시그윈을 내 제품에 무료로 번들로 제공할 수 있나요?
예. LGPL 라이선스가 적용된 시그윈 버전 2.5.2부터는 가능하지만 상호 운용성상의 이유로 권장되지는 않습니다.
2.5.2 이전 시그윈 버전은 GPL 라이선스였습니다. 이전 버전의 cygwin1.dll을 배포하려면 GPL 약관에 따라 해당 cygwin1.dll을 빌드하는 데 사용된 정확한 소스 코드를 배포할 의향이 있어야 합니다. 이전 cygwin1.dll과 링크되는 애플리케이션을 배포하는 경우, 해당 애플리케이션의 소스 코드를 GPL 호환 라이선스에 따라 제공해야 합니다.
4.23. 하지만 어떤 애플리케이션이 최신 디엘엘 위에 이전 시그윈 DLL을 설치하면 내 애플리케이션이 손상되지 않나요?
"중단"의 의미가 무엇인지에 따라 다릅니다. 애플리케이션이 시그윈의 /bin 디렉터리가 아닌 다른 위치에 시그윈 디엘엘 버전을 설치하는 경우 Q: 4.21의 규칙이 적용됩니다. 애플리케이션이 이전 버전의 DLL을 /bin에 설치하는 경우 애플리케이션 제공업체에 큰 소리로 항의해야 합니다.
시그윈 디엘엘은 이전 버전과의 호환성을 위해 노력하므로 최신 버전의 DLL은 항상 이전 실행 파일과 함께 작동해야 합니다. 따라서 일반적으로 시스템에 항상 한 가지 버전의 DLL을 유지하는 것이 가장 좋으며, 설치된 배포판과 일치하는 최신 버전이어야 합니다.
4.24. 시그윈에서 XYZ 패키지를 사용할 수 없는 이유는 무엇인가요?
아마도 유지 관리할 의향이나 능력이 없는 사람이 없기 때문일 것입니다. 시간이 걸리며 시그윈 팀의 우선 순위는 시그윈 패키지입니다. 나머지는 자원봉사로 이루어집니다. 기여하고 싶으신가요? https://cygwin.com/packaging.html 참조.
4.25. XYZ의 시그윈 패키지가 왜 그렇게 오래되었나요?
(또한: XYZ 패키지 버전이 XYZ 웹 사이트에서 다운로드할 수 있는 버전보다 오래된 이유는 무엇인가요? 패키지 XYZ 버전이 리눅스 시스템에 설치한 버전보다 오래된 이유는 무엇인가요? 시그윈에 이전 버전의 패키지 XYZ만 작동해야 하는 특별한 기능이 있나요?)
시그윈 배포판의 모든 패키지에는 패키지 업데이트를 보내는 책임이 있는 관리자가 있습니다. 이 사람은 자원 봉사자이며, 패키지의 공식 개발자와 같은 사람이 아닌 경우가 거의 없습니다. 패키지의 버전이 오래된 것 같다면 그 이유는 보통 패키지를 유지 관리하는 사람이 아직 업데이트를 하지 않았기 때문입니다. 드물게 최신 패키지는 실제로 유지 관리자가 작업 중인 복잡한 변경 사항이 필요합니다.
긴급하게 업데이트가 필요한 경우 사이버윈 메일링 리스트에 정중하게 메시지를 보내 관리자에게 핑을 보내는 것도 괜찮습니다. 그러나 관리자가 패키지를 업데이트할 시간이 있거나 요청에 대한 응답을 받을 수 있다는 보장은 없습니다.
여기서 운영 용어는 "자원 봉사"라는 점을 기억하세요.
4.26. 다른 드라이브에 액세스하려면 어떻게 해야 하나요?
여기에는 약간의 유연성이 있습니다.
시그윈에는 마운트되지 않은 드라이브에 대한 "cygdrive 접두사"가 내장되어 있습니다. 예를 들어 Z: 드라이브에 '/cygdrive/z/'로 액세스할 수 있습니다.
일부 애플리케이션(특히 bash)에서는 윈도우 백슬래시('\') 대신 포식스 슬래시('/')를 사용하여 익숙한 Windows <드라이브>:/경로/를 사용할 수 있습니다. (하지만 아래 경고를 참조하세요!) 이렇게 하면 명백한 방식으로 Windows 경로에 매핑되지만, 내부적으로 마운트(기본 또는 명시적)에 따라 시그윈 경로를 사용하도록 변환됩니다. 예를 들어
bash$ cd C:/윈도우
bash$ pwd
/cygdrive/c/윈도우
및
bash$ cd C:/시그윈
bash$ pwd
/
를 기본 설정으로 사용합니다. 윈도우 경로에 백슬래시를 사용할 수도 있지만 셸에서 이스케이프 처리해야 합니다.
경고: 다른 마운트 지점을 통해 다른 포식스 경로가 동일한 윈도우 디렉터리에 매핑될 수 있기 때문에 Windows 경로에서 포식스 경로로 이동하는 데 약간의 모호함이 있습니다. 다른 마운트 지점은 bin모드 또는 텍스트 모드일 수 있으므로 시그윈 앱의 동작은 해당 위치에 도달하는 데 사용된 포식스 경로에 따라 달라질 수 있기 때문에 이 점이 중요합니다.
드라이브를 명시적으로 포식스 경로에 마운트하면 윈도우 경로의 모호함을 피하고 "/cygdrive"를 입력하는 것을 피할 수 있습니다. 예를 들어
bash$ mkdir /c
bash$ mount c:/ /c
bash$ ls /c
그러면 /cygdrive/c/윈도우가 /c/Windows가 되어 타이핑이 조금 더 줄어듭니다.
마운트 지점을 영구적으로 유지하려면 /etc/fstab 파일에 마운트 지점을 입력해야 한다는 점에 유의하세요. 마운트 명령은 현재 시그윈 세션의 수명 기간 동안만 마운트 지점을 추가합니다.
또한 /etc/fstab 파일을 사용하여 기본 cygdrive 접두사를 변경하고 빈모드 또는 텍스트모드 여부를 변경할 수 있습니다. 자세한 내용은 시그윈 사용자 가이드(https://cygwin.com/cygwin-ug-net/using.html#mount-table)를 참조하세요.
4.27. 시그윈 콘솔 창에 복사하여 붙여넣으려면 어떻게 해야 하나요?
먼저 표준 콘솔 창 대신 mintty를 사용해 보세요. 민트티에서는 왼쪽 마우스로 선택해도 복사되고 가운데 마우스로 붙여넣기할 수 있습니다. 이보다 더 쉬울 수는 없습니다!
윈도우의 콘솔 창에서 속성 대화 상자를 엽니다. 옵션에는 '빠른 편집 모드'라는 이름의 토글 버튼이 있습니다. 이 버튼은 켜져 있어야 합니다. 속성을 저장합니다.
.inputrc 파일에 다음 줄을 추가하여 클립보드에서 붙여넣기할 수 있도록 삽입 키를 바인딩할 수도 있습니다:
"\e[2~": 클립보드에서 붙여넣기
4.28. 시그윈과 함께 어떤 방화벽을 사용해야 하나요?
Kerio 개인용 방화벽, ZoneLabs 무결성 데스크톱 및 윈도우 내장 방화벽에 대한 좋은 보고가 있었습니다. ZoneAlarm 및 Norton Internet Security를 포함한 다른 잘 알려진 제품들은 일부 사용자에게는 문제를 일으켰지만 다른 사용자에게는 정상적으로 작동했습니다. 지난 보고에 따르면, Agnitum 전초 기지는 시그윈과 작동하지 않았습니다. 이상한 연결 관련 문제가 발생하면 방화벽을 비활성화하는 것이 좋은 문제 해결 단계입니다(실행 중인 다른 모든 애플리케이션, 특히 색인 검색과 같은 리소스 집약적인 프로세스를 닫거나 비활성화하는 것과 마찬가지로).
전반적으로 시그윈은 어떤 방화벽을 사용하든 상관하지 않습니다. 몇 가지 드문 예외는 소켓 코드와 관련이 있습니다. 시그윈은 소켓을 사용하여 IPC와 같은 많은 기능을 구현합니다. 일부 지나치게 열성적인 방화벽은 '계층화된 서비스 공급자' 에이피아이를 사용하여 윈샥 스택에 깊숙이 설치하고 전체에 훅을 설치합니다. 안타깝게도 메일링 리스트 아카이브에는 잘못 작성된 방화벽 유형 소프트웨어로 인해 문제가 발생한 사례들이 산재해 있습니다. 이러한 제품 중 상당수는 방화벽을 비활성화한다고 해서 이러한 변경 사항이 제거되지 않으며 완전히 제거해야 한다는 점에 유의하세요.
시그윈의 정상적인 작동을 방해하는 것으로 알려진 애플리케이션 목록은 BLODA를 참조하세요.
4.29. Unix와 윈도우 간에 파일을 공유하려면 어떻게 해야 하나요?
개발 중에는 Samba와 NFS를 실행하는 Linux 박스와 윈도우 머신이 있습니다. 우리는 종종 Linux에서 크로스 컴파일러로 빌드하고 바이너리와 소스를 Windows 시스템으로 복사하거나 Samba가 설치된 파티션에서 직접 가지고 놀기도 합니다. 또는 마이크로소프트 NFS 클라이언트를 사용하여 Windows에서 Linux의 NFS 공유를 사용하기도 합니다. 그리고 scp, ftp, rsync와 같은 도구가 있습니다.
4.30. 시그윈은 대소문자를 구분하나요?
몇몇 유닉스 프로그램에서는 철자는 같지만 대소문자가 다른 파일 이름을 사용할 수 있습니다. 대표적인 예가 Makefile과 makefile을 원하는 Perl의 구성 스크립트입니다. 윈도우는 대소문자만 다른 파일 간의 차이를 구분할 수 없으므로 구성이 실패합니다.
이 문제를 해결하기 위해 시그윈은 대소문자 구분을 지원합니다. 이 기능을 사용하는 방법에 대한 자세한 설명은 시그윈 사용자 가이드(https://cygwin.com/cygwin-ug-net/using-specialnames.html)를 참조하세요.
4.31. 도스 특수 파일 이름은 어떻게 하나요?
윈도우에서는 루트 파일 이름이나 확장자 부분으로 com1, lpt1, aux 등의 파일 이름을 지정할 수 없습니다. 그렇게 하면 문제가 발생합니다. 유닉스 프로그램은 이러한 이름을 피하지 않기 때문에 문제가 생길 수 있습니다. 예를 들어, perl 배포판에는 aux.sh라는 파일이 있습니다. perl 구성은 aux.sh가 있는지 확인하려고 시도하지만 마법 문자 'aux'가 포함된 파일에 대한 작업은 중단됩니다.
적어도 기본 윈도우 도구를 사용할 때는 이런 일이 발생합니다. 시그윈은 이러한 파일 이름을 잘 처리할 수 있습니다. 파일 이름으로 가능한 것과 불가능한 것에 대한 자세한 설명은 사용 설명서(https://cygwin.com/cygwin-ug-net/using-specialnames.html)를 참조하세요.
4.32. 도구가 중단되면 어떻게 다시 시작하나요?
문제가 발생하여 어떤 이유로 도구가 중단되는 경우(aux.sh라는 파일을 읽어보면 쉽게 알 수 있음), 먼저 ^C를 눌러 bash 또는 cmd 프롬프트로 돌아가 보세요.
다른 셸을 시작해도 애플리케이션이 실행되지 않는다면 중단된 프로세스가 여전히 어딘가에서 실행되고 있을 가능성이 높습니다. 작업 관리자, pview 또는 유사한 유틸리티를 사용하여 프로세스를 종료하세요.
그리고 다른 모든 방법이 실패하면 항상 재설정 버튼/전원 스위치가 있습니다. 이론적으로는 그럴 필요는 없지만요.
4.33. 왜 이상한 디렉토리 구조인가요?
왜 /lib와 /usr/lib(그리고 /bin, /usr/bin)는 같은 것을 가리키나요?
심볼릭 링크 대신 마운트를 사용하는 이유는 무엇인가요?
디스크 루트(예: C:\)를 시그윈 루트로 사용할 수 있나요? 왜 권장하지 않나요?
기본 위치에 새로 설치한 후 마운트 지점은 다음과 같이 표시됩니다:
bash$ mount
C:\시그윈\bin on /usr/bin 유형 ntfs (바이너리,자동)
C:\시그윈\lib on /usr/lib 유형 ntfs (바이너리,자동)
C:\시그윈 on / 유형 ntfs (바이너리,자동)
C: on /cygdrive/c 유형 ntfs (바이너리,포식스=0,사용자,누마운트,자동)
이는 의도적인 것으로, 자신이 무엇을 하고 있는지 잘 모르는 경우가 아니라면 이러한 마운트를 실행 취소해서는 안 됩니다.
다양한 애플리케이션과 패키지가 /lib 또는 /usr/lib(유사하게 /bin 또는 /usr/bin)에 설치될 것으로 예상할 수 있습니다. 이 두 디렉터리를 구분하고 추적하려고 애쓰는 대신(때때로 복제나 심볼릭 링크가 필요할 수도 있음), 실제 디렉터리는 하나만 유지하면서 그에 상응하는 방법으로 액세스하기로 결정했습니다.
이를 위해 심볼릭 링크도 고려되었지만, 삼바 드라이브에서 항상 작동하는 것은 아니기 때문에 제외되었습니다. 또한 마운트를 해결하는 데 디스크 액세스가 필요하지 않으므로 처리 속도가 더 빠릅니다.
시그윈이 아닌 애플리케이션은 시그윈 마운트(또는 대부분의 심볼릭 링크)를 인식하지 못한다는 점에 유의하세요. 예를 들어, WinZip을 사용하여 Cygwin 패키지의 tar 배포를 압축 해제하는 경우 올바른 Cygwin 경로에 설치되지 않을 수 있습니다. 그러니 이렇게 하지 마세요!
자신이 무엇을 하고 있는지 잘 알고 그 결과에 대처할 준비가 되어 있지 않다면 시그윈 루트 디렉터리를 드라이브의 루트 디렉터리와 동일하게 만들지 않는 것이 좋습니다. 일반적으로 시그윈 계층 구조는 C:\와 분리되어 있으면 유지 관리가 더 쉽습니다. 우선, (예를 들어) \bin 및 \lib 디렉터리를 생성할 수 있는 다른 (Cygwin이 아닌) 애플리케이션과의 충돌 가능성을 피할 수 있습니다. (지금은 그런 것이 설치되어 있지 않을 수도 있지만, 앞으로 추가할 수 있는 것이 무엇인지 누가 알겠습니까?).
4.34. 시그윈과 같은 안티바이러스 프로그램은 어떻게 작동하나요?
사용자들은 NT(및 기타?)용 NAI(이전 McAfee) VirusScan이 시그윈과 호환되지 않는다고 보고했습니다. 이는 새로 로드된 공유 메모리를 cygwin1.dll에서 검사하려고 시도하기 때문이며, 이로 인해 포크()가 실패하여 많은 도구에 혼란을 일으킬 수 있습니다. (하지만 이 문제가 여전히 존재하는지는 확인되지 않았습니다.)
tar.gz 아카이브의 압축을 풀 때 시스템이 중단된다는 보고가 여러 번 있었습니다. 이는 분명히 VirusScan의 버그이므로 NAI에 보고해야 합니다. 유일한 해결 방법은 이러한 파일에 액세스할 때 VirusScan을 비활성화하는 것입니다. 이는 설정 중에 문제가 될 수 있으며 해당 자주 묻는 질문 항목에 설명되어 있습니다.
일부 사용자는 바이러스 백신 소프트웨어가 활성화되어 있을 때 시그윈을 사용할 때 성능이 크게 저하된다고 보고합니다. 바이러스 백신 소프트웨어를 완전히 비활성화하는 대신 콘텐츠가 검사에서 제외되는 디렉터리를 지정할 수 있습니다. 기본 설치에서 이 디렉터리는 C:\시그윈\bin입니다. 물론, 이는 시그윈이 아닌 적대적인 프로그램에 의해 악용될 수 있으므로 사용자 책임하에 이 작업을 수행하세요.
시그윈의 정상적인 작동을 방해하는 것으로 알려진 애플리케이션 목록은 BLODA를 참조하십시오.
4.35. GNU Emacs의 시그윈 포트가 있습니까?
예. 이맥스 패키지를 설치하세요. 이것은 터미널 창에서 GNU 이맥스를 실행하는 데 필요한 모든 것을 제공합니다. X11(https://x.cygwin.com/) 지유아이도 사용하려면 emacs-X11 패키지를 설치하세요. 두 경우 모두 'emacs' 또는 '/usr/bin/emacs'를 입력하여 이맥스를 실행합니다.
4.36. XEmacs의 시그윈 포트가 있나요?
예. 세 가지 모드에서 사용할 수 있습니다:
X11 (https://x.cygwin.com/) 지유아이
이맥스를 시작하기 전에 DISPLAY 환경 변수를 설정해야 합니다.
bash$ DISPLAY=127.0.0.1:0 xemacs &
윈도우 기본 지유아이
xemacs를 시작하기 전에 DISPLAY 환경 변수를 설정 해제해야 합니다.
bash$ DISPLAY= xemacs &
콘솔 모드
터미널(기본 또는 X11) 창에서 -nw로 xemacs를 시작합니다.
bash$ xemacs -nw
모든 표준 패키지를 XEmacs와 함께 사용하려면 다음 두 가지 패키지를 다운로드해야 합니다:
xemacs-sumo - XEmacs 표준 패키지
xemacs-mule-sumo - XEmacs MULE(다중 언어 이맥스) 패키지
4.37. 이전 심볼릭 링크 중 일부가 더 이상 작동하지 않는 이유는 무엇인가요?
시그윈은 여러 문자 집합을 지원합니다. 시그윈으로 만든 심볼릭 링크는 모든 문자 집합에서 이식 가능한 UTF-16 문자 집합을 사용합니다. 이전 심볼 링크는 현재 윈도우 코드페이지를 사용하여 작성되었으므로 모든 문자 집합에서 이식되지 않습니다. 심볼릭 링크의 대상이 더 이상 확인되지 않는다면 심볼릭 링크가 네이티브 비 ASCII 문자를 사용하는 대상 파일명을 가리키고 있으며 심볼릭 링크를 만들 때와 다른 문자 집합을 사용하고 있을 가능성이 높습니다.
해결 방법 심볼 링크를 삭제하고 새 시그윈에서 다시 생성합니다. 새 심볼 링크는 앞으로 어떤 문자 집합을 사용하든 대상을 올바르게 가리킬 것입니다.
4.38. 삼바 마운트 파일 시스템에서 심볼릭 링크가 작동하지 않는 이유는 무엇인가요?
Samba의 기본 심볼릭 링크는 도스 SYSTEM 파일 속성으로 표시됩니다. Samba는 기본적으로 이 속성을 활성화하지 않습니다. 이 속성을 활성화하려면 Samba 설명서를 참조한 다음 다음 줄을 삼바 구성 파일에 추가하세요:
map system = yes
create mask = 0775
0775는 0010 비트가 설정되어 있는 한 아무 값이나 사용할 수 있습니다.
또는 윈도우 바로가기를 심볼릭 링크로 사용할 수도 있습니다. CYGWIN 환경 변수 옵션 "winsymlinks:lnk" https://cygwin.com/cygwin-ug-net/using-cygwinenv.html 참조 삼바는 재구문 지점을 지원하지 않으므로 심볼릭 링크를 만드는 일부 방법을 사용할 수 없습니다.
4.39. 시그윈 1.7.34 이상으로 업데이트한 후 ssh를 사용한 공개 키 인증이 실패하는 이유는 무엇인가요?
이는 시그윈의 POSIX ACL 처리에서 오랜 보안 문제를 수정한 결과입니다. IEEE 1003.1e 초안 17에서는 ACL의 보조 사용자 및 그룹 항목의 권한이 그룹 권한 마스크에 반영되도록 정의하여 파일의 기본 그룹의 권한과 ACL의 보조 사용자 및 그룹의 모든 권한이 그룹 권한 마스크에 반영되도록 합니다. 그 배경에는 표준 POSIX 권한 비트가 다른 사람이 파일에 대해 잠재적으로 보이지 않는 추가 권한을 가지고 있다는 사실을 반영하는 방식이 있습니다. 이 비교적 복잡한 인터페이스는 IEEE 1003.1("POSIX.1")을 준수하는 애플리케이션이 ACL이 있는 시스템에서 예상대로 작동하도록 보장하기 위해 정의되었습니다.
그렇다면 이는 여러분의 상황에 어떤 의미일까요? 일반적으로 이는 개인 키 파일(예: ~/.ssh/id_rsa)의 권한이 너무 열려 있다는 의미입니다. OpenSSH는 개인 키 파일의 권한이 0600일 것으로 예상합니다. 기본 SSH2 RSA 키 파일을 예로 들어 보겠습니다:
ls -l .ssh/id_rsa
-rw------- 1 사용자 그룹 1766 Aug 26 2013 .ssh/id_rsa
그러나 다른 계정이 파일을 읽을 수 있는 경우 키가 손상될 가능성이 있습니다. 파일에 bad_guys 그룹에 대한 추가 rw- 권한이 있다고 가정해 보세요. 시그윈 1.7.33까지는 다음과 같이 표시되었을 것입니다:
ls -l .ssh/id_rsa
-rw-------+ 1 사용자 그룹 1766 Aug 26 2013 .ssh/id_rsa
권한 문자열 뒤에 추가 + 문자가 있는 것을 알 수 있습니다. 이는 ACL에 추가 ACL 항목이 있음을 나타냅니다. 그러나 POSIX 권한 비트만 확인하는 애플리케이션(ssh도 그 중 하나입니다!)은 파일에 대한 권한이 0600이기 때문에 이 사실을 알지 못합니다.
시그윈 1.7.34부터 추가 권한은 IEEE 1003.1e 초안 17에 따라 그룹 권한 비트에 반영됩니다:
ls -l .ssh/id_rsa
-rw-rw----+ 1 사용자 그룹 1766 Aug 26 2013 .ssh/id_rsa
이제 ssh는 파일에 추가 권한이 있음을 인식하고 불만을 표시합니다. .ssh/authorized_keys 파일에 너무 열린 권한이 있는 경우에도 동일한 문제가 발생합니다. 하지만 클라이언트 측에서는 갑자기 비밀번호를 묻는 것 외에는 어떤 도움 텍스트도 표시되지 않습니다. 이는 서버의 ~/.ssh/authorized_keys 파일을 자세히 살펴볼 수 있는 좋은 힌트입니다.
개인 키 파일 또는 ~/.ssh/authorized_keys 파일의 권한을 수정하려면 -b 옵션과 함께 setfacl 명령을 사용하기만 하면 됩니다. 이렇게 하면 모든 추가 ACL 항목이 제거되어 권한이 너무 개방되지 않도록 수정됩니다:
ls -l .ssh/id_rsa
-rw-rw----+ 1 사용자 그룹 1766 Aug 26 2013 .ssh/id_rsa
setfacl -b .ssh/id_rsa
ls -l .ssh/id_rsa
-rw------- 1 사용자 그룹 1766 Aug 26 2013 .ssh/id_rsa
위의 명령을 실행한 후 두 번째 ls 명령을 실행해도 여전히 -rw-rw---- 권한이 부여되는 경우 파일의 기본 그룹이 사용자의 개인 그룹이기 때문일 가능성이 높습니다:
$ ls -l .ssh/id_rsa
-rw-rw---- 1 프레드 프레드 1766 Aug 26 2013 .ssh/id_rsa
윈도우 보안 시스템에서는 그룹과 사용자를 거의 동일하게 취급하므로 해당 파일에 대한 사용자 또는 그룹 권한을 변경하면 사용자와 그룹 모두에 변경 사항이 반영됩니다. 사실상 모드 0600은 모드 0660이 됩니다. 이러한 파일을 사용자만 읽을 수 있도록 하려는 것이므로 이 문제를 해결하는 방법은 간단합니다:
$ chgrp `id -g` ~/.ssh/*
이렇게 하면 이러한 파일의 그룹이 로컬 구성에 따라 Users와 같은 기본 그룹으로 재설정됩니다. 그래도 문제가 해결되지 않으면 다음과 같이 시도해 볼 수 있습니다:
chgrp None ~/.ssh/*
이 그룹은 항상 존재하지만 영어 이외의 윈도우 버전에서는 이름이 다릅니다. 사이트에서 Windows 도메인을 사용하는 경우 로컬 그룹 대신 도메인 그룹을 사용할 수도 있습니다. 예를 들어 도메인 사용자 그룹을 대신 사용할 수 있습니다.
setfacl에 대한 자세한 내용은 https://cygwin.com/cygwin-ug-net/setfacl.html 를 참조하세요.
4.40. 시그윈 1.7.34로 업데이트한 후 내 .rhosts 파일이 더 이상 r로그인에서 인식되지 않는 이유는 무엇인가요?
이 문제는 SSH의 키 파일과 완전히 동일합니다. Q: 4.39를 참조하세요.
해결 방법은 동일합니다:
$ ls -l .rhosts
-rw-rw----+ 1 사용자 그룹 42 Nov 12 2010 .rhosts
$ setfacl -b .rhosts
$ ls -l .rhosts
-rw------- 1 사용자 그룹 42 Nov 12 2010 .rhosts
4.41. 시그윈 1.7.34로 업데이트한 후 내 파일에 추가 권한이 있는 이유는 무엇인가요?
이 문제는 SSH의 키 파일과 정확히 동일합니다. Q: 4.39를 참조하세요.
해결 방법은 동일합니다:
$ ls -l *
-rw-rwxr--+ 1 사용자 그룹 42 Nov 12 2010 file1
-rw-rwxr--+ 1 사용자 그룹 42 2010년 11월 12일 파일2
$ setfacl -b *
$ ls -l *
-rw-r--r-- 1 사용자 그룹 42 Nov 12 2010 file1
-rw-r--r-- 1 사용자 그룹 42 Nov 12 2010 file2
새로 만든 파일에 예기치 않은 권한이 있을 수도 있습니다:
터치 foo
ls -l foo
-rw-rwxr--+ 1 사용자 그룹 42 Nov 12 2010 foo
이는 파일을 만드는 디렉터리에 새로 만든 파일과 하위 디렉터리에 상속되는 원치 않는 기본 ACL 항목이 있다는 의미일 수 있습니다. 해결책은 역시 동일합니다:
setfacl -b .
터치 바
$ ls -l bar
-rw-r--r-- 1 사용자 그룹 42 Nov 12 2010 bar
4.42. Tk 프로그램이 더 이상 작동하지 않는 이유는 무엇인가요?
시그윈과 함께 배포된 이전 버전의 Tcl/Tk(예: tclsh84.exe, wish84.exe)는 실제로 해당 도구의 "시그윈 버전"이 아니었습니다. 이들은 네이티브 라이브러리로 빌드되었기 때문에 Cygwin 마운트나 심볼릭 링크를 이해하지 못했습니다. 이로 인해 실제 Cygwin 프로그램과 상호 작용하는 모든 종류의 문제가 발생했습니다.
2012년 2월부터 이 라이브러리는 시그윈의 POSIX 에이피아이와 X11을 사용하는 Tcl/Tk 버전으로 대체되어 지유아이 기능을 제공합니다. Tk 앱을 시작하려고 할 때 다음과 같은 메시지가 표시되는 경우:
애플리케이션 초기화에 실패했습니다: "" 표시를 위해 연결할 수 없습니다.
그런 다음 X 서버를 시작하거나 이미 실행 중인 경우 DISPLAY 변수를 적절한 값으로 설정해야 합니다. 시그윈 배포판에는 X 서버가 포함되어 있으며, 설치 및 시작 지침은 시그윈/X 사용자 가이드를 참조하세요.
4.43. 시그윈을 방해하는 것으로 밝혀진 애플리케이션은 무엇인가요?
때때로 사람들은 합리적인 설명이 없는 것처럼 보이는 시그윈 및 시그윈 패키지에서 이상한 오류와 문제를 보고했습니다. 이들이 보고하는 가장 일반적인 증상 중에는 포크 실패, 메모리 누수, 파일 액세스 거부 문제가 있습니다. 이러한 문제를 추적한 결과, 동일한 PC에 설치된 다른 소프트웨어의 간섭으로 인해 발생하는 경우가 많습니다. 특히 안티바이러스, 안티스파이웨어, 방화벽 애플리케이션과 같은 보안 소프트웨어는 탐색기 셸과 기본 커널을 포함하여 시스템의 다양한 부분에 후크를 설치하여 기능을 구현하는 경우가 많습니다. 때때로 이러한 후크는 완전히 투명한 방식으로 구현되지 않아 Cygwin과 같은 다른 프로그램의 작동에 영향을 미치는 동작 변경을 유발합니다.
문제를 일으키는 것으로 밝혀진 소프트웨어는 다음과 같습니다:
AR 소프트 RAM 디스크
ATI Catalyst(일부 버전)
AVAST(파일 시스템 및 행동 실시간 차단 비활성화)
Avira AntiVir
BeyondTrust 파워브로커
BitDefender
Trustware의 Bufferzone
ByteMobile 노트북 최적화 클라이언트
COMODO 방화벽 프로
COMODO 인터넷 보안
ConEmu("ConEmuHk 주입"을 비활성화하거나 ConEmuHk 설명서를 참조)
Citrix 메타프레임 프레젠테이션 서버/XenApp(Citrix 지원 페이지 참조)
크레던트 가디언 쉴드
CylancePROTECT
Earthlink 토탈 액세스
Forefront TMG
Google 데스크톱
Iolo 시스템 메카닉/안티바이러스/방화벽
케리오, 아그니툼 또는 존알람 개인 방화벽
LanDesk
Lavasoft 웹 컴패니언
레노버 IPS 코어 서비스(ipssvc)
레노버 래피드부트 쉴드
"로지텍 프로세스 모니터" 서비스가 포함된 로지텍 웹캠 소프트웨어
Mac 유형
NOD32 바이러스 백신
NVIDIA GeForce(일부 버전)
Norton/McAfee/Symantec 안티바이러스 또는 안티스파이웨어
PC 도구 스파이웨어 닥터
Panda 인터넷 보안
DLA 구성 요소가 포함된 Sonic Solutions 레코딩 소프트웨어(DLA 비활성화 시)
Sophos 안티 바이러스 7
스파이봇 S&D 티타이머
Embassy Trust Suite 및 Embassy Security Center를 포함하여 wxvault.dll을 사용하는 Wave Systems Corp의 다양한 프로그램
바이러스 백신이 포함된 Webroot 스파이 스위퍼
윈도우 디펜더
윈도우 라이브원케어
IBM 보안 트러스티어 래포트(해당 홈페이지 참조)
때때로 이러한 문제는 문제가 되는 소프트웨어를 일시적으로 또는 부분적으로 비활성화하여 해결할 수 있습니다. 예를 들어, 바이러스 백신에서 온-액세스 검사를 비활성화하거나 시그윈 설치 루트 아래의 파일을 무시하도록 구성할 수 있습니다. 안타깝게도 소프트웨어를 비활성화해도 작동하지 않는 경우가 많은데, 운영 체제에 후크를 걸고 있는 많은 애플리케이션은 비활성화해도 후크가 설치된 채로 완전히 투명한 통과 모드로 설정되어 있기 때문입니다. 때때로 이 통과 모드가 투명하지 않아 후크가 여전히 시그윈을 방해하는 경우가 있는데, 이러한 경우 소프트웨어를 완전히 제거해야 정상 작동으로 복구할 수 있습니다.
발생할 수 있는 몇 가지 증상은 다음과 같습니다:
무작위 포크() 실패
시스템의 모든 프로세스에 자신을 로드하는 후크 디엘엘로 인해 발생합니다. POSIX 포크() 의미론에 따르면 자식 프로세스의 메모리 맵은 부모 프로세스의 레이아웃과 정확히 복제되어야 합니다. 이러한 DLL 중 하나가 부모에서 로드된 주소와 자식 메모리 공간의 다른 기본 주소에 로드되면 결국 부모에서 다른 DLL에 속해 있던 공간을 차지하게 될 수 있습니다. 시그윈이 하위의 동일한 주소에서 원본 DLL을 로드할 수 없으면 포크() 호출이 실패해야 합니다.
파일 액세스 문제
일부 프로그램(예: 온 액세스 스캔 기능이 있는 바이러스 스캐너)은 컴퓨터에서 실행 중인 다른 모든 소프트웨어가 액세스하는 모든 파일을 스캔하거나 다른 방식으로 작동합니다. 어떤 경우에는 파일을 실제로 사용하는 소프트웨어가 파일을 닫은 후에도 파일에 대한 열린 핸들을 유지할 수 있습니다. 이로 인해 삭제, 이름 변경, 이동 등의 작업이 액세스 거부 오류와 함께 실패하는 것으로 알려져 있습니다. 극단적인 경우에는 스캐너가 파일 핸들을 유출하여 커널 메모리 고갈로 이어지는 것으로 알려져 있습니다.
네트워킹 문제
방화벽 소프트웨어는 때때로 시그윈에 대해 약간 재미있어합니다. 현재로서는 그 이유를 알 수 없습니다. 시그윈은 표준 Winsock2 에이피아이만 사용하지만, 아마도 방화벽 게시자가 잘 테스트하지 않는 덜 자주 사용되는 방식일 수 있습니다. 원인 모를 연결 실패 또는 송수신되는 네트워크 데이터의 손상 등의 증상이 나타납니다.
메모리 및/또는 핸들 누수
윈도우 운영 체제에 연결되는 일부 애플리케이션은 시그윈과 상호 작용할 때 할당된 메모리 또는 기타 시스템 리소스를 누수시키는 버그를 나타냅니다. 증상으로는 메모리 부족 오류에 대한 불만과 운영 체제의 가상 메모리 고갈 대화 상자 등이 있으며, 작업 관리자 또는 시스템 내부의 프로세스 탐색기와 같은 도구를 사용하여 초과 메모리 할당을 확인할 수 있지만, 가상 메모리 페이징 및 파일 캐싱과 같은 복잡한 문제로 인해 통계를 해석하는 것이 항상 간단하지는 않습니다.
4.44. 포크() 실패는 어떻게 해결하나요?
안타깝게도 윈도우는 유닉스 계열 OS에서 볼 수 있는 프로세스 생성의 포크/실행 모델을 사용하지 않기 때문에 시그윈이 안정적이고 올바른 포크()를 구현하기 어렵고, 이로 인해 다음과 같은 오류 메시지가 발생할 수 있습니다:
부모와 같은 주소로 somedll을 다시 매핑할 수 없습니다.
힙을 할당할 수 없습니다.
dll 로딩을 기다리는 동안 죽었습니다.
자식 -1 - 초기화 전에 longjmp를 기다리는 동안 죽었습니다.
상태_액세스_위반
일시적으로 리소스를 사용할 수 없음
위의 오류에 대한 잠재적 해결 방법:
포크()를 사용하려는(그리고 실패한) 프로세스를 다시 시작합니다. 때때로 윈도우가 평소보다 fork()에 훨씬 더 적대적인 프로세스 환경을 설정하는 경우가 있습니다.
BLODA에 있는 모든 소프트웨어를 제거했는지(비활성화만 하지 않았는지) 확인하세요.
OS와 CPU가 이를 지원하는 경우 32비트 시그윈에서 64비트 시그윈으로 전환합니다. 주소 공간이 클수록 포크()가 실패할 가능성이 적습니다.
환경 변수 시그윈을 "detect_bloda"로 설정하면 추가 디버깅이 가능하므로 문제를 일으키는 다른 소프트웨어가 무엇인지 알 수 있습니다.
자세한 내용은 이 메일을 참조하세요.
전체 리베이스 강제 실행: 재베이스 트리거 풀리베이스를 실행하고 모든 시그윈 프로그램을 종료한 후 시그윈 설치 프로그램을 실행합니다.
기본적으로 시그윈 설치 프로그램은 새로 설치된 파일의 증분 리베이스를 자동으로 수행합니다. 전체 리베이스를 강제로 수행하면 리베이스 전에 리베이스 맵이 지워집니다.
자세한 내용은 /usr/share/doc/rebase/README 및 /usr/share/doc/시그윈/_autorebase.README를 참조하세요.
새 패키지를 설치하거나 기존 패키지를 업데이트하면 리베이스의 효과가 취소되고 종종 포크() 실패가 다시 나타납니다.
fork()가 안정적으로 작동하기 어려운 기술적 이유에 대해서는 사용자 가이드의 프로세스 생성 섹션을 참조하세요.
4.45. find_fast_cwd 경고를 어떻게 수정하나요?
이전 시그윈 릴리스에서는 사용자에게 다음과 같은 메시지와 함께 메일링 리스트에 문제를 보고하도록 요청했습니다:
FIND_FAST_CWD: 경고: FAST_CWD 포인터를 계산할 수 없습니다. 이 문제를
이 문제를 공개 메일링 리스트 시그윈@cygwin.com
최근 시그윈 릴리스에서는 이 메시지가 변경되었습니다:
이 문제는 일반적으로 최신 윈도우에서 이전 시그윈 버전을 사용하는 경우 발생합니다.
https://cygwin.com/ 에서 사용 가능한 최신 시그윈 버전으로 업데이트하세요.
문제가 지속되면 https://cygwin.com/problems.html 을 참조하세요.
이는 심각한 문제가 아니며, 시그윈이 윈도우 릴리스에서 유닉스 현재 디렉토리 처리의 모든 측면을 정확히 에뮬레이션하지 못할 수도 있다는 경고입니다.
안타깝게도 일부 프로젝트와 제품에서는 시그윈 프로젝트에서 최신 릴리스를 설치하는 대신 최신 윈도우 릴리스를 완전히 지원하지 않을 수 있는 이전 시그윈 릴리스를 여전히 배포하고 있습니다. 또한 애플리케이션에서 사용하는 Cygwin 패키지를 보안 문제 수정 및 업그레이드를 통해 최신 상태로 유지할 수 있는 확실한 방법을 제공하지 않을 수도 있습니다.
해결책은 시그윈 사용자 가이드의 '시그윈 설정하기'의 인터넷 설정 섹션에 있는 지침에 따라 Cygwin 설치 프로그램을 다운로드하여 실행하는 것입니다.
시그윈 설치 프로그램을 실행하기 전에 모든 응용 프로그램을 종료하십시오. 설치 프로그램을 실행할 때 표시되는 대부분의 값을 변경하지 말고 대부분의 경우 다음 버튼을 선택해야 합니다. 이미 시그윈 릴리스가 설치되어 있고 현재 설치만 업그레이드하려는 경우입니다. 시스템에 대한 인터넷 연결에 프록시가 필요한 경우 직접 선택해야 하며, 항상 최신 Cygwin 다운로드(미러) 사이트, 가급적 시스템에서 가장 가까운 사이트를 선택해야 더 빠른 다운로드가 가능합니다(자세한 내용은 미러 사이트 웹 페이지에서 확인할 수 있습니다).
시그윈 설치 프로그램은 시그윈 자체 및 설치된 애플리케이션에 필요한 모든 패키지를 다운로드하여 업그레이드를 적용합니다. 업데이트 적용 또는 업데이트 후 애플리케이션에 문제가 있는 경우 프로젝트 또는 제품 공급업체에 보고하여 해결 조치를 받아야 합니다.
시그윈은 자원 봉사 프로젝트이므로 프로젝트 또는 제품에서 설치한 이전 릴리스에 대한 지원을 제공할 수 없으므로, 설치한 프로젝트 또는 제품을 빠른 이메일을 통해 다른 사용자에게 알려주시면 도움이 될 것입니다.
|