Что означает фраза «Чувствительность к регистру — это функция файловой системы Linux, а не операционной системы Linux»?
На случай, если кому-то тоже понадобится что-то на Python. Укажите имя файла и волшебное слово для подсчета.
#!/usr/bin/python3
# magic_word_count.py
# Takes a filename and magic word and prints the number of times the word
# appears on each line of the file.
#
#./magic_word_count.py myfile.txt foo
#
import sys
filename = sys.argv[1]
magic_word = sys.argv[2]
with open(filename, 'r') as f:
for line in f.readlines():
words = line.strip().split(',')
print(len([word for word in words if word == magic_word]))
Использование:
$ cat myfile.txt
foo,bar,foo,foo
bar,foo,bar,bar
foo,foo,bar,bar
$./magic_word_count.py myfile.txt foo
3
1
2
Это потому, что 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
На самом деле это немного сложнее, чем это, и ваш lsтест не будет работать даже с FAT, потому что он на самом деле сохраняет регистр--он не позволит вам создавать Testи testкаталогов, но между этими двумя случаями (и между T*иt*)есть разница, поэтому ls t*для testи Tempне будет перечислять содержимое обоих.
Как объяснил Войтех , NTFS чувствительна к регистру. Попытка на файловой системе FAT будет работать, но только если вы используете case -сворачивающийся вариант, т.е.msdosв Linux (Я не знаю, есть ли эквивалент на WSL ). В этом варианте FAT все имена файлов пишутся в нижнем регистре -, поэтому Testотображается как test.
Существует ряд аспектов, которые следует учитывать в отношении чувствительности к регистру в файловых системах.:
- хранит ли сама файловая система информацию о прецедентах;
- учитывает ли ожидаемое использование файловой системы случай;
- отображает ли драйвер файловой системы или операционная система регистр, т.е. можно ли найти файл без учета регистра;
- как отображать регистр.
Историческая FAT, реализованная в msdos, находится где-то между первыми двумя :технически, FAT может хранить регистр, но на практике она не использовалась таким образом, а MS -DOS и ее клоны сворачивают регистр (, поэтому readme.txt, README.TXTи ReAdMe.TxTявляются допустимыми способами доступа кREADME.TXT). Windows сохраняет это поведение даже в случае -сохранения файловых систем (, включая VFAT и NTFS ). Драйвер файловой системы msdosсправляется с этим, отображая все имена файлов в нижний регистр, что не совсем правильно, но дает согласованные результаты и позволяет избежать проблем с инструментами в стиле Unix -и ожиданиями пользователей. Таким образом, в Linux монтирование файловой системы с помощью драйвера msdosозначает, что доступ к README.TXTвозможен только через readme.txt, а не через любой из вариантов, включая показанные выше.
Ваша цитата проистекает из того, что ядро Linux само по себе не особо заботится, по крайней мере, на первый взгляд :можно представить себе файловую систему, где open("README.TXT")и open("ReAdMe.TxT")будут открываться тот же файл.Действительно, XFS можно настроить таким образом, по крайней мере, для имен файлов ASCII (она сохраняет регистр, но обеспечивает нечувствительный к регистру -поиск ). Однако для сценариев общего -назначения все быстро усложняется, и за эти годы было много дискуссий; см., например, Файловые системы и нечувствительность к регистру , Case -нечувствительный поиск файловой системы и Case -нечувствительный ext4 на LWN.
Я подвергаю сомнению текст цитаты; Операционная система не зависит -от регистра --, она обычно не чувствительна к регистру и не чувствительна к нему. Вместо этого оболочки командной строки и/или драйверы файловой системы определяют регистр.
И даже тогда это не так просто. :Компьютеры — это числовые машины, а не текстовые. Все сигналы и данные имеют связанные числовые значения. Текст обычно использует 7 -битный код ASCII (в 8 -битовых группах, поэтому 8-й бит всегда равен 0 в ASCII. Unicode, ANSI и т. д. еще больше усложняют задачу. ), где коды верхнего и нижнего регистра различаются. Вот коды для «A» и «a» (в двоичном формате):
A 01000001
a 01100001
На различных уровнях (ядра, оболочки, файлов, системного драйвера, ЦП и др. )числовые значения не зависят от регистра, поскольку нет такого понятия, как верхний -/ нижний -регистр 1. и 0.
Также имейте в виду концепцию "подстановки". Подстановка — это идея использования '*' или '?' «сопоставлять» что угодно --даже ничего --в разных сценариях и правилах, в зависимости от того, какой символ глобуса использовался.
В типичной Unix-подобной -оболочке, такой как Bash, оболочка выполнит подстановку :в ls *, расширит ' *' списком совпадающих имен файлов,передзапуском команды lsи передать ей список совпавших имен, а не «*».
Типичная оболочка в стиле «msdos» этого не делает. В этой ситуации оболочка cmd.exeзапустит команду ls.exe(при условии, что она существует!)и передайте ему один «*».Затем команда ls.exeобрабатывает расширение «*» в соответствии со своими правилами.
Добавить в файловые системы... EXT (Файловые системы Unix )чувствительны к регистру. Файловые системы FAT нечувствительны к регистру (взгляните на старый образ дискеты FAT --имена файлов хранятся с использованием UPPERCASE ASCII ), что еще сложнее с FAT32 и LFN (поддержка длинных имен файлов ). И NTFS, которая пытается преодолеть разрыв, будучи и тем, и другим --NTFS обычно сохраняет регистр -, игнорируя регистр, когда пытается сопоставить имя файла (помните также, что имя файла хранится как последовательность числовых данных ).
В приведенном примере ls te*оболочка bash предоставляет вам дополнительные возможности. Например, попробуйте ls [Tt]e*, и он будет соответствовать как «Test», так и «temp», но не «TECH».
Как видите, ситуация очень сложная. И точный вопрос, заданный по данному утверждению, также представляет собой сложную ситуацию, еще более осложненную тем, что утверждение сомнительно без дополнительных оговорок и контекста.
Я думаю, что цитата не только, как этот ответ правильно указывает, двусмысленная и -контекстно-зависимая, но и в целом вводит в заблуждение из-за использования слов «чувствительный» и «функция». На самом деле, и ядро Linux, и операционные системы Linux, или GNU/Linux, или Unixoid, а также собственные файловые системы Linux "чувствительны к регистру -" именно , потому что они не имеют абсолютно понятия "дело" . Для Linux разница между aи Aточно такая же, как между aиb:двумя разными кодовыми точками, одним (или более )битами, переключаемыми (и ни одним из десятичных разрядов. 32 и не выше десятичного числа 127, если оставить в стороне особые случаи ). Любая идея о каком-то особом отношении между строчной -и прописной буквой «А», которая является чем-то иным, чем отношение между двумя кодовыми точками, либо навязывается другими контекстами (, такими как код C ), либо чистой конвенцией (приверженности к чего все же можно ожидать от инструментов! ).
Путаница неизбежна, потому что отсутствие понятия чего-либо полностью противоречит нашему понятию чувствительности к тому же самому предмету. Если средство проверки орфографии утверждает, что оно -чувствительно к грамматике, мы ожидаем, что оно распознает правила, выходящие за рамки чисто орфографических правил, или, чтобы быть менее метафоричным, его программисты реализовали функции, которые так или иначе имеют дело с концепцией грамматики.. И хотя программисты Linux (в любом из упомянутых выше значений ), безусловно, все имеют концепцию регистра символов, они просто не реализовали ничего из этого в системе.
Кроме того, отсутствие понятия о чем-либо обычно не считается функцией.Однако отображение aв A, что либо не позволяет test.txtкроме TEST.TXT, либо, что еще хуже, делает два неразличимыми, является функцией, которая должна быть явно реализована в ОС или файловая система или любой другой уровень, о котором мы говорим в конкретном контексте. И эта функция маскируется под отсутствие функции, называя ее «случай-в чувствительности». Он предоставляет интерфейс, который позволяет пользователю быть нечувствительным к удерживанию или не удерживанию клавиши Shift при вводе имени файла. (И единственным возможным объяснением того, почему кто-то когда-то считал это выгодным, является распространенное заблуждение, что менее выразительные пользовательские интерфейсы легче понять -, но это выходит за рамки вопроса.)