Почему терминал чувствителен к регистру?

Производительность

Я записал маленький Сравнительный тест (источник), для обнаружения, что файловая система выполняет лучше всего с сотней тысячами маленьких файлов:

  • создайте 300 000 файлов (512B к 1536B) с данными из/dev/urandom
  • перепишите 30 000 случайных файлов и измените размер
  • считайте 30 000 последовательных файлов
  • считайте 30 000 случайных файлов
  • удалите все файлы

  • синхронизация и кэш отбрасывания после каждого шага

Результаты (среднее время в секундах, понизьтесь = лучше):

Using Linux Kernel version 3.1.7
Btrfs:
    create:    53 s
    rewrite:    6 s
    read sq:    4 s
    read rn:  312 s
    delete:   373 s

ext4:
    create:    46 s
    rewrite:   18 s
    read sq:   29 s
    read rn:  272 s
    delete:    12 s

ReiserFS:
    create:    62 s
    rewrite:  321 s
    read sq:    6 s
    read rn:  246 s
    delete:    41 s

XFS:
    create:    68 s
    rewrite:  430 s
    read sq:   37 s
    read rn:  367 s
    delete:    36 s

Результат:
В то время как Ext4 имел хорошую общую производительность, ReiserFS был экстремальным значением быстро при чтении последовательных файлов. Оказалось, что XFS является медленным со многими маленькими файлами - Вы не должны использовать его для этого варианта использования.

Проблема фрагментации

Единственный способ препятствовать тому, чтобы файловые системы распределили файлы по диску, должен сохранить раздел только столь большим, как Вы действительно нуждаетесь в нем, но обращаете внимание, чтобы не сделать раздел слишком небольшим, предотвратить фрагментацию внутрифайла. Используя LVM может быть очень полезным.

Дальнейшее чтение

Дуга Wiki имеет некоторые большие статьи, имеющие дело с производительностью файловой системы:

https://wiki.archlinux.org/index.php/Beginner%27s_Guide#Filesystem_types

https://wiki.archlinux.org/index.php/Maximizing_Performance#Storage_devices

12
04.01.2013, 23:59
8 ответов

В конечном счете это был произвольный выбор, сделанный создателями Unix более чем четыре десятилетия назад теперь. Они, возможно, приняли решение сделать вещи нечувствительными к регистру как создатели MS-DOS, сделал десятилетие спустя, но это имеет его недостатки, также.

Это слишком глубоко встраивается в *ix культура для изменения теперь. Чувствительной к регистру проблемой файловой системы, поднятой eppesuig, является только часть его. системы macOS — которые Основаны на Unix — обычно, имеют нечувствительный к регистру (но сохранение случая) файловые системы, таким образом, на таких системных командах, внешних к оболочке, на самом деле рассматриваются нечувствительно к регистру. Но, builtins как cd останьтесь чувствительными к регистру.

Даже с нечувствительной к регистру файловой системой, история вещей сговаривается против Ваших пожеланий, Hussain. Если я ввожу ls на моем Mac я получаю цветной список каталогов. Если я ввожу LS вместо этого, /bin/ls все еще выполнения, но список не является цветным, потому что псевдоним, который добавляет -C флаг чувствителен к регистру.

Лучше всего просто привыкните к нему. Если Вы можете, учиться любить его.

43
27.01.2020, 19:54
  • 1
    Имена файлов На самом деле Windows могут быть чувствительными к регистру. Они находятся в подсистеме POSIX, например, и видят msdn.microsoft.com/en-us/library/ee681827%28v=vs.85%29.aspx –  fpmurphy 04.01.2013, 15:45
  • 2
    Это на самом деле удивительно, так как некоторые общие терминалы, доступные в то время, были в верхнем регистре только, и они должны были реализовать обходное решение (поместите обратную косую черту перед буквой, если Вы хотите, чтобы это было действительно прописным - включил, если Вы ввели свое имя пользователя во всем верхнем регистре, когда Вы вошли в систему) в драйвере протокола работы линии. –  Random832 04.01.2013, 16:06

Технические системы, которые я использую и уважение, почти исключительно чувствительны к регистру: будьте этим ОС или язык программирования или что-либо еще.

Исключениями, о которых я мог думать прямо сейчас, являются HTML-тэги и некоторые реализации SQL и язык программирования Ada.

Даже в тех случаях, я думаю, что существуют сильные тенденции на самом деле записать HTML-тэги в нижнем регистре и семантику SQL-запроса в верхнем регистре (и использованные для своей выгоды параметры). (Исправьте меня, если я неправ.) Что касается Ada, режим Emacs исправит Вас, если Вы, например, введете строчное имя процедуры, хотя это не будет иметь значения при компиляции. Так, даже когда там нечувствительно к регистру, кажется, что люди соглашаются, что это - плохая идея.

