Почему нет ограничения скорости с помощью тонкой работы с ruby?
Если вы хотите, чтобы путь изменялся только на время действия команды.
Затем вам нужно устанавливать его для каждого вызова команды.
Идеально подходит для псевдонима:
alias myprog='PATH="$PATH":$(readlink -f prog) myprog'
Использовать как:
$ myprog && myprog
YES
YES
Конечно, функция с таким же именем не будет работать:
$ myprog(){ PATH="$PATH":$(readlink -f prog) myprog; } ### DO NOT USE !!
Я просто интересно, действительно ли вам это нужно. Если вы создаете сценарий внутри ~ / bin (после входа в систему с созданным каталогом ~ / bin ), переменная PATH уже будет включать этот путь, а скрипт будет выполнен, просто назвав его:
$ cd ~/bin ### create the dir if it didn't exist.
$ echo "echo YES" >> myprog
$ chmod u+x myprog
$ cd ~
$ myprog ### remember to reload ~/.bashrc (re-login).
YES
Я думаю, что отследил это. Возможно, это ошибка в trickle, возникшая в результате ползучего фичуризма в библиотечном вызове socket().
Код trickle переопределяет socket(), как вы знаете. В верхней части его переопределения в файле trickle-overload.c есть проверка, включающая type == SOCK_STREAM, так что только соединения типа SOCK_STREAM имеют право на обработку.
Код ruby открывает сокет с type = SOCK_STREAM | SOCK_CLOEXEC. SOCK_CLOEXEC - это расширение Linux (начиная с версии 2.6.27), которое позволяет избежать использования последующего вызова fcntl для установки флага close-on-exec.
К сожалению, SOCK_STREAM - это не то же самое, что SOCK_STREAM | SOCK_CLOEXEC, поэтому обработка trickle не будет происходить, пока его код не будет исправлен, чтобы разрешить расширения, которые теперь разрешены в поле socket type.
Я не знаю никакого обходного пути, кроме как перекомпилировать trickle для вашей системы с измененным сравнением типов сокетов.
(Я отправил сообщение об ошибке в Debian Bugs, поскольку это моя предпочтительная платформа.)
.