Hacker News Digest

С версии 0.157.0 CLI-инструмент Codex при простом запуске интерактивной сессии стал автоматически поднимать постоянный фоновый демон (codex app-server --managed-daemon). Он работает без TTY, переживает закрытие всех окон (переподчиняется процессу 1) и завершается только командой остановки или перезагрузкой. Автор предлагает сделать daemon_auto_start опциональным (по умолчанию false) либо хотя бы один раз спрашивать согласие.

Демон копирует весь платформенный пакет (~374 МБ: codex, codex-code-mode-host, встроенные bwrap/zsh/rg) в ~/.codex/packages/app-server-daemon/releases/<версия>/ и запускается из копии, из-за чего версия бэкенда расходится с установленной через пакетный менеджер. Отдельный самообновляющийся процесс (pid-update-loop) проверяет обновления через 5 минут, затем ежечасно, скачивает новые релизы и перезапускает бэкенд, что может убивать активные сессии. Демон также «закрепляет» окружение первой сессии: например, переменные HTTPS_PROXY остаются от того запуска, который его стартовал, независимо от параметров последующих сессий.

Для CLI ожидаемо, чтобы бэкенд жил и умирал вместе с окном, запускал установленный бинарник и не обновлялся сам. Если поведение оставят по умолчанию, автор просит завершать демон при отключении последнего клиента и не копировать/самообновляться при установке через npm/brew/pacman. Обнаружен и баг: daemon stop останавливает app-server, но оставляет pid-update-loop живым. Обходной путь — отключить функцию, остановить демон, вручную убить процесс обновления и удалить каталог пакета.

Автозапуск демона Codex CLI вызывает проблемы: баги, переполнение диска (до 12 ГБ в ~/.codex), нарушение прав доступа (например, .git становится доступен только для чтения) и блокировку выполнения целей. Демон работает независимо от TTY и не наследует переменные окружения шелла, что ломает автоматизацию. Некоторые пользователи считают такой скрытый процесс небезопасным и сравнивают его с «бекдором». Способы решения: 1. Отключить автозапуск в ~/.codex/config.toml: `[features] daemon_auto_start = false`. 2. Использовать флаг `--no-daemon`. 3. Полностью заблокировать демон, заменив pid- и lock-файлы ссылками на /dev/null с командой `chattr +i`. 4. Перейти на минимальные инструменты (hax) или изолировать Codex в Docker-контейнере с фиксированными версиями. Мнения об автообновлениях разделились: одни считают их стандартной практикой, другие — опасными и враждебными к пользователю.

Тильда в переменной PATH не раскрывается в домашний каталог, если она находится в кавычках или после двоеточия в присваивании переменной. Например, строка export PATH="$PATH:~/.local/bin/" добавит в PATH буквальную строку ~/.local/bin/, которая интерпретируется как относительный путь ./~/.local/bin/ относительно текущего рабочего каталога, а не как $HOME/.local/bin/. Это может привести к неожиданному поведению, например, запуску программ из поддельной структуры каталогов вроде ./~/. Раскрытие тильды происходит только в незакавыченных контекстах сразу после = или :, поэтому даже export PATH=$PATH:~/.local/bin работает в Bash и Zsh, но ломается при наличии пробелов. Надёжный способ — использовать $HOME: export PATH="$PATH:$HOME/.local/bin/". Проверить наличие проблемы можно командой echo "$PATH" | grep '~'. Если вывод не пустой — замените ~ на $HOME в конфигурационных файлах оболочки. Инструмент nono полезно предупреждает об таких уязвимостях в песочнице.

Проблема с тильдой в PATH — распространённая ловушка. Решение — не в кавычках, а в использовании $HOME или правильном расположении тильды вне кавычек. Тильда раскрывается только в определённых контекстах: в присваивании переменных без кавычек, но не в двойных кавычках или после двоеточия — это особенность POSIX-оболочек. Для переносимости скриптов следует использовать #!/bin/bash явно, так как /bin/sh часто не является bash. Использование кавычек вокруг переменных (например, $PATH) обязательно, но тильда должна быть за пределами двойных кавычек, как в export PATH='$PATH':~/.local/bin. В скриптах рекомендуется избегать ~ вообще, используя $HOME, $XDG_DATA_HOME и другие явные переменные окружения для надёжности и читаемости. Расширение тильды — не подстановка переменной, а специфическая операция, не срабатывающая внутри двойных кавычек. Спор: @amarshall утверждает, что не нужно квотировать строки в bash, но @kragen опровергает, показывая, что тильда не раскрывается в некоторых контекстах, например, при конкатенации с переменной. Опыт участников показывает, что создание директории с именем '~' — частая ошибка при неправильной обработке тильды в конфигах инструментов (Perl-утилиты, IDE). Для избежания проблем с расширением тильды в PATH рекомендуется писать export PATH=~/.local/bin:$PATH без кавычек, так как присваивание переменной в bash не требует кавычек. Поведение ~username (например, ~root) работает, но не обсуждается. Использование HOME=/tmp/my-test-home переопределяет поведение ~, что может привести к неожиданным результатам при ручном изменении HOME. Чтение man bash — единственный надёжный способ избежать ловушек, так как поведение тильды и кавычек описано там детально.