Причина состоит в том, что Вы получаете намного более выразительное питание с чувствительным к регистру. Не только количественно - CD один, но CD, Cd, cD, и cd четыре - но что еще более важно, можно выразить цель, акцент, и т.д. с помощью верхнего - и нижний регистр разумно; также, при программировании, Вы улучшите удобочитаемость.

Интуитивно, ясно, что Вы не читаете hi и HI тот же путь!

Но, чтобы дать Вам компьютерный пример мира, на языке программирования Ada (с 1980-х), первая строка блока кода процедуры могла быть похожей на это:

procedure body P(SCB : in out Semaphore_Control_Block) is

как Вы видите, имена процедур и названия параметра использованы для своей выгоды, как типы данных, все остальное - нижний регистр. Также обратите внимание, что "все прописное" название параметра говорит нам, что это - акроним. Теперь, сравните это с

procedure body p(scb : in out semaphore_control_block) is

Это возможно, поскольку Ada нечувствительна к регистру (или, чтобы быть точным, компилятор изменит его на путь в моем первом примере, но конечно не изменит Ваш код). Или, как насчет:

PROCedure body P(Scb : IN Out semaphore_CONTROL_BLOCK) iS

Тот немного смешон, я знаю; но кто-то был бы достаточно глуп записать этому тот путь (хорошо, возможно, не). Точка, чувствительная к регистру система не только вынудит людей быть последовательными, им будет также помогать она (удобочитаемость) и использовать ее для их преимущества (пример акронима выше).

6
27.01.2020, 19:54
  • 1
    и Delphi также нечувствительны к регистру. Кроме того, имея, например, две переменные length и Length обычно плохая идея:) –  Ajasja 04.01.2013, 18:27
  • 2
    @Ajasja: это интересно, потому что Ada много похожа на Паскаля. Ну, я предполагаю, считали ли Вы их всех, были бы тонны таких языков, потому что существует столько языков программирования. Что касается длины, конечно - но Вы могли возможно думать о некотором таком случае: что относительно Max (человек), и макс. (функция, которая берет список реалов и возвращает самое большое)? –  Emanuel Berg 04.01.2013, 19:16
  • 3
    Относительно Вашего последнего примера Вам могло бы быть интересно знать, что интерпретатор SuperBasic QL использовал для своей выгоды ключевые слова точно тем способом: DEFine PROCedure Hello, например. Только необходимо было ввести капитализированные биты, но полное слово появилось в распечатках программ. Это относилось REMarkТакже и не было настолько раздражающим... –  David Given 26.04.2014, 23:34

Это не "терминальная" проблема, это - функция файловой системы. Как оболочка должна искать Ваши команды на (всегда чувствительный к регистру) файловая система?

8
27.01.2020, 19:54
  • 1
    И что, если две или больше команды соответствуют? –  scai 04.01.2013, 13:35
  • 2
    Единственная опция, которая может помочь Вам немного, является a bash опцию называют cdspell: это пытается найти корректное имя файла, даже если Вы снабдили подсказкой его неправильно, но это только работает на аргументы команды. удивительно рабочий –  eppesuig 04.01.2013, 13:44
  • 3
    @HussainTamboli Там мог бы быть названными командами cd, CD, cD и Cd каждый с уникальным поведением. –  scai 04.01.2013, 14:04
  • 4
    Это не действительно функция файловой системы или терминальная функция – это - функция оболочки. Shell builtins будет чувствителен к регистру в нечувствительной к регистру файловой системе. Кроме того, большинство команд хеша оболочек, таким образом, команды никогда не являются действительно файлами, они на самом деле привлечены из хеша. Попробовать hash -p /bin/hostname HOSTNAME и теперь HOSTNAME команда для /bin/hostname. –  kojiro 04.01.2013, 18:57
  • 5
    О, я должен также упомянуть, что можно сказать большинству оболочек быть менее чувствительным к регистру. Для удара можно связать set completion-ignore-case on. –  kojiro 04.01.2013, 19:06

Понятие "верхнего/ниже" случая может быть (и действительно), локаль определенная вещь, который, поскольку любая другая сложность дизайна должна быть продвинута максимально близко к точке использования в стеке приложений, не быть частью ядра.

Наличие чувствительной к регистру среды позволяет переносить его в нечувствительную к регистру среду, но не наоборот.

2
27.01.2020, 19:54

Это не более или менее странно, чем то, что у нас есть алфавит верхнего регистра и алфавит нижнего регистра для запуска с. Если Вы заглядываете /usr/bin, Вы будете уведомление a (очень), немного исполняемых файлов используют капитализацию.

Чувствительное к регистру пространство имен не является всего вдвое более большим, чем нечувствительное - различие растет экспоненциально с длиной слова. Например, с помощью 26 символов существует 26^3 (17576) различные возможности в трех буквах; с помощью 52 (2 * 26) символы там 52^3=140608. Открытое пространство имен является хорошей вещью ;)

