NULL.
envp — указатель массива символьных строк переменных системного окружения (environment). Последний элемент массива envp обязан быть NULL. Каждый элемент массива является строкой (char*) вида: variable = value. Если само значение указателя envp равно NULL, то дочерний процесс полностью наследует копию окружения родителя. (Окружение процесса — всегда «копия», поэтому любые изменения, внесенные в окружение дочерним процессом, никак не отражаются на окружении его родителя.)
Если дочерний процесс является скриптом интерпретатора (флаг SPAWN_CHECK_SCRIPT), то первая строка текста скрипта должна начинаться с #! , за которыми должны следовать путь и аргументы того интерпретатора, который будет использоваться для интерпретации этого скрипта. К скрипту не применяется установленный в системе интерпретатор по умолчанию (как это происходит при вызове его по имени из командной строки).
Правила наследования (и ненаследования) параметров дочернего процесса от родителя (RID, RGID и других атрибутов) жестко регламентированы, достаточно сложны (в зависимости от флагов) и могут быть уточнены в технической документации QNX. Отметим, что безусловно наследуются такие параметры, как: а) приоритет и дисциплина диспетчеризации; б) рабочий и корневой каталоги файловой системы. Не наследуются: установки таймеров процесса tms_utime, tms_stime, tms_cutime и tms_cstime, значение взведенного сигнала SIGALRM (это значение сбрасывается в ноль), файловые блокировки, блокировки и отображения памяти (shared memory), установленные родителем.
При успешном завершении вызов функции возвращает PID порожденного процесса. При неудаче возвращается -1 и errno устанавливается:
• E2BIG — количество байт, заданное в списке аргументов или переменных окружения и превышающее ARG_MAX;
• EACCESS — нет права поиска в каталогах префикса имени файла, или для файла не установлены права на выполнение, или файловая система по указанному пути была смонтирована с флагом ST_NOEXEC;
• EAGAIN — недостаточно системных ресурсов для порождения процесса;
• ERADF — недопустим хотя бы один из файловых дескрипторов в массиве fd_map;
• EFAULT — недопустима одна из буферных областей, указанных в вызове;
• ELOOP — слишком глубокий уровень символических ссылок к файлу или глубина префиксов (каталогов) в полном пути к файлу;
• EMFILE — недостаточно ресурсов для отображения файловых дескрипторов в дочерний процесс;
• ENAMETOOLONG — длина полного пути превышает PATH_MAX или длина компонента имени файла и пути превышает NAME_MAX;
• ENOENT — файл нулевой длины или несуществующий префиксный компонент в полном пути;
• ENOEXEC — файл, указанный как программа, имеет ошибочный для исполняемого файла формат;
• ENOMEM — в системе недостаточно свободной памяти для порождения процесса;
• ENOSYS — файловая система, специфицированная полным путевым именем файла, не предназначена для выполнения spawn();
• ENOTDIR — префиксные компоненты пути исполняемого файла не являются каталогами;
Даже из этого очень краткого обзора вызова spawn() становятся очевидными некоторые вещи:
• Эта форма универсальна (самодостаточна), она позволяет обеспечить весь спектр разнообразных форм порождения нового процесса
• Она же и самая громоздкая форма, тяжеловесная для практического кодирования, поэтому в реальных текстах в большинстве случаев вы вместо нее встретите ее конкретизации: spawnl() , spawnle(), spawnlp(), spawnlpe(), spawnp() , spawnv(), spawnve(), spawnvp(), spawnvpe (). Все эти формы достаточно полно описаны в [1]. Функционально они эквивалентны spawn(), поэтому мы не станем на них детально останавливаться.
• Хотя вызов spawn() и упоминается в описаниях как POSIX-совместимый, в QNX он существенно расширен и модифицирован и поэтому в лучшем случае может квалифицироваться как «выполненный по мотивам» POSIX.
В качестве примера приведем использованную в [4] (глава Д. Алексеева «Утилита on») форму вызова для запуска программы (с именем, заданным в строке command) на удаленном узле node (например, /net/xxx) сети QNET (как вы понимаете, это совершенно уникальная возможность QNX, говорить о которой в рамках POSIX-совместимости просто бессмысленно):
int main() {
char* command = '...', *node = '...';
// параметры запуска не используются
char* const argv[] = { NULL };
struct inheritance inh;
inh.flags = 0;
// флаг удаленного запуска
inh.flags |= SPAWN_SETND;
// дескриптор хоста
inh.nd = netmgr_strtond(node, NULL);
pid_t pid = spawnp(command, 0, NULL, &inh, argv, NULL);
...
}
Использованная здесь форма spawnp() наиболее близка к базовой spawn() и отличается лишь тем, что для поиска файла программы используется переменная системного окружения PATH.
Приведем характерный пример вызова группы exec*():
int execl(const char* path, const char* arg0, const char* arg1, ...
const char* argn, NULL);
где path — путевое имя исполняемого файла; arg0, …, argn — символьные строки, доступные процессу как список аргументов. Список аргументов должен завершаться значением NULL. Аргумент arg0 должен быть именем файла, ассоциированного с запускаемым процессом.
Устоявшаяся терминология «запускаемый процесс» относительно exec*() явно неудачна и лишь вводит в заблуждение. Здесь гораздо уместнее говорить о замещении выполнявшегося до этой точки кода новым, выполнение которого начинается с точки входа главного потока замещающего процесса.
