В чем разница между `set -o` и `bindkey`?
Ожидаемое расположение libcrypto.so.1.1в Debian 9.5 — /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1, а не /usr/lib64... и содержащий его пакет — libssl1.1, содержащий библиотеки OpenSSL; в упаковке Debian пакет opensslсодержит только файлы конфигурации, двоичные файлы команд /usr/bin/opensslи /usr/bin/c_rehashи соответствующие справочные страницы. Пакет openssl(и все, что требует библиотек OpenSSL ), зависит от libssl1.1. Таким образом, управление пакетами позволяет вам устанавливать только библиотеки, если вам не нужен инструмент командной строки openssl-и вы собираете, например. встроенная система с минимальным объемом доступного дискового пространства.
При новой установке Debian 9.x на архитектуре x86 _64 /usr/lib64даже не должно существовать. Тот факт, что он существует, предполагает, что другая копия opensslмогла быть установлена из какого-то альтернативного источника (, возможно, путем копирования двоичных файлов с другого хоста или путем установки пакетов, предназначенных для других дистрибутивов ).
Запустите dpkg --verify libssl1.1 openssl, чтобы проверить целостность пакетов libssl1.1и opensslв вашей системе. В выводе будут перечислены все файлы, которые были изменены :, если, например. двоичный файл /usr/bin/opensslуказан в выводе, вы будете знать, что opensslвашей системы был подделан.
Наихудший -возможный сценарий заключается в том, что ваша система была взломана, и злоумышленник попытался заменить ваш OpenSSL модифицированной версией, из-за которой злоумышленнику будут переданы ваши личные ключи. Если да, то злоумышленник совершил ошибку,возможно, с помощью набора библиотек, предназначенных для систем стиля RHEL/CentOS/Fedora -(, где путь /usr/lib64обычно используется )в вашей системе Debian.
Если вы считаете, что ваша система может быть:взломана, не паникуйте . В Server Fault есть канонический ответ о том, что делать, если вы подозреваете, что ваш сервер был взломан хакером.
bindkey -v/-e— это синтаксис tcsh(встроенная функция bindkeyбыла добавлена в tcsh в 5.19PL2 в 1990 году ), а set -o vi/emacs— это синтаксис ksh (, уже присутствующий в ksh85, вероятно, ранее как ksh имел режим emacs/vi по крайней мере еще в 1983 году ).
В zshbindkeyбыл добавлен в версии 2.0 в 1991 году, которая шла с первой версией zle (1.0, предыдущая версия использовала readline, заимствованную изbash).
zsh, так как первая версия 1.0 имела setoptдля установки параметров (в дополнение к параметрам, передаваемым в командной строке, как в csh/Bourne ), а (t)cshи bashиспользовали специальные вместо переменных. В 2.0 была добавлена опция -o(как для интерпретатора, так и для встроенной set)для совместимости с ksh(bash, которая сама преобразовывала свои специальные переменные в параметры, установленные с помощью новой встроенной shoptв 2.0. в 1996 году; это отдельный набор параметров от тех, которые установлены с помощью set -o; set -oподдержка добавлена примерно в 1990 году ).
«Опции» viи emacsне были добавлены в zsh до 2003 в версии 4.1.1.Парадигма «опция» не очень подходит для этого, так как когда вы устанавливаете опцию emacs, она отключает режим vi.
Вы заметите, что zsh -o emacsи zsh -o viв настоящее время не работают должным образом в том, что zsh сообщает zsh: invalid module name `zsh/zle'при запуске (об ошибке ).
Большинство оболочек, включая zsh, также выбирают режим редактирования по умолчанию на основе значений переменных среды $EDITORи $VISUAL, чтобы попытаться сопоставить режим редактирования строки с предпочтениями редактора пользователя.