4
27.01.2020, 19:54
  • 1
    Где Вы получали 3 от? –  ctrl-alt-delor 18.04.2018, 12:47
  • 2
    @ctrl-alt-delor Это - просто пример: "существуют 26^3 (17576) различные возможности в трех буквах". номер –  goldilocks 18.04.2018, 16:39

В качестве отправной точки причина, по которой этот вопрос был задан, и причина, по которой вы найдете много дискуссий по нему, если вы погуглите эту тему, заключается в том, что чувствительность к регистру затрудняет "нормальным" людям изучение и использование языка программирования. или интерфейс командной строки.

Чувствительность к регистру возникла из-за низкой мощности компьютеров в прошлом. Чтобы сделать вещи нечувствительными к регистру, потребовалась одна дополнительная операция синтаксического анализа перед тем, как команда была передана интерпретатору или компилятору перед ее выполнением, и первые разработчики не были готовы тратить энергию компьютера на удобство учета регистра.

Я считаю, что в приведенных выше комментариях содержится ряд неверных утверждений. Во-первых, психологи скажут вам, что люди автоматически не различают слова, написанные заглавными или строчными буквами, или даже их комбинацию с точки зрения значения слова. В обычных выразительных языках регистр используется для передачи дополнительного значения. Например, использование заглавной буквы в начале слова в предложении указывает на то, что это, скорее всего, имя собственное. Заглавные буквы также используются для придания прозе структуры. Например, заглавная буква используется для обозначения начала предложения. Но «Слово» и «слово» рассматриваются человеческим разумом как означающие одно и то же.

Создатели DOS, ADA и Pascal, и это лишь некоторые из них, понимали, что чувствительность к регистру была дополнительным бременем для новичков.Позже текстовые редакторы в «Интегрированных средах разработки» (IDE), распознав зарезервированное слово, могли изменить это слово так, чтобы оно в любом случае соответствовало стилю; плюс отображать его другим цветом, чтобы слово выделялось. Таким образом, аргумент о том, что чувствительность к регистру делает код более читаемым, ошибочен. Не для «нормальных» людей. Он просто добавляет ненужный и иногда сбивающий с толку слой к и без того сложной задаче.

Java - крайний пример очень плохого языка с точки зрения простоты использования новичком. Он обеспечивает строгую чувствительность к регистру, но по глупости позволяет программисту иметь две функции, обе с одним и тем же именем, но которые на самом деле являются разными функциями в силу того факта, что одна имеет другой набор аргументов. Действительно, Java - это такой аборт языка, что, когда университеты перешли от преподавания синтаксиса Паскаля студентам, проходящим курсы, не связанные с информатикой, процент успешных участников упал с 70% до 40%.

Таким образом, чувствительность к регистру возникла по двум причинам. Во-первых, не хватало мощности компьютера. Во-вторых, люди, которые попадают в информатику, часто находятся в аутическом спектре и плохо относятся к потребностям «нормальных» людей. Как следствие, эти люди не могут понять, что чувствительность к регистру не нужна и является препятствием для изучения и использования языка программирования.

-2
27.01.2020, 19:54

La distinción entre mayúsculas y minúsculas es una idea tonta que surgió porque los escritores de Unix no entendieron que ASCII está diseñado para ser fácilmente insensible a mayúsculas y minúsculas. Uno simplemente ignora los bits iniciales. Ascii es una codificación de 7 bits con A mayúscula en el valor de bit decimal 65 1000001 y en el bit decimal 97 1100001. Con las letras siguientes en orden alfabético. Esto generó todo tipo de ideas, como que todas las claves en los pares de valores clave deberían ser numéricas para evitar que las zapatillas sean diferentes de las zapatillas. La base de datos Pick Multi -Value se dio cuenta de esto desde el principio y no distingue entre mayúsculas y minúsculas.

-3
27.01.2020, 19:54

Это не терминал, это файловая -система. Или в случаеcd(cd — это оболочка, встроенная в )оболочку, то есть чувствительная к регистру.

Было бы возможно (по крайней мере с ASCII ), сделать его нечувствительным к регистру. Это сложнее с ныне используемым юникодом (, совпадают ли два символа, может зависеть от локального ).

Что с этим делать

  • Живите с этим.
  • Попробуйте эти варианты оболочки. Они предлагают компромисс и упрощают работу, не создавая всех проблем нечувствительности к регистру.
    • shopt -s nocaseglob#это у меня~/.bashrc
    • shopt -s nocasematch#это также было бы в~/.bashrc
    • set completion-ignore-case on#это у меня~/.inputrc
1
27.01.2020, 19:54

Теги

Похожие вопросы