В пустом окружении исполняемые файлы не найдены, если не указан полный путь. Попробуйте это сделать с помощью execvp
.
Функция system
вызывает оболочку - в Linux с Glibc она вызывает /bin/sh
(поэтому не требуется PATH
). Оболочки определяют несколько собственных переменных в дополнение к тем, которые поступают из окружения. Вы можете увидеть, что они определяют, выполнив env -i /path/to/shell -c set
, и какие переменные они экспортируют, выполнив env -i /path/to/shell -c export
. В частности, dash и bash - две оболочки, которые вы, скорее всего, найдете как /bin/sh
в Linux - устанавливают (но не экспортируют) PATH
во "вменяемое" значение по умолчанию, если в окружении его нет. Разные оболочки устанавливают разные значения или не устанавливают их вообще.
$ env -i bash -c 'echo $PATH'
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ env -i dash -c 'echo $PATH'
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ env -i mksh -c 'echo $PATH'
/usr/bin:/bin
$ env -i ksh93 -c 'echo $PATH'
$ env -i zsh -c 'echo $PATH'
/bin:/usr/bin:/usr/ucb:/usr/local/bin
$ env -i csh -c 'echo $PATH'
PATH: Undefined variable.
$ env -i tcsh -c 'echo $PATH'
PATH: Undefined variable.
На моей машине (и на вашей, видимо), which
сам по себе является /bin/sh
скриптом. Оболочка, вызываемая system
, использует свою собственную переменную пути, чтобы найти программу which
, но не экспортирует ее. Оболочка, которая сама запускает сценарий which
, также определяет переменную PATH
для своего внутреннего использования.
Вы не можете сделать это постфактум, но вы можете загрузить согласованный набор обновленных пакетов и перейти на них позже:
apt update
apt -d upgrade
обновит индексы и загрузит все кандидаты на обновление без фактического выполнения обновления. Пока вы снова не обновите индексы (, что означает отказ от запуска apt update
и вариантов, а также отключение любых заданий, которые могут сделать это за вас, например apt-daily
), вы сможете применить обновить позже, запустив
apt upgrade
Если вы установите apt-listbugs
, вы также будете предупреждены о неисправленных критических ошибках в версиях, до которых вы собираетесь перейти, перед обновлением.
Как упомянул Жиль , похоже, тестирование Debian может оказаться более подходящим, чем нестабильным. Тестирование выполняется на несколько дней позже нестабильного, и, кроме того, пакеты переходят в режим тестирования только в том случае, если это не приводит к критической ошибке выпуска -при тестировании и поддерживает согласованность набора тестовых пакетов (, т.е. , зависимости все еще доступны и т. д. ). Однако обратите внимание, что при выполнении тестирования есть последствия для безопасности, и вы должны быть в курсе обновлений безопасности. Связанная вики-страница содержит гораздо больше деталей и рекомендаций.
И тестовый Debian, и нестабильный Debian на самом деле не являются -ориентированными на пользователя скользящими дистрибутивами; они являются плацдармом для следующего стабильного выпуска Debian.