Хорошо, вы правы. Я почему‐то решил, что вы написали про абсолютно произвольное изменение порядка, а не более конкретный циклический сдвиг — моя способность «додумать» без уточнения несколько промахнулась :)
Зачем? Я не очень представляю себе, как можно реализовывать что‐то поверх протокола уровня UART и получить случайное изменение порядка байтов (если только у вас нет ошибки в программе). Получить мусорный бит в середине на том же SPI при помехах на линии тактирования — можно. Получить инверсию бита из‐за помех — можно. Получить байт(ы) посылки от другого устройства между байтами посылки от первого — можно, но такие проблемы разруливаются не CRC, если только инверсия произошла не при передаче адреса отправителя. А что может привести к изменению порядка байтов кроме ошибки в программе? У того же TCP ожидается произвольный порядок приёма, но пакетов и по очень хорошей причине.
Если вы наберёте в iPython import fnmatch, затем fnmatch??, то увидите, что fnmatch делает ровно то же самое, что и ряд людей выше, включая меня: преобразует шаблон в регулярное выражение.
А может логичнее попытаться с символьными вычислениями? Т.е. вместо диапазонов вы будете хранить набор уравнений и неравенств, определяющих как диапазон входных данных (и только их, диапазоны зависимых переменных вами не вычисляются), так и всё, что происходило с разными переменными. А при нахождении строчки, на которой можно навернуться, добавлять недопустимое условие и скармливать какой‐нибудь CAS (computer algebra system). Если она успешно решает данный набор, то могут быть проблемы и можно доложить пользователю. Если говорит решений нет — то проблем нет. Если зависает или выдаёт ошибку — то либо у вас ошибка в программе, либо система уравнений и неравенств просто слишком сложная для CAS. В обоих случаях нужно использовать запасной план — либо игнорирование (т.е. «в анализируемом коде нет ошибки»), либо уточнение условий (не у пользователя, а на основании эвристики) и перезапуск CAS, либо использование другого алгоритма без символьных вычислений.
Я не думаю, что такой вариант бы сработал с языком общего назначения. Но с GLSL может и зайдёт.
Тем, что мне не нужно писать отдельный код для обработки случая [MANY, 0] (и [MANY, 1], которое .+?). Компилятор Python re всё равно должен скомпилировать оба варианта в один и тот же автомат.
Строго говоря, начало строки можно не указывать из‐за match. Вот конец указать нужно, если ответы как‐то принимаются без него, то что‐то с тестами не так.
Кстати, что с жадным, что с нежадным, и в обоих случаях максимально оптимизированном регулярным выражением Python виснет на тесте 1708, хотя тест 1614 уже на моей машине проходит за примерно 0,2 мс независимо от жадности. Вот, собственно, код:
#!/usr/bin/env python3
import re
START = 0
LITERAL = 1
ANY = 2
SOME = 3
MANY = 4
END = 5
class Solution(object):
@staticmethod
def isMatch(s, p):
atoms = [(START,)]
for ch in p:
last_atom_typ = atoms[-1][0]
if ch == '*':
if last_atom_typ == ANY:
atoms[-1] = [MANY, 1]
elif last_atom_typ == MANY:
pass
elif last_atom_typ == SOME:
atoms[-1] = [MANY, atoms[-1][1]]
else:
atoms.append([MANY, 0])
elif ch=='?':
if last_atom_typ == MANY:
atoms[-1][1] += 1
elif last_atom_typ == SOME:
atoms[-1][1] += 1
elif last_atom_typ == ANY:
atoms[-1] = [SOME, 2]
else:
atoms.append((ANY,))
else:
if last_atom_typ == LITERAL:
atoms[-1][1] += ch
else:
atoms.append([LITERAL, ch])
atoms.append((END,))
atom_to_str_funcs = (
lambda x: '^',
lambda x: x[1],
lambda x: '.',
lambda x: '.{{{}}}'.format(x[1]),
lambda x: '.{{{},}}?'.format(x[1]),
lambda x: '$',
)
r = ''.join((
atom_to_str_funcs[i[0]](i)
for i in atoms
))
return bool(re.match(r, s))
from time import monotonic
# Test 1614
start = monotonic()
print(Solution.isMatch("aaabbbaabaaaaababaabaaabbabbbbbbbbaabababbabbbaaaaba", "a*******b"))
print(monotonic() - start)
# Test 1708
start = monotonic()
print(Solution.isMatch("abbabaaabbabbaababbabbbbbabbbabbbabaaaaababababbbabababaabbababaabbbbbbaaaabababbbaabbbbaabbbbababababbaabbaababaabbbababababbbbaaabbbbbabaaaabbababbbbaababaabbababbbbbababbbabaaaaaaaabbbbbaabaaababaaaabb", "**aa*****ba*a*bb**aa*ab****a*aaaaaa***a*aaaa**bbabb*b*b**aaaaaaaaa*a********ba*bbb***a*ba*bb*bb**a*b*bb"))
print(monotonic() - start)
# Test
# ##test 940
# import time
# pt=time.time()
# print(isMatch("aaaabaaaabbbbaabbbaabbaababbabbaaaababaaabbbbbbaabbbabababbaaabaabaaaaaabbaabbbbaababbababaabbbaababbbba","*****b*aba***babaa*bbaba***a*aaba*b*aa**a*b**ba***a*a*"))
# print(time.time()-pt)
(Для нежадной версии убейте второй вопросительный знак, их здесь всего два.) Я не думаю, что можно сделать что‐то лучше на регулярных выражениях. Вот, кстати, что мой код генерирует для данного теста:
Мне интересно, а зачем вам вообще какая‐либо группировка? * применяется к предыдущему атому, точка — сама по себе атом. Поэтому .* должно нормально зайти. Если добавить ?, то такое решение выдаёт превышение time limit (на моей системе — 8,7 секунд) значительно позже, на тесте 1614:
#!/usr/bin/env python3
import re
class Solution(object):
@staticmethod
def isMatch(s,p):
r = "^"
for ch in p:
if ch == '*':
r += ".*?"
elif ch=='?':
r += "."
else:
r += ch
r += "$"
return bool(re.match(r, s))
# Test 1614
from time import monotonic
start = monotonic()
print(Solution.isMatch("aaabbbaabaaaaababaabaaabbabbbbbbbbaabababbabbbaaaaba", "a*******b"))
print(monotonic() - start)
# ##test 940
# import time
# pt=time.time()
# print(isMatch("aaaabaaaabbbbaabbbaabbaababbabbaaaababaaabbbbbbaabbbabababbaaabaabaaaaaabbaabbbbaababbababaabbbaababbbba","*****b*aba***babaa*bbaba***a*aaba*b*aa**a*b**ba***a*a*"))
# print(time.time()-pt)
TUI — нет. Остальные UI — да. И, кстати, может общаться и через сокеты, и через обычные pipe. Только в случае с Neovim ожидается, что GUI запустит neovim (или, теоретически, присоединится к уже запущенному), а не наоборот.
Мои Casio PRW-2500T работают который год работают без подзарядки, синхронизации (пробовал настроить, т.к. говорили, что что‐то из‐за рубежа они могут ловить, но не получилось) и подстройки времени. До этого были более дешёвые Casio WL-500, лежали на подоконнике с момента покупки новых часов (с 2013) и до сих пор. Эти лежали без подзарядки и синхронизации (не поддерживается автоматическая и не требовалась ручная за неиспользованием) и всё равно показывают, причём правильную дату и время, большее на один час (очевидно, из‐за изменений в часовых поясах) без трёх с небольшим минут (уже из‐за собственного отставания) от реального.
Правда, три с лишним минуты за 5 лет в норматив «10 секунд за год» не укладываются. А новые я вроде когда‐то подводил, но не помню когда и насколько они отставали/спешили (по настроению вполне мог и за отставание на три секунды подвести). Но и те, и те вполне себе позволяли мне плавать (в т.ч. нырять без акваланга) вместе с ними. Вторые ещё имеют встроенный компас, термометр (бесполезен после надевания: температура окружающей среды некорректна из‐за нагрева от тела, для температуры тела датчик расположен неправильно; но можно мерить температуру воды при купании), барометр, секундомер, таймер и будильники. И титановый ремешек, который ваших внуков переживёт. Единственная претензия — неправильный (непривычный для нормального русского человека) порядок месяца и числа.
Аккумуляторы ни тем, ни тем я не менял. Но у дешёвых менялся ремень один раз (порвался сам ремень) и ещё уже у нового ремня порвалась штуковина, придерживающая конец ремня. После чего я их и поменял на то, у чего ремешек не сломается.
Я не знаю про софт ЯД на Windows, на linux я вполне себе использую davfs2 для доступа к ЯД. В сообщении это просто пример того, что вы не захотите монтировать на букву диска, а не тычок в сторону Windows — как я указал там же, я знаю, что в Windows реально можно монтировать не только на букву, просто это видится отдельным механизмом, тогда как linux вариант выглядит более целостно.
Как сказали выше, представления разные. Но каталог — это часто по сути просто специальным образом отмеченный файл, в котором в некотором виде хранится таблица соответствия имени файла в каталоге и его inode. «Жёсткая ссылка» на файл означает, что один inode присутствует в двух таких специальных файлах. Т.к. каталог — тоже файл — то с помощью hex редактора по идее можно сделать жёсткую ссылку на каталог. Но тут возникают проблемы целостности: что означает hardlink/.. в таком случае? И это не говоря уже о возможности подсунуть какой‐нибудь ничего не подозревающей программе, рекурсивно обходящей каталоги, каталоги с бесконечной вложенностью — а даже сейчас не все такие программы умеют обрабатывать бесконечную вложенность символических ссылок (привет, Vim, как ни странно).
Потому что слишком ограничено. И либо провоцирует сложности с контролем доступа, если вы, к примеру, хотите в многопользовательской ОС использовать ваш Яндекс.Диск как каталог, но не давать доступа к нему другим пользователям. Либо заставляет создавать отдельные механизмы: вы знаете, что в Windows можно примонтировать диск в пустую NTFS папку? Вопрос: если в Windows с дисками считают необходимым иметь такую функциональность, то зачем реализовывать заведомо слабофункциональную систему в новой ОС?
Кроме того, попробуйте придумать, как выглядел бы тот же chroot с Windows‐подобным монтированием? А это ведь неплохой инструмент отладки изменённого окружения при неизменённом ядре.
Ещё вы с linux‐подобным монтированием вы можете отправить Program files на отдельный диск, даже если система пока не поддерживает ничего, кроме FAT32, а в FAT32 нет символических ссылок (не говоря уже о жёстких ссылках, которые для каталогов не поддерживаются нигде).
Ещё, кстати, а зачем в новой ОС обратные косые черты в пути? В бо́льшей части языков программирования это символ экранирования и потому нифига не удобен в путях.
Документация на $PROMPT_EOL_MARK явно указывает на то, какие настройки отвечают за это поведение. Установка в пустую строку не является отключением, просто не будет визуальной индикации, что команда завершилась без новой строки, но новая строка будет добавляться, знака процента только не будет.
Но мне кажется, вопрос не в том «как отключить», а «отключить при открытии терминала». При открытии терминала этот процент показываться не должен, потому что ещё не введены никакие команды. Я не имею ни малейшего понятия, как можно случайно вывести этот процент в файлах настроек, но, возможно, терминал при открытии что‐то шлёт, что воспринимается как команда. Отключение показа просто лишит человека удобной возможности и спрячет какую‐то проблему, не решив её.
Сказать что за проблема сложно, я бы предложил
Сначала удалить (переименовать так, чтобы zsh не нашёл) файлы настроек. Если процент останется, то виноват терминал. Если нет, то дело в каких‐то плагинах.
Добавить set -x в начало какого‐либо файла настроек zsh. Например, zshrc, но лучше в /etc[/zsh]/zshenv (по‐умолчанию в /etc/zshenv, но, к примеру, в Gentoo zsh компилируется так, чтобы он искал этот файл в /etc/zsh/zshenv). После получения в начале терминала кучи строк вроде +_zsh_highlight_preexec_hook:3> typeset -gi _ZSH_HIGHLIGHT_PRIOR_CURSOR=0 вместо процента нужно убедиться, что вы видите начало вывода (следующую за set -x строку с какой‐либо командой, рекомендую просто добавить после set -x что‐то вроде true start: true ничего не делает с аргументом и ничего не выводит, но в трассировке появится), скопировать весь вывод в какой‐либо текстовый редактор и поискать для начала там /bin/zsh: запускаемые пользователем команды в выводе set -x выглядят как +/bin/zsh:4> foo.
Если таким образом нашлась какая‐то команда, которую вы не печатали, то попытайтесь по окружению определить, откуда она взялась. Как гарантированно найти проблему, если такой команды нет, я не знаю, но я бы просто просмотрел вывод на предмет того, понимаю ли я что там происходит и откуда берутся команды.
Если вы используете что‐то вроде oh-my-zsh, то просмотр вывода после set -x на предмет «зачем и откуда» может оказаться кошмаром. Но тут должно быть возможно отключение плагинов блоками до того момента, как процент при запуске не перестанет показываться.
(процент после abc нарисован инвертированно) (кстати, хочу заметить, что при копировании между подсвеченным % и z нет символа новой строки, только много пробелов).
Если попробовать эквивалентный вариант с bash, то получите что‐то вроде
С неподсвеченными приглашениями ко вводу это особенно заметно: попробуйте быстро найти где заканчивается abc и начинается приглашение. И это не всё: нажмите t и дождитесь, пока символов не станет много (для гарантии — пока «команда» не перейдёт на новую строку). Когда у вас набралась команда вида tttttttttttttttttttttttttttttttttttttttttttttttttttt нажмите <C-u>. В нормальной ситуации вы получите bash-4.4$. С abcbash-4.4$ вы получите abcbash-4.: bash не понимает, где реально находится ваш ввод и все возможности, которые должны знать позицию курсора, будут работать некорректно.
Кстати, а почему «грустный смайлик», а не собственно код? Код завершения иногда предоставляет дополнительные данные: во‐первых, у некоторых программ они задокументированы. Во‐вторых, при завершении по (необработанному) сигналу код будет иметь определённое значение.
В‐третьих, если только последняя команда из цепочки вида a | b | c завершилась с ошибкой, то код завершения будет ненулевым. Нужно показывать $pipestatus (весь, если хотя бы одна программа завершилась с ошибкой), но пачка смайликов будет выглядеть как‐то странно.
В zsh по‐умолчанию нет никаких alias, кроме run-help=man и which-command=whence. Можете проверить с zsh -f. Вы говорите либо про какие‐то системные файлы настроек, либо про сборку вроде oh-my-zsh.
Зачем хранить в истории дубликаты команд? Если не ошибаюсь, то это не даст нормально использовать поиск по началу строки. И в любом случае ограничит число различных команд, которые вы могли бы хранить в истории. И всё это с единственным сомнительным плюсом возможности получить статистику использования, что можно организовать отдельно, не замусоривая историю.
PS: Для zsh нужно использовать не history, а history -- $[-2**31]; вместо $[-2**31] нужно использовать отрицательное число по модулю не менее длины истории (но влезающее в (?)int поскольку наименьшее число на моей 64‐битной системе — $[2**63], только его использование вызывает ошибку как если бы я использовал положительное число). (Обычно можно просто написать history -- -10000000 и не парится.) Просто history по‐умолчанию выдаст только последние несколько команд (у меня 16).
Не вижу тут фантастики. Во‐первых, если нужно, то замерить можно: вы знали, что в природе существуют 100 ГГц осциллографы? (Он, конечно, скорее всего обойдётся намного дороже машины, но это точно не фантастика. К тому же, если измерять такие задержки осциллографом, то и одного ГГц достаточно.) Во‐вторых, если что‐то нельзя измерить напрямую, то есть другие методы: нужно просто вместо одной сессии запрос‐ответ сделать длинную цепочку запрос‐ответ‐запрос‐… Джиттер от тактового генератора можно уменьшить дополнительным шагом: просто сначала с помощью надёжной, но медленной, схемы машина передаёт брелку шифроблокнот, а сама генерирует случайный набор данных. Потом в цепочке запрос‐ответ‐запрос машина использует уже сгенерированный набор данных, а брелок просто делает xor запросов с шифроблокнотом и отправляет обратно. Измеряется время всей цепочки, определяется диапазон, в котором это время должно находится, сравнивается.
Можно ещё сильнее уменьшить джиттер тактового генератора, если xor’ить и управлять передающей антенной в брелке будет FPGA. Хотя я не говорю, что FPGA тактовый сигнал не нужен, просто FPGA в такой схеме позволяет сформировать ответную посылку фактически сразу после приёма последнего байта, начав отправку немедленно. Джиттер будет влиять только задержку между приёмом и началом отправки (не более одного такта, и даже отсутствует, если есть возможность сделать триггер по концу приёма) и на длительность отправки (совершенно не важно, так как можно измерить длительность посылки и вычесть из времени всей цепочки: в конце концов, нас волнует только задержка между концом отправки со стороны автомобиля и началом приёма на стороне автомобиля).
А почему релокация именно в столицу/крупный город? Некоторые уезжают и наоборот, в города помельче.
Хорошо, вы правы. Я почему‐то решил, что вы написали про абсолютно произвольное изменение порядка, а не более конкретный циклический сдвиг — моя способность «додумать» без уточнения несколько промахнулась :)
Зачем? Я не очень представляю себе, как можно реализовывать что‐то поверх протокола уровня UART и получить случайное изменение порядка байтов (если только у вас нет ошибки в программе). Получить мусорный бит в середине на том же SPI при помехах на линии тактирования — можно. Получить инверсию бита из‐за помех — можно. Получить байт(ы) посылки от другого устройства между байтами посылки от первого — можно, но такие проблемы разруливаются не CRC, если только инверсия произошла не при передаче адреса отправителя. А что может привести к изменению порядка байтов кроме ошибки в программе? У того же TCP ожидается произвольный порядок приёма, но пакетов и по очень хорошей причине.
Если вы наберёте в iPython
import fnmatch, затемfnmatch??, то увидите, чтоfnmatchделает ровно то же самое, что и ряд людей выше, включая меня: преобразует шаблон в регулярное выражение.А может логичнее попытаться с символьными вычислениями? Т.е. вместо диапазонов вы будете хранить набор уравнений и неравенств, определяющих как диапазон входных данных (и только их, диапазоны зависимых переменных вами не вычисляются), так и всё, что происходило с разными переменными. А при нахождении строчки, на которой можно навернуться, добавлять недопустимое условие и скармливать какой‐нибудь CAS (computer algebra system). Если она успешно решает данный набор, то могут быть проблемы и можно доложить пользователю. Если говорит решений нет — то проблем нет. Если зависает или выдаёт ошибку — то либо у вас ошибка в программе, либо система уравнений и неравенств просто слишком сложная для CAS. В обоих случаях нужно использовать запасной план — либо игнорирование (т.е. «в анализируемом коде нет ошибки»), либо уточнение условий (не у пользователя, а на основании эвристики) и перезапуск CAS, либо использование другого алгоритма без символьных вычислений.
Я не думаю, что такой вариант бы сработал с языком общего назначения. Но с GLSL может и зайдёт.
Тем, что мне не нужно писать отдельный код для обработки случая
[MANY, 0](и[MANY, 1], которое.+?). Компилятор Python re всё равно должен скомпилировать оба варианта в один и тот же автомат.Строго говоря, начало строки можно не указывать из‐за
match. Вот конец указать нужно, если ответы как‐то принимаются без него, то что‐то с тестами не так.Кстати, что с жадным, что с нежадным, и в обоих случаях максимально оптимизированном регулярным выражением Python виснет на тесте 1708, хотя тест 1614 уже на моей машине проходит за примерно 0,2 мс независимо от жадности. Вот, собственно, код:
(Для нежадной версии убейте второй вопросительный знак, их здесь всего два.) Я не думаю, что можно сделать что‐то лучше на регулярных выражениях. Вот, кстати, что мой код генерирует для данного теста:
^.{0,}?aa.{0,}?ba.{0,}?a.{0,}?bb.{0,}?aa.{0,}?ab.{0,}?a.{0,}?aaaaaa.{0,}?a.{0,}?aaaa.{0,}?bbabb.{0,}?b.{0,}?b.{0,}?aaaaaaaaa.{0,}?a.{0,}?ba.{0,}?bbb.{0,}?a.{0,}?ba.{0,}?bb.{0,}?bb.{0,}?a.{0,}?b.{0,}?bb$Мне интересно, а зачем вам вообще какая‐либо группировка?
*применяется к предыдущему атому, точка — сама по себе атом. Поэтому.*должно нормально зайти. Если добавить?, то такое решение выдаёт превышение time limit (на моей системе — 8,7 секунд) значительно позже, на тесте 1614:TUI — нет. Остальные UI — да. И, кстати, может общаться и через сокеты, и через обычные pipe. Только в случае с Neovim ожидается, что GUI запустит neovim (или, теоретически, присоединится к уже запущенному), а не наоборот.
Мои Casio PRW-2500T работают который год работают без подзарядки, синхронизации (пробовал настроить, т.к. говорили, что что‐то из‐за рубежа они могут ловить, но не получилось) и подстройки времени. До этого были более дешёвые Casio WL-500, лежали на подоконнике с момента покупки новых часов (с 2013) и до сих пор. Эти лежали без подзарядки и синхронизации (не поддерживается автоматическая и не требовалась ручная за неиспользованием) и всё равно показывают, причём правильную дату и время, большее на один час (очевидно, из‐за изменений в часовых поясах) без трёх с небольшим минут (уже из‐за собственного отставания) от реального.
Правда, три с лишним минуты за 5 лет в норматив «10 секунд за год» не укладываются. А новые я вроде когда‐то подводил, но не помню когда и насколько они отставали/спешили (по настроению вполне мог и за отставание на три секунды подвести). Но и те, и те вполне себе позволяли мне плавать (в т.ч. нырять без акваланга) вместе с ними. Вторые ещё имеют встроенный компас, термометр (бесполезен после надевания: температура окружающей среды некорректна из‐за нагрева от тела, для температуры тела датчик расположен неправильно; но можно мерить температуру воды при купании), барометр, секундомер, таймер и будильники. И титановый ремешек, который ваших внуков переживёт. Единственная претензия — неправильный (непривычный для нормального русского человека) порядок месяца и числа.
Аккумуляторы ни тем, ни тем я не менял. Но у дешёвых менялся ремень один раз (порвался сам ремень) и ещё уже у нового ремня порвалась штуковина, придерживающая конец ремня. После чего я их и поменял на то, у чего ремешек не сломается.
И да, Casio PRW-2500T всё ещё продаются.
Я не знаю про софт ЯД на Windows, на linux я вполне себе использую davfs2 для доступа к ЯД. В сообщении это просто пример того, что вы не захотите монтировать на букву диска, а не тычок в сторону Windows — как я указал там же, я знаю, что в Windows реально можно монтировать не только на букву, просто это видится отдельным механизмом, тогда как linux вариант выглядит более целостно.
Как сказали выше, представления разные. Но каталог — это часто по сути просто специальным образом отмеченный файл, в котором в некотором виде хранится таблица соответствия имени файла в каталоге и его inode. «Жёсткая ссылка» на файл означает, что один inode присутствует в двух таких специальных файлах. Т.к. каталог — тоже файл — то с помощью hex редактора по идее можно сделать жёсткую ссылку на каталог. Но тут возникают проблемы целостности: что означает
hardlink/..в таком случае? И это не говоря уже о возможности подсунуть какой‐нибудь ничего не подозревающей программе, рекурсивно обходящей каталоги, каталоги с бесконечной вложенностью — а даже сейчас не все такие программы умеют обрабатывать бесконечную вложенность символических ссылок (привет, Vim, как ни странно).Потому что слишком ограничено. И либо провоцирует сложности с контролем доступа, если вы, к примеру, хотите в многопользовательской ОС использовать ваш Яндекс.Диск как каталог, но не давать доступа к нему другим пользователям. Либо заставляет создавать отдельные механизмы: вы знаете, что в Windows можно примонтировать диск в пустую NTFS папку? Вопрос: если в Windows с дисками считают необходимым иметь такую функциональность, то зачем реализовывать заведомо слабофункциональную систему в новой ОС?
Кроме того, попробуйте придумать, как выглядел бы тот же chroot с Windows‐подобным монтированием? А это ведь неплохой инструмент отладки изменённого окружения при неизменённом ядре.
Ещё вы с linux‐подобным монтированием вы можете отправить Program files на отдельный диск, даже если система пока не поддерживает ничего, кроме FAT32, а в FAT32 нет символических ссылок (не говоря уже о жёстких ссылках, которые для каталогов не поддерживаются нигде).
Ещё, кстати, а зачем в новой ОС обратные косые черты в пути? В бо́льшей части языков программирования это символ экранирования и потому нифига не удобен в путях.
Документация на $PROMPT_EOL_MARK явно указывает на то, какие настройки отвечают за это поведение. Установка в пустую строку не является отключением, просто не будет визуальной индикации, что команда завершилась без новой строки, но новая строка будет добавляться, знака процента только не будет.
Но мне кажется, вопрос не в том «как отключить», а «отключить при открытии терминала». При открытии терминала этот процент показываться не должен, потому что ещё не введены никакие команды. Я не имею ни малейшего понятия, как можно случайно вывести этот процент в файлах настроек, но, возможно, терминал при открытии что‐то шлёт, что воспринимается как команда. Отключение показа просто лишит человека удобной возможности и спрячет какую‐то проблему, не решив её.
Сказать что за проблема сложно, я бы предложил
Добавить
set -xв начало какого‐либо файла настроекzsh. Например,zshrc, но лучше в/etc[/zsh]/zshenv(по‐умолчанию в/etc/zshenv, но, к примеру, в Gentoo zsh компилируется так, чтобы он искал этот файл в/etc/zsh/zshenv). После получения в начале терминала кучи строк вроде+_zsh_highlight_preexec_hook:3> typeset -gi _ZSH_HIGHLIGHT_PRIOR_CURSOR=0вместо процента нужно убедиться, что вы видите начало вывода (следующую заset -xстроку с какой‐либо командой, рекомендую просто добавить послеset -xчто‐то вродеtrue start:trueничего не делает с аргументом и ничего не выводит, но в трассировке появится), скопировать весь вывод в какой‐либо текстовый редактор и поискать для начала там/bin/zsh: запускаемые пользователем команды в выводеset -xвыглядят как+/bin/zsh:4> foo.Если таким образом нашлась какая‐то команда, которую вы не печатали, то попытайтесь по окружению определить, откуда она взялась. Как гарантированно найти проблему, если такой команды нет, я не знаю, но я бы просто просмотрел вывод на предмет того, понимаю ли я что там происходит и откуда берутся команды.
set -xна предмет «зачем и откуда» может оказаться кошмаром. Но тут должно быть возможно отключение плагинов блоками до того момента, как процент при запуске не перестанет показываться.Если команда не вывела в конце новую строку, то эта возможность zsh предотвратит слияние вывода команды с приглашением ко вводу.
Это лучше объяснить на примере: запустите
zsh -fи наберите тамecho -n abc. Получите что‐то вроде(процент после abc нарисован инвертированно) (кстати, хочу заметить, что при копировании между подсвеченным
%иzнет символа новой строки, только много пробелов).Если попробовать эквивалентный вариант с
bash, то получите что‐то вродеС неподсвеченными приглашениями ко вводу это особенно заметно: попробуйте быстро найти где заканчивается
abcи начинается приглашение. И это не всё: нажмитеtи дождитесь, пока символов не станет много (для гарантии — пока «команда» не перейдёт на новую строку). Когда у вас набралась команда видаttttttttttttttttttttttttttttttttttttttttttttttttttttнажмите<C-u>. В нормальной ситуации вы получитеbash-4.4$. Сabcbash-4.4$вы получитеabcbash-4.: bash не понимает, где реально находится ваш ввод и все возможности, которые должны знать позицию курсора, будут работать некорректно.Кстати, а почему «грустный смайлик», а не собственно код? Код завершения иногда предоставляет дополнительные данные: во‐первых, у некоторых программ они задокументированы. Во‐вторых, при завершении по (необработанному) сигналу код будет иметь определённое значение.
В‐третьих, если только последняя команда из цепочки вида
a | b | cзавершилась с ошибкой, то код завершения будет ненулевым. Нужно показывать$pipestatus(весь, если хотя бы одна программа завершилась с ошибкой), но пачка смайликов будет выглядеть как‐то странно.В zsh по‐умолчанию нет никаких alias, кроме
run-help=manиwhich-command=whence. Можете проверить сzsh -f. Вы говорите либо про какие‐то системные файлы настроек, либо про сборку вроде oh-my-zsh.Зачем хранить в истории дубликаты команд? Если не ошибаюсь, то это не даст нормально использовать поиск по началу строки. И в любом случае ограничит число различных команд, которые вы могли бы хранить в истории. И всё это с единственным сомнительным плюсом возможности получить статистику использования, что можно организовать отдельно, не замусоривая историю.
PS: Для zsh нужно использовать не
history, аhistory -- $[-2**31]; вместо$[-2**31]нужно использовать отрицательное число по модулю не менее длины истории (но влезающее в (?)intпоскольку наименьшее число на моей 64‐битной системе —$[2**63], только его использование вызывает ошибку как если бы я использовал положительное число). (Обычно можно просто написатьhistory -- -10000000и не парится.) Простоhistoryпо‐умолчанию выдаст только последние несколько команд (у меня 16).Не вижу тут фантастики. Во‐первых, если нужно, то замерить можно: вы знали, что в природе существуют 100 ГГц осциллографы? (Он, конечно, скорее всего обойдётся намного дороже машины, но это точно не фантастика. К тому же, если измерять такие задержки осциллографом, то и одного ГГц достаточно.) Во‐вторых, если что‐то нельзя измерить напрямую, то есть другие методы: нужно просто вместо одной сессии запрос‐ответ сделать длинную цепочку запрос‐ответ‐запрос‐… Джиттер от тактового генератора можно уменьшить дополнительным шагом: просто сначала с помощью надёжной, но медленной, схемы машина передаёт брелку шифроблокнот, а сама генерирует случайный набор данных. Потом в цепочке запрос‐ответ‐запрос машина использует уже сгенерированный набор данных, а брелок просто делает xor запросов с шифроблокнотом и отправляет обратно. Измеряется время всей цепочки, определяется диапазон, в котором это время должно находится, сравнивается.
Можно ещё сильнее уменьшить джиттер тактового генератора, если xor’ить и управлять передающей антенной в брелке будет FPGA. Хотя я не говорю, что FPGA тактовый сигнал не нужен, просто FPGA в такой схеме позволяет сформировать ответную посылку фактически сразу после приёма последнего байта, начав отправку немедленно. Джиттер будет влиять только задержку между приёмом и началом отправки (не более одного такта, и даже отсутствует, если есть возможность сделать триггер по концу приёма) и на длительность отправки (совершенно не важно, так как можно измерить длительность посылки и вычесть из времени всей цепочки: в конце концов, нас волнует только задержка между концом отправки со стороны автомобиля и началом приёма на стороне автомобиля).