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

Я обнаружил что read подерживает миллисекундные таймауты и в bash и в ksh — в статье собственно и есть пример в 4 read подряд. Можно наверное сделать «read -n1» первого нажатия и затем «read -n1 -t 0.01» в цикле, пока не получишь пустую строку, тогда будет универсально — попробую на днях поэксперементировать.

На самом деле текст к времени публикации слегка устарел — я уже избавился от tput (как оказалось он не везде может быть), и в тексте скрипта сейчас его нет нигде, в пользу более универсального stty — для получения размеров я беру данные из «stty size» чтобы получить сразу ширину и высоту — и быстрее и проще, а управляющие коды для цветов вписал статикой.

Но насчет произвольного количества символов — я тогда пока не придумал, как в баш сделать правильное определение нажатие любой клавиши, если совсем неизвестна длина.
По тестам, самое длинное было 4, и если в каком-то терминале те кнопки, которые используются в менеджере будут занимать больше, они могут не сработать.
Насколько это актуально?

За комментарий спасибо!
Согласен, в принципе можно в начале запуска через tput получить актуальные для текущего терминала значения комбинаций для спецкнопок, взять от них max length и повысить совместимость, что важно. Попробую поискать, можно ли это сделать надежно без tput.

Обязательно займусь ( в нерабочее время ;)

А может ты покупаешь шкаф, а тебе говорят — нет, подумайте об архитектуре на будущее, берите шубохранилище.

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

Изначальная задача заключалась в разработке приложения под небольшую клиентскую базу — до 10 000 пользователей.

Ну так а в чем тут несоответствие решения? Клиент хотел 10000, получил 10000. Если у него стало 100.000 то это не архитектура плохая, а требования некорректные.

Назовите пожалуйста названия художки, которые вы читаете, и которая развивает словарный запас? Вот не лучшее в классике, а просто 5-10 последних прочитанных вами книг?

Добрый день. Аккаунта в LinkedIn нет и не планирую. Подтвердите пожалуйста профиль.

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

Тимсити — наверное лучший с точки зрения визуализации всего. Кастомные табы творят чудеса для любых идей. Один раз настроенный профессионалом, легко может поддерживаться джунами. Жаль, что дорогой.

gitlab/github — это то, куда вообще стремится мир пайплайнов. Упрощение всего этого дела, перевод всей кастомизации с уровня CI на уровень сборщиков и контейнеров. Сложно сказать насколько это плохо или хорошо — это выгодно для самого процесса, поэтому скорее всего все там будем.