방금 다음 문장을 읽었습니다.
대소문자 구분은 Linux 운영 체제가 아닌 Linux 파일 시스템의 기능입니다.
이 문장을 통해 Linux 컴퓨터를 사용하지만 Windows 파일 시스템으로 포맷된 장치를 사용하는 경우 대소문자 구분은 문제가 되지 않는다는 것을 추론합니다.
이를 확인하기 위해 다음을 시도했습니다.
$ ~/Documents: mkdir Test temp
$ ~/Documents: touch Test/a.txt temp/b.txt
$ ~/Documents: ls te*
b.txt
tempLinux 파일 시스템을 사용하고 있기 때문에 예상되는 디렉토리의 파일만 나열합니다 .
Windows 파일 시스템(참고: WSL2를 사용 중임)으로 이동하면 여전히 동일한 결과가 나오지만 대소문자 구분을 무시하고 두 디렉터리 모두에 파일이 나열될 것으로 예상됩니다.
$ /mnt/d: mkdir Test temp
$ /mnt/d: touch Test/a.txt temp/b.txt
$ /mnt/d: ls te*
b.txt
나는 bash와 zsh를 모두 사용해 보았습니다.
어떤 면에서는 bash(또는 zsh)와 관련이 있는 것 같습니다. 왜냐하면 bash는 대소문자를 구분하지 않는 파일 시스템을 사용할 때에도 대소문자 구분을 적용한다는 내용도 읽었기 때문입니다.
테스트는 Powershell용이므로 파일 시스템이 실제로 대소문자를 구분하지 않음을 의미합니다.
답변1
여기에서 실행 중입니다:
ls te*
기능 중 하나를 사용하세요껍데기라고와일드카드또는파일 이름 생성(POSIX의 경로 이름 확장자)은 Linux 시스템이나 Linux에서 사용되는 파일 시스템에 대한 경로 이름이 아닙니다.
te*연장되다쉘을 통해이 패턴과 일치하는 파일 목록으로 이동합니다.
이를 위해 쉘은 시스템의 현재 디렉토리에 있는 항목 목록을 요청한 다음(일반적으로 readdir()시스템별 시스템 호출(Linux의 경우)을 사용하여 아래에 설명된 C 라이브러리의 함수를 사용 getdents()) 각 이름을 비교합니다. 패턴으로.
대소문자를 구분하지 않고 일치하도록 쉘을 구성하거나( . 처음에 보고된 대로)확장 glob 연산자에서nocaseglobzsh 또는 bash의 옵션 참조) glob 연산자를 사용하여 대소문자 구분을 전환하지 않는 한( 경로 이름 확인은 시스템 또는 기본 파일 시스템은 대소문자를 구분하지 않거나 NTFS와 유사하게 설정될 수 있습니다.(#i)zshte*readdir()te
답변2
~처럼보이테크(Vojtech) 설명, NTFS는 대소문자를 구분합니다. FAT 파일 시스템에서 시도하면 작동하지만 케이스 접기 변형을 사용하는 경우에만즉 msdosLinux에서(WSL에 이에 상응하는 것이 있는지는 모르겠습니다). 이 FAT 변형의 경우 파일 이름은 모두 소문자 Test이므로 test.
파일 시스템의 대소문자 구분과 관련하여 고려해야 할 몇 가지 측면이 있습니다.
- 파일 시스템 자체가 케이스 정보를 저장하는지 여부
- 파일 시스템의 의도된 사용이 대소문자를 고려하는지 여부
- 파일 시스템 드라이버이든 운영 체제 매핑의 경우이든,즉대소문자를 무시한 파일을 찾을 수 있습니까?
- 어떻게사건을 매핑합니다.
에서 구현된 역사적 FAT는 msdos처음 두 가지 사이 어딘가에 있습니다. 기술적으로 FAT는 대소문자를 저장할 수 있지만 실제로는 그런 방식으로 사용되지 않으며 MS-DOS와 해당 복제본은 대소문자를 축소합니다(따라서 readme.txt및 은 모두 유효한 액세스 방법 README.TXT입니다 ). Windows는 VFAT 및 NTFS를 포함한 대소문자 보존 파일 시스템에서도 이 동작을 유지합니다. 파일 시스템 드라이버는 모든 파일 이름을 소문자로 매핑하여 이 문제를 처리합니다. 이는 덜 정확하지만 일관된 결과를 생성하고 Unix 스타일 도구 및 사용자 기대와 관련된 문제를 방지합니다. 따라서 Linux에서 드라이버를 사용하여 파일 시스템을 마운트한다는 것은 위에 표시된 변형을 포함한 변형이 아닌 를 통해서만 액세스할 수 있음 을 의미합니다 .ReAdMe.TxTREADME.TXTmsdosmsdosREADME.TXTreadme.txt
귀하의 인용문은 Linux가핵심적어도 표면적으로는 그 자체로는 특별히 걱정하지 않습니다. 동일한 파일을 여는 파일 시스템을 상상할 수 open("README.TXT")있습니다 open("ReAdMe.TxT"). 실제로 XFS는 최소한 ASCII 파일 이름에 대해 이런 방식으로 구성할 수 있습니다(대소문자는 유지하지만 대소문자를 구분하지 않는 조회를 제공합니다). 그러나 일반적인 시나리오의 경우 상황이 빠르게 더 복잡해지며 수년에 걸쳐 많은 논의가 있었습니다.파일 시스템 및 대소문자를 구분하지 않음,대소문자를 구분하지 않는 파일 시스템 조회, 그리고대소문자를 구분하지 않는 ext4LWN에서.
답변3
그 이유는NTFS는 대소문자도 구분합니다., Windows에서는 사용자에게 이를 숨깁니다. FAT는 대소문자를 구분하지 않습니다. 동일한 디렉터리에 디렉터리를 생성해 보면 test이를 확인할 수 있습니다.Test
$ ls
test
$ mkdir Test
mkdir: cannot create directory ‘Test’: File exists
$ mkdir TEST
mkdir: cannot create directory ‘TEST’: File exists
실제로는 이보다 조금 더 복잡하며 lsFAT를 사용하는 경우 테스트도 작동하지 않습니다.케이스 예약됨-- 및 디렉토리를 생성할 수는 없지만 여전히 Test두 가지 경우(및 사이) test를 구별하므로 for 및에는 두 가지 내용이 모두 나열되지 않습니다.T*t*ls t*testTemp
답변4
한 가지 점을 지적할 가치가 있는데, 이는 이러한 답변 중 일부를 맥락에 맞출 수 있습니다.
Linux에서 파일 이름을 처리하는 모든 시스템 호출은 바이트 문자열을 처리합니다. 즉, 프로그램이 파일 시스템에서 어떤 작업을 수행하도록 요청할 때마다 사용 중인 모든 파일 이름을 바이트 문자열로 지정하고 반환되는 모든 파일 이름은 바이트 문자열이 됩니다. 일반적으로(필수는 아니지만) 이러한 문자열에는 ASCII 또는 UTF-8로 인코딩된 텍스트가 포함되며 대문자와 소문자의 이진 표현은 이러한 인코딩에서 다릅니다. 따라서 파일 이름을 "단지 바이너리 데이터"로 취급하는 모든 항목은 대소문자를 구분합니다.
이러한 요청이 파일 시스템 드라이버에 도달하면 일부 파일 시스템은 파일 이름을 대소문자를 구분하여 해석하고(일반적으로 Linux 또는 기타 Unix 운영 체제의 경우) 일부 파일 시스템은 파일 이름을 대소문자를 구분하지 않고 해석합니다(일반적으로 다른 작업의 경우). , Windows와 같은). 그러나 이는 프로그램이 볼 수 없는 내부 구현 세부 사항입니다. 프로그램이 볼 수 있는 것은 바이트 문자열뿐입니다.
일반적으로 프로그램은 실행 중인 파일 시스템이 대소문자를 구분하는지 여부를 확인하려고 시도하지 않으며 많은 프로그램은 파일 시스템이 대소문자를 구분한다고 암시적으로 가정합니다(이것이 구현하기 가장 쉽기 때문입니다). 일부에는 대소문자를 처리할 수 있는 구성 옵션이 있을 수 있지만 모든 파일 시스템이 바이트 문자열이므로 프로그램이 보는 파일 이름에서 이를 알아낼 수 없다는 점을 명심하십시오.