Вы не поняли. В данном примере вы не «нарываетесь» на пробел. Вы намеренно ставите его там, чтобы строка после пробела не сохранилась в истории. Bash здесь реализует логичное, но неудобное поведение — такую строку переиспользовать средствами bash нельзя никак.
Но, с другой стороны, если это не внешний репозиторий, а просто локальный файл. Что плохого, если система позволяет запустить «mplayer „фильм1.скачано отсюда.divx“» вместо «MPlayer „Фильм1.Скачано Отсюда.DivX“» с учетом текущей локали?
Давайте вы расскажете, как вы видите практическое воплощение вашего запроса, а я скажу, почему так делать не надо. Автодополнение можно, нужно и уже научили игнорировать регистр, если пользователь не против. Можно сделать такое же автодополнение в диалоге открытия файлов. Но попытка сделать что‐то подобное в системной функции открытия файла обязательно приведёт как минимум к коллизиям имён: у нас есть два файла input.tXt и input.TxT. Какой надо открыть, если у нас спросили input.txt (почему ФС не должна быть регистронезависимой уже обсудили, поэтому считаем, что она регистрозависимая и существование таких файлов возможно)? Можно нагородить кучу условий для обхода таких ловушек в такой функции, но из‐за их существования с регистрозависимой ФС регистронезависимая функция открытия файлов непременно будет тормозить.
При вводе кода автодополнение обычно регистронезависимое даже в регистрозависимых языках. Удобно же.
Часто можно настроить, если всё же не удобно.
В zsh автодополнение имён файлов тоже может быть регистронезависимым. Реализация регистронезависимости на этом уровне куда как проще и однозначнее регистронезависимости на уровне ФС: здесь вы можете просто взять текущую локаль и никто вас не осудит. Можете взять ту самую гиганскую ICU. В ФС текущую локаль взять нельзя, т.к. она должна быть переносимой между системами. $upcase будет некорректен на машине с произвольной локалью, что бы в этой таблице не содержалось. А запихивание ICU в ядро и применение соответствующих алгоритмов при каждой попытке открыть файл… Есть и более простые способы превратить систему в тормозящее г…но. ICU хороша, но там где она есть и применяемая к чему надо, а не в ядре и применяемая ко всему подряд.
Т.е. разные языки используют разные uppercase'ы для «тех же» символов. И? Как это влияет на сравнение двух строк с учетом codepage'а?
У вас в каталоге затесались .git и .gİt. Вторая использует ту самую U+0130. Что будете делать? Учтите, что турецкий пользователь должен ожидать, что это одинаковые имена, а все остальные — что разные. В зависимости от того, что система записала в файл $upcase либо те, либо другие останутся с обманутыми ожиданиями. Более того, если кто‐то догадался записать, что toupper('i') == 'İ' (и так же для всех остальных латинских букв, имеющих свой верхний регистр в турецком языке) в $upcase, то регистронезависимое сравнение имён файлов, написанных на английском, сломается. А если нет, то сломается сравнение на турецком в данной ФС. Или вы ожидаете, что у пользователя из Турции нет ни одного файла с именем на английском языке? Можно нагородить костылей вроде toupper('İ') == 'I' && toupper('i') == 'I', но я абсолютно уверен что более опытные товарищи смогут найти пример, который не решается с помощью таких костылей в принципе.
Вы можете сделать корректное с точки зрения компьютера регистронезависимое сравнение. Можете даже сделать его переносимым между системами. Но корректное с точки зрения пользователя сравнение невозможно в принципе, потому что имена файлов не имеют свойства «язык», введение с ручным контролем пользователя этого пользователя отвратит, автоматическое проставление языка не всегда корректно и весьма ресурсозатратно, и в любом случае вместо одной кодовой страницы вы получите целую тучу, к тому же станет совершенно не понятно, как нормализовывать имя файла, если в каталоге есть файлы с разной кодовой таблицей.
Оно работает. Просто есть три места для сохранения: файл, структура в памяти и специальное место, где сохраняется предыдущая строка. В зависимости от настроек вы можете не сохранить строку в памяти и файле либо не сохранить в файле. Но вы не можете не сохранить (точнее можете, но с использованием ряда хаков) предыдущую команду в этом специальном месте. Очень удобно и совершенно правильно: или вам нравится перепечатывать «несохраняемую» строку на каждой ошибке (копирование — вставка не всегда вариант и всегда медленнее стрелочки вверх или эквивалента)?
Команда станет недоступна из истории, как только вы введёте следующую. С моими функциями zshaddhistory и собственным widget'om accept-line (отвечает за исполнение введённой строки, у меня на нём лежит исполнение команд с нестандартным синтаксисом) команда исчезает даже если просто «отправить на исполнение» пустую строку, но вообще-то вам нужно ввести что-то непустое.
В zsh есть множество вариантов удаления истории. Но вы всегда можете один раз воспользоваться предыдущей введённой строкой, даже если она и не сохранится потом в истории. В том числе это работает и с !!.
Это настройка HIST_VERIFY (кстати, оказывается в bash она тоже есть: habrahabr.ru/post/246375/#comment_8188087) и судя по man zshoptions по‐умолчанию она не включена (как и в bash, кстати). Только zsh всегда даёт вам редактировать ранее введённую команду, а bash — нет.
То есть, приведение к верхнему регистру работает в общем случае некорректно, сравнение некорректно в принципе (две разных строки вполне могут приводиться к одинаковой строке в верхнем регистре), поддержка новых языков в принципе невозможна (иначе вместо «инвариантной» локали образуется целый набор локалей, зависящий от версии ОС), от гиганских таблиц (представляющих собой локаль) так и не избавились и реализация работает медленнее регистрозависимой.
Ну и оказывается, что вместо инвариантной локали всё-таки используется локаль, встроенная в файловую систему. Просто блеск! Теперь количество гиганских таблиц равно количеству файловых систем.
Как всегда, zsh можно настроить и так, и так. Кстати, у меня команда, начинающаяся с пробела, удаляется из истории с помощью функции zshaddhistory (не помню, чем меня не устроила настройка HIST_IGNORE_SPACE). А вообще zsh имеет кучу способов удаления из истории:
$HISTORY_IGNORE: переменная, содержащая шаблон, под который должна подпадать игнорируемая команда
setopt HIST_IGNORE_SPACE: настройка, заставляющая игнорировать командную строку, начинающуюся с пробела или использующую обычный (есть ещё suffix и глобальные) alias, начинающийся с пробела
setopt HIST_NO_FUNCTIONS и setopt HIST_NO_STORE — игнорируют командную строку, в которой есть определение функции или вызов fc
zshaddhistory: если данная функция завершится с кодом 1, то строка не будет сохранена, а если 2, то она не будет сохранена в файле, но будет в памяти.
Во всех случаях вы можете один раз получить команду повторно, независимо от того, была ли она сохранена в файле или в памяти или не была сохранена ни там, ни там.
Первый — это из Supplemental Private Use Area-B. Бесполезен без своих шрифтов: будете видеть то, что вы сейчас видите. Чем их при этом не устроила просто Private Use Area непонятно.
Вообще‐то оба варианта похожи на U+FFFD REPLACEMENT CHARACTER, просто из разных шрифтов. GTK‐шные программы часто вместо REPLACEMENT CHARACTER показывают вот такие вот символы (внимание: в шрифте может быть и обычно есть¹ U+FFFD, но GTK вставляет туда свой символ), раньше чаще можно было увидеть прямоугольник. Есть ещё вариант с вопросительным знаком в ромбе (ромб залитый, вопрос цвета фона) — самый популярный¹ в шрифтах. Видел в Luxi Mono обрезанный ромб (шестиугольник) с тем же вопросительным знаком.
¹ Впрочем, возможно, что kcharselect просто отображает этот ромб из другого шрифта, потому он и есть самый популярный у меня. Проверять с помощью fontforge неохота.
Я понял. Просто здесь проводится аналогия между MAC’ом и автомобильном номером, и их оба не скрывают и не будут скрывать, на что есть причины. Вы сказали причину для автомобильного номера, я дополнил причиной для MAC’а.
Так это хорошо. Есть страничка github.com/aserebryakov/filestyle/releases, на которой сейчас много копий README. А в предложенном варианте там будет нормальный, полный CHANGELOG.
Собственно поэтому в powerline я changelog не веду — достаточно того, что список изменений есть на Github и есть полностью его копия в описании изменений в master ветке.
А зачем в github releases помещать README? Обычно туда помещают часть CHANGELOG (что изменилось по сравнению с предыдущим выпуском) и/или какую‐нибудь производную от него (к примеру, где сломана совместимость и как это исправить).
MAC’и, конечно, не «нельзя скрывать». Их просто «нельзя скрыть» — не раскрыв MAC’а вы никуда не подключитесь. Разве что их рандомизация не запрещена законодательством, в отличие от рандомизации номера автомобиля.
Да, если считать по количеству клавиш на удаление, то почти одинаково. Количество клавиш на ввод так совсем одинаково. alias -g всё же имеет преимущество, т.к. все удобные <C-…> у меня уже заняты, да и результат выглядит компактнее. Недостаток — может испортить скрипты, загруженные после создания alias’а.
Кстати, zsh при использовании emacs варианта раскладки использует widget для <C-w>, который считает, что | следует непременно удалять вместе с предшествовавшим словом (даже если оное отделено пробелом).
Нет. Вы можете переопределить __eq__ любым угодным вам способом. Другой вопрос, что в ряде мест (к примеру, при сравнении списков) применяется сравнение id() перед сравнением объектов: есть известный пример с NaN, или вот ещё:
Python 2.7.8 (a980ebb26592ed26706cd33a4e05eb45b5d3ea09, Nov 28 2014, 06:20:07)
[PyPy 2.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> class NE(object):
.... def __eq__(self, other):
.... return False
....
>>>> n = NE()
>>>> [1, 2, n] == [1, 2, n]
True
>>>> n == n
False
. В CPython и jython картина точно такая же. IronPython покажет два False, но у него всегда были проблемы с совместимостью.
Подсветка — нет, скорее всего пользователь не поймёт, что подсвечивается и почему (если только это не смешанный CRNL/NL файл). Вот сообщение о том, что &l:fileformat is# 'dos' при открытии сделать можно, вместе с описанием «а что это такое» и «как исправить» (и «как отключить предупреждение»).
Подсвечивать ^M в тексте всё же можно — «замечаемость» его сильно зависит от используемой цветовой схемы. С моим wombat256mod это особых проблем не доставляло, хотя там и нет кричащего фона. В стандартной схеме ^M похож на комментарий, что ещё заметнее. Проблем нету в основном потому, что ^M либо нет вообще, либо он есть везде (при вставке из старой Opera, к примеру). Так что мой комментарий всё же относится к моему опыту.
Я бы рекомендовал подсвечивать все управляющие символы, а не \r. Во всех известных мне языках программирования их можно заменить на что‐то из печатных символов, а проблем при использовании VCS или cat они доставить могут (VCS может счесть, что файл является бинарным, а в терминале они не зря называются управляющими).
bashнельзя никак.input.tXtиinput.TxT. Какой надо открыть, если у нас спросилиinput.txt(почему ФС не должна быть регистронезависимой уже обсудили, поэтому считаем, что она регистрозависимая и существование таких файлов возможно)? Можно нагородить кучу условий для обхода таких ловушек в такой функции, но из‐за их существования с регистрозависимой ФС регистронезависимая функция открытия файлов непременно будет тормозить.В zsh автодополнение имён файлов тоже может быть регистронезависимым. Реализация регистронезависимости на этом уровне куда как проще и однозначнее регистронезависимости на уровне ФС: здесь вы можете просто взять текущую локаль и никто вас не осудит. Можете взять ту самую гиганскую ICU. В ФС текущую локаль взять нельзя, т.к. она должна быть переносимой между системами. $upcase будет некорректен на машине с произвольной локалью, что бы в этой таблице не содержалось. А запихивание ICU в ядро и применение соответствующих алгоритмов при каждой попытке открыть файл… Есть и более простые способы превратить систему в тормозящее г…но. ICU хороша, но там где она есть и применяемая к чему надо, а не в ядре и применяемая ко всему подряд.
.gitи.gİt. Вторая использует ту самую U+0130. Что будете делать? Учтите, что турецкий пользователь должен ожидать, что это одинаковые имена, а все остальные — что разные. В зависимости от того, что система записала в файл $upcase либо те, либо другие останутся с обманутыми ожиданиями. Более того, если кто‐то догадался записать, чтоtoupper('i') == 'İ'(и так же для всех остальных латинских букв, имеющих свой верхний регистр в турецком языке) в $upcase, то регистронезависимое сравнение имён файлов, написанных на английском, сломается. А если нет, то сломается сравнение на турецком в данной ФС. Или вы ожидаете, что у пользователя из Турции нет ни одного файла с именем на английском языке? Можно нагородить костылей вродеtoupper('İ') == 'I' && toupper('i') == 'I', но я абсолютно уверен что более опытные товарищи смогут найти пример, который не решается с помощью таких костылей в принципе.Вы можете сделать корректное с точки зрения компьютера регистронезависимое сравнение. Можете даже сделать его переносимым между системами. Но корректное с точки зрения пользователя сравнение невозможно в принципе, потому что имена файлов не имеют свойства «язык», введение с ручным контролем пользователя этого пользователя отвратит, автоматическое проставление языка не всегда корректно и весьма ресурсозатратно, и в любом случае вместо одной кодовой страницы вы получите целую тучу, к тому же станет совершенно не понятно, как нормализовывать имя файла, если в каталоге есть файлы с разной кодовой таблицей.
Команда станет недоступна из истории, как только вы введёте следующую. С моими функциями zshaddhistory и собственным widget'om accept-line (отвечает за исполнение введённой строки, у меня на нём лежит исполнение команд с нестандартным синтаксисом) команда исчезает даже если просто «отправить на исполнение» пустую строку, но вообще-то вам нужно ввести что-то непустое.
!!.man zshoptionsпо‐умолчанию она не включена (как и в bash, кстати). Только zsh всегда даёт вам редактировать ранее введённую команду, а bash — нет.Ну и оказывается, что вместо инвариантной локали всё-таки используется локаль, встроенная в файловую систему. Просто блеск! Теперь количество гиганских таблиц равно количеству файловых систем.
zshaddhistory(не помню, чем меня не устроила настройкаHIST_IGNORE_SPACE). А вообще zsh имеет кучу способов удаления из истории:
Во всех случаях вы можете один раз получить команду повторно, независимо от того, была ли она сохранена в файле или в памяти или не была сохранена ни там, ни там.$HISTORY_IGNORE: переменная, содержащая шаблон, под который должна подпадать игнорируемая командаsetopt HIST_IGNORE_SPACE: настройка, заставляющая игнорировать командную строку, начинающуюся с пробела или использующую обычный (есть ещё suffix и глобальные)alias, начинающийся с пробелаsetopt HIST_NO_FUNCTIONSиsetopt HIST_NO_STORE— игнорируют командную строку, в которой есть определение функции или вызовfczshaddhistory: если данная функция завершится с кодом1, то строка не будет сохранена, а если2, то она не будет сохранена в файле, но будет в памяти.…вручную и случайно дописал четвёрку.¹ Впрочем, возможно, что kcharselect просто отображает этот ромб из другого шрифта, потому он и есть самый популярный у меня. Проверять с помощью fontforge неохота.
Собственно поэтому в powerline я changelog не веду — достаточно того, что список изменений есть на Github и есть полностью его копия в описании изменений в
masterветке.alias -gвсё же имеет преимущество, т.к. все удобные<C-…>у меня уже заняты, да и результат выглядит компактнее. Недостаток — может испортить скрипты, загруженные после создания alias’а.Кстати, zsh при использовании emacs варианта раскладки использует widget для
<C-w>, который считает, что|следует непременно удалять вместе с предшествовавшим словом (даже если оное отделено пробелом).__eq__любым угодным вам способом. Другой вопрос, что в ряде мест (к примеру, при сравнении списков) применяется сравнениеid()перед сравнением объектов: есть известный пример с NaN, или вот ещё:. В CPython и jython картина точно такая же. IronPython покажет два
False, но у него всегда были проблемы с совместимостью.&l:fileformat is# 'dos'при открытии сделать можно, вместе с описанием «а что это такое» и «как исправить» (и «как отключить предупреждение»).Подсвечивать
^Mв тексте всё же можно — «замечаемость» его сильно зависит от используемой цветовой схемы. С моим wombat256mod это особых проблем не доставляло, хотя там и нет кричащего фона. В стандартной схеме^Mпохож на комментарий, что ещё заметнее. Проблем нету в основном потому, что^Mлибо нет вообще, либо он есть везде (при вставке из старой Opera, к примеру). Так что мой комментарий всё же относится к моему опыту.Я бы рекомендовал подсвечивать
всеуправляющие символы, а не\r. Во всех известных мне языках программирования их можно заменить на что‐то из печатных символов, а проблем при использовании VCS или cat они доставить могут (VCS может счесть, что файл является бинарным, а в терминале они не зря называются управляющими).