Хуки в шелле

ничего не понял. Что происходит и почему. Чем это отличается от альясов, функций и своих скриптов?

То есть это автоматизация сценария, при котором мы бы зашли в директорию и вручную сделали в ней . ./env.rc? Для отмены действия можно запустить дочерний процесс, в нём пошалить и потом его завершить.

Идея вполне здравая, но роль хуков не раскрыта. Кажется, было бы лучше, если действие было настолько простым, что сложная автоматизация не требовалась бы.

Я пока чаще делаю так:

% envrun go test

envrun задаёт переменные окружения и запускает свои аргументы.

зашли в директорию и сделали в ней . ./env.rc?

да, причём, хуки персистентные, в контексте пользователя, т.е. не исчезают, если процесс с шеллом завершается

есть такое: https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/dotenv

не пользуюсь, мешает, имею отдельный алиас для этого

direnv с интеграцией в юзаемый шелл?

~ ❯ which python                                                               
~ ❯ ls -d /tmp/.venv                                                          
drwxr-xr-x@ 7 andrey  wheel   224B 29 сент. 14:15:37 2025 /tmp/.venv
~ ❯ cd /tmp/
/tmp ❯ which python                                                            
/private/tmp/.venv/bin/python

А не проще обустроить отдельные сессии в screen/tmux? Там ещё и баш_хистори может быть своя.

хуки в шелле - это скрипты, выполняемые, например, при переходе в или покидании рабочей директории.

В ~/.bashrc

export PROMPT_COMMAND='
    path=/path/to/dir
    [[ $PWD == $path ]] &&
        > test_file
    [[ $OLDPWD == $path ]] &&
        rm $path/test_file
'

УМВР.

Чем это отличается от альясов, функций и своих скриптов?

Был тут один… Ему, да и ТС-у тоже, надо напихать в панамку за такие идеи )))

А при чём тут какой-то gvm? Я про фича Шелла говорю. Вот, например, в баше есть ассоциативные массивы, но это же не значит, что их нужно во все скрипты пихать. Не нравится - не используй.

А при чём тут какой-то gvm?

ну, примерно, при том, что там реализовано, примерно, как ты метишь.

Как это будет работать, я тебе уже показал ссылкой на их гитхаб.

Аналогично с переписыванием приглашения - попробуй для гита выводить имя текущей ветки и маркер незакоммиченных изменений. Поплюйся на тормоза и выключи. И идею свою отложи подальше - вот мой тебе совет.

Нет. Там какой-то чел скачивает что-то из инета я и жалуется, что система себя не так ведёт.

Я со screen такой способ уже давно использую на удаленных серверах.

А не проще обустроить отдельные сессии в screen/tmux? Там ещё и баш_хистори может быть своя. legolegs

Ну надо же, не все лоровцы сейкины на всю голову, хоть кто то по людски живёт! :) Два чая legolegs-у, да с коньячком!

Нет

seiken-а ответ

$ cd ~ # а оно уже деактивировало venv автоматом.

$ cd - # а теперь venv активирован.

fish с VirtualFish и Auto-activation плагином такое умеет:

 ~ > which python                                                        ✔ │ pi@rpi-5 │ 15:25:47
/usr/bin/python

 ~ > cd Work/                                                            ✔ │ pi@rpi-5 │ 15:25:57
 ~/Work > which python                          ✔ │ pi@rpi-5 │ 🐍 3.11.2 (InfoScreen) │ 15:26:02
/home/pi/.virtualenvs/InfoScreen/bin/python

 ~/Work > cd ..                                 ✔ │ pi@rpi-5 │ 🐍 3.11.2 (InfoScreen) │ 15:26:03
 ~ > which python                                                        ✔ │ pi@rpi-5 │ 15:26:05
/usr/bin/python

 ~ >                                                                     ✔ │ pi@rpi-5 │ 15:26:07

Второй юз-кейс - менять строку промпта в зависимости от директории.

На что менять ? В современных интерактивных шеллах она давно уже искаропки сама меняется

Само по себе tmux/screen - та ещё дрочильня. Но идея переместить хуки в сторону терминального приложения - здравая.

https://github.com/direnv/direnv

Переменные окружения - слишком ограниченно. В идеале надо уметь выполнять любой код.

Всё, что кроме промпта, делает только хуже. venv неспроста явно активируется, под ним можно уйти в другой каталог, и там запустить к примеру модуль существующий в венве.

Существует несколько реализаций: https://github.com/direnv/direnv/#related-projects

подозреваю, что это способ создать геморрой. когда ты забудешь про эти неявные вызовы где-то, а они отработают. или, ещё хуже, на чужом сервере ты это установишь, а потом другой юзер зайдёт и поймает неслабые галюны от твоих настроек. любые такие вещи лучше вызывать явно, во избежание.

твоя идея уже давно реализована во всех вменяемых оболочках. кроме баша

пользователь переходит в определеный каталог и у него выполняется патч бармина

тоже подумала об этом. но даже безобидного «cd ..» хватит для форменного издевательства над юзером.

ну да, я пользуюсь таким, zsh-autoenv. Чтобы активировать venv в нужных мне проектах, устанавливать нужную JAVA_HOME и т.п.

Так как я пользуюсь этим в git-репах с worktree, которые удаляю после мержа веток, то проблем с «поставил хук, забыл о нём, через месяц вернулся туда же и получил неожиданные результаты» не возникает.

У меня при переходе показывается листинг директории - первые двадцать файлов и надпись и сколько ещё там файлов. Типа так:

$ cd books
A_Practical_Introduction_to_PSL.pdf
ARM System-on-Chip Architecture.pdf
A Scheme Syntax-Rules Primer.pdf
 ... 368 lines more ... 
$ 

Но это для всех папок. А для конкретных - запуск nix-shell при входе в папку проекта.

Да, хорошая идея, тоже думал про это. Наверняка такое придумали уже.

Твоя идея предполагает отмену. А как ты отменишь результат выполнения любого кода? Непонятно. В принципе можно сделать так - выполняемый хук распечатывает пары name=value, которые добавляются в env и убираются при выходе из директории.

К примеру файл .env может быть либо исполняемым и тогда он исполняется и должен распечатать набор name=env. Либо не исполняемым и тогда он должен из себя представлять набор name=env.

Правда непонятно, как вообще отслеживать это всё для данной сессии shell-а, если делать это в виде внешнего инструмента, интегрируемого в shell через какой-нибудь precmd…

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

В случае Python venv я нахожу это довольно полезным, особенно если используется разнообразный софт не из дистрибутива, требующий отсутствующих модулей или версий модулей, отличающихся от системных

Тогда как раз наоборот, заходишь в директорию проекта через полгода, уже и забыл что там настраивал, а правильный venv автомагически активировался и все работает как надо

Ну и, конечно, имя активного venv’a должно отображаться в промпте