Маленькие знания часто дают большой эффект в повседневной работе инженера. Например, ctrl + r в терминале можно улучшить с помощью fzf для нечёткого поиска истории или atuin, который хранит историю в SQLite и позволяет искать по директориям. В SQL можно выполнять SELECT без FROM — удобно для тестирования функций или проверки выражений вроде SELECT TRUE <> NULL. Для оптимизации запросов в PostgreSQL и MySQL полезно EXPLAIN ANALYZE, которое выполняет запрос и показывает детальную производительность. В регулярных выражениях \b помогает находить границы слов, а логарифмы удобны для bucketing метрик — например, Math.floor(Math.log10(count)) группирует значения по порядкам величины. В современном JavaScript полезны Array.flatMap, Object.entries и Promise.withResolvers, а в Node.js — повторное использование HTTPS-соединений через https.Agent, что снижает латентность. В Git: git log -S pattern ищет коммиты, где строка была добавлена или удалена («git pickaxe»), git checkout - переключается на предыдущий HEAD, а вместо find часто достаточно **/*.md при включённом globstar в Bash. Для поиска по содержимому файлов лучше использовать rg (ripgrep), а в Zsh стоит включить автодополнение через compinit и настроить FPATH для функций от Homebrew. Эти приёмы не требуют глубоких знаний, но экономят время и снижают когнитивную нагрузку. Аналогично в компаниях ценны небольшие внутренние лайфхаки: какой источник данных смотреть при проблеме, кто эксперт в определённой области, где лежит документация по сложной теме, когда нужно вручную масштабировать систему, какая команда делает rolling restart, какой утилитой удобно скриптировать рутинную задачу. Один такой совет в день — достаточно, чтобы не перегружать команду, но полезно для тех, кто ещё не знал этого трюка. Даже если вы знаете 9 из 10, десятый может сэкономить час работы и спровоцировать полезное обсуждение. Старшим инженерам стоит делиться такими знаниями — они формируют культуру эффективной работы.

Эффективность мелких трюков зависит от привычки и системного закрепления, а не от их наличия. Инженеры годами используют неоптимальные методы из-за привычки и лени, несмотря на знание более быстрых альтернатив. Записывайте полезные трюки в легко доступный документ — это помогает вспомнить их при необходимости, не полагаясь на память или поиск в интернете. Размещайте чит-листы на стене или в рабочем пространстве — физическое присутствие подсказок повышает вероятность их применения. Создавайте bash-алиасы или скрипты, которые 'порицают' за использование устаревших команд — это формирует новую привычку (как @lelandbatey с git switch). Храните редко используемые, но важные команды в файле типа ~/scratch.txt с grep-доступом — это надежнее, чем история shell. Используйте zoxide вместо cd — он запоминает частые директории и позволяет прыгать между ними без цепочек ../.. (как @disinterred). Используйте zhist для улучшенного поиска истории Zsh с контекстом — он лучше стандартного fzf (как @overflowy). Сохраняйте полезные команды в Makefile или инструментарии приложения — это делает их воспроизводимыми и устраняет необходимость вводить их вручную (как @cachvico). Пишите полезные трюки на собственном сайте — это делает их долговечными и удобными для обмена (как @AJRF). Изучайте трюки, наблюдая за тем, как AI выполняет задачи — часто AI использует неизвестные вам команды (например, в perf, как @kccqzy и @SebasDev). Спор: Некоторые считают, что трюки вроде SELECT без FROM зависят от СУБД — например, IBM-продукты могут не поддерживать это (как @rf15). Спор: Некоторые считают, что эти трюки — не программирование, а администрирование или CLI-навыки (как @ozim и @1vuio0pswjnm7). Спор: Некоторые считают, что трюки устаревают из-за AI — например, @bufordtwain и @monideas считают, что AI делает их менее полезными. Используйте git ls-files вместо find для поиска файлов в репозитории — это быстрее и точнее (как @lucasoshiro). Используйте rg --hidden -g '!*.lock' для фильтрации шума в поиске — это эффективно для повседневной работы (как @ahmedhossamdev). Используйте pbcopy на macOS для копирования вывода команды в буфер обмена — это ускоряет работу с API-ответами (как @okinternets).

zoxide — это умная замена команды cd, которая запоминает часто посещаемые каталоги и позволяет быстро переходить по ним с помощью частичного совпадения имён. Она поддерживает все основные оболочки, включая bash, zsh и fish, и использует алгоритм ранжирования для предложения наиболее релевантных путей.

Инструмент работает быстрее аналогов вроде autojump, так как написан на Rust, и интегрируется с fzf для интерактивного выбора. Практический бонус — экономия времени при навигации в сложных проектных структурах.

• Критика zoxide за нечёткость работы и потенциальные ошибки при навигации, а также предпочтение встроенного поиска по истории ZSH или комбинации с fzf.
• Положительные отзывы о значительном ускорении навигации и интеграции zoxide в рабочий процесс, особенно в сочетании с другими инструментами (fzf, bat, starship).
• Обсуждение альтернатив и схожих инструментов (autojump, z, navita, CDPATH в bash/zsh), их сравнение с zoxide.
• Варианты настройки и использования zoxide, включая алиасы для cd, флаг basedir и интерактивный режим zi.
• Замечания о том, что для многих пользователей нативные возможности оболочки или другие инструменты покрывают большинство потребностей.

rv — новый Ruby-менеджер
Десять лет я мечтал о менеджере, который одновременно управляет Ruby-версиями, ставит уже скомпилированные интерпретаторы и запускает любой скрипт без конфликтов. Такой инструмент уже есть — это Python-утилита uv. Вдохновившись ею, я начал делать rv.

Что умеет rv

• Написан на Rust ⇒ всё мгновенно: установка Ruby 3.4.x на macOS/Ubuntu занимает 1 с.
• rv tool run — запуск любой gem-команды (gist, rubocop, …) в изолированном окружении без предварительной настройки.
• rv tool install — ставит CLI-утилиту с собственным Ruby и гемами, не трогая проект.
• Однофайловые скрипты: внутри .rb хранятся версия Ruby и lock-файл; rv run script.rb — и всё работает.
• Единая команда вместо цепочки rvm install, bundle install, bundle exec.

Команда и статус
Уже подключились Samuel Giddins (RubyGems) и Sam Stephenson (rbenv). Сейчас rv умеет переключать Ruby в zsh и ставить готовые сборки.
Попробовать: spinel-coop/rv и roadmap.

• Участники обсуждают новый инструмент rv для Ruby, вдохновлённый uv из Python-мира.
• Одни рады скорости и «одному инструменту для всего» (Ruby + gems + инструменты), другие считают, что Bundler и так работает нормально.
• Часть разработчиков предпочитает универсальные менеджеры (mise, asdf, Nix), чтобы не плодить отдельные утилиты под каждый язык.
• Есть опасения, что Ruby может пойти по пути «venv-ада» Python или потребовать Rust для вклада.
• Несколько человек просят сравнительную таблицу с rvm/rbenv и поддержку .tool-versions.

Я обожаю dotfiles.

“Dotfiles” — это конфигурационные файлы для программ и ОС, часто начинаются с точки: .bashrc, .tmux.conf, .zshrc. Когда софт не поддерживает настройку файлами, грустно: сложнее синхронизировать конфиги между устройствами и при настройке новых машин.

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

Но свои публиковать некомфортно: мои алиасы, кастомизации и решения кажутся слишком личными. Почему — точно не знаю.

У меня есть классный репозиторий с кучей всего: конфиг zsh и алиасы, tmux, neovim и vscode, Python startup-скрипт. Храню список пакетов Homebrew — ставлю на новый компьютер одной командой. Там же — CSS-правила для Stylus, чтобы везде получать нужный вид.

Для управления использую GNU Stow: структура папок позволяет командой stow [folder] раскидать симлинки по нужным местам, и изменения синхронизируются на всех машинах. Это очень удобно.

В сумме там 19 конфигов плюс весь мой neovim с плагинами. Но пока я «берегу их как тайну», пока не почувствую готовность делиться.

Если откликнулось — напишите на juhamattisantala at gmail dot com. В 2025 хочу больше глубоких разговоров с людьми со всего мира — буду рад вашему письму.

• Участники разделились: одни считают дотфайлы слишком личными/уязвимыми для публикации, другие — ценным источником обмена знаниями и вдохновения.
• Главные опасения: утечки секретов и контекста (хосты, пути, IP, корпоративные детали), риски социнженерии и отпечатков, а также стыд/страх оценки «неидеальной» личной конфигурации.
• Распространенная практика — разделение на слои: публичные «универсальные» настройки, приватные оверрайды и секреты; отдельные репозитории, шифрование (age/gpg, sops), менеджеры вроде chezmoi, myba, Polykey.
• Советы по безопасности: не хранить секреты в .bashrc и подобных, исключать их через .gitignore, использовать шифрование и хранилища (1Password ссылки, отдельные файлы, приватные репо).
• Польза публикации: обучение через чужие конфиги (vim/zsh/emacs/nvim), улучшения качества жизни через алиасы/маппинги, возможность быстро делиться и переустанавливать окружение.
• Практические подходы: файл-локальные приватные настройки, employer-специфические include-файлы, документирование и чистка перед открытием, минимизация зависимостей от нестандартного софта.
• Итоговый консенсус: «делиться избирательно» — держать публичным обобщаемое и полезное, а чувствительное и слишком личное — приватным или зашифрованным.