Репликация команды `export` в банке для установки переменной среды

Сценарий

Выполняя серию команд с использованием ProcessBuilder, я заметил, что в настоящее время я не могу установить переменную среды так, чтобы она оставалась «известной» после выполнения набора команд.

Вопрос

Как воссоздать эффекты* команды export TASKDDATA=/var/taskd в файле .jar?

Попытка 0

Переменная среды ProcessBuilder в java Предоставляет способ установить переменную среды для каждой конкретной команды, но когда я выполняю .jar этого решения и проверяю, установлена ​​ли переменная среды $u после выполнения, я обнаруживаю, что это не так. В то время как $TASKDDATA остается установленным после выполнения. Проиллюстрировать:

a@DESKTOP-desktopName:/mnt/e$ echo $TASKDDATA

a@DESKTOP-desktopName:/mnt/e$ TASKDDATA=/var/taskd
a@DESKTOP-desktopName:/mnt/e$ echo $TASKDDATA
/var/taskd
a@DESKTOP-desktopName:/mnt/e$ sudo java -jar autoInstallTaskwarrior.jar
[sudo] password for a:
Process ended with rc=0

Standard Output:

util/


Standard Error:


a@DESKTOP-desktopName:/mnt/e$ echo $TASKDDATA
/var/taskd
a@DESKTOP-desktopName:/mnt/e$ echo $u

Попытка 1

Для одной команды переменная среды может использовать решение, которое я написал: Java ProcessBuilder, как получить двоичный вывод из команды. Однако это не сохраняет переменную задачи для второй команды, в которой ее необходимо установить снова. Однако при использовании команды экспорта переменную среды не требуется устанавливать повторно. В частности, эта разница становится очевидной, когда код Java завершен, и пользователь хочет ввести любые дополнительные команды, для которых требуется переменная среды. В этом случае пользователю необходимо сначала снова ввести команду экспорта.

Попытка 2

Дополнительная разница возникает, когда открывается новая оболочка для получения привилегий root с помощью sudo -s. Мало того, что установка среды в файле .jar требует повторной установки для каждой отдельной команды, но, кроме того, переменная среды не передается новой оболочке с привилегиями root. Например, выполнение следующих команд:

commandLines[53] = new String[4];
commandLines[53][0] = "sudo";
commandLines[53][1] = "-s";
commandLines[53][2] = "taskdctl"; 
commandLines[53][3] = "start";
commands[53].setCommandLines(commandLines[53]);
commands[53].setEnvVarContent("/var/taskd");
commands[53].setEnvVarName("TASKDDATA");
commands[53].setWorkingPath("/usr/share/taskd/pki");

commandLines[54] = new String[5];
commandLines[54][0] = "sudo";
commandLines[54][1] = "-s";
commandLines[54][2] = "task"; 
commandLines[54][3] = "sync";
commandLines[54][4] = "init";
commands[54].setCommandLines(commandLines[54]);
commands[54].setEnvVarContent("/var/taskd");
commands[54].setEnvVarName("TASKDDATA");
commands[54].setWorkingPath("/usr/share/taskd/pki");

возвращает:

53RUNNINGCOMMAND=sudo -s taskdctl start
The TASKDDATA variable must be set.

54RUNNINGCOMMAND=sudo -s task sync
Could not connect to 0.0.0.0 53589
Sync failed.  Could not connect to the Taskserver.
Syncing with 0.0.0.0:53589

Примечание 1

Установка переменной среды $TASKDDATA=/var/taskd перед выполнением .jar с помощью: TASKDDATA=/var/taskd sudo java -jar autoInstallTaskwarrior.jar не гарантирует, что переменная среды $TASKDDATA останется доступной после выполнения файла .jar. Кроме того, это выходит за рамки вопроса, поскольку оно установлено не в файле .jar, а вне файла .jar.

Примечание 2

Я понял, что нецелесообразно использовать команду export в качестве команды, выполняемой построителем процессов, как и команду cd.

* Вот почему вопрос сосредоточен на воспроизведении «долговременного/длительного» эффекта/доступности установки переменной среды, а не на том, «как выполнить команду экспорта».


command-line java environment-variables processbuilder
person a.t.    schedule 16.04.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

когда я запускаю .jar этого решения и проверяю, установлена ​​ли переменная среды $u после выполнения, я обнаруживаю, что это не так.

Это ожидаемое поведение. Некоторые операционные системы поддерживают концепцию глобальных переменных «среды». Но не ЮНИКС. В UNIX, как и в операционных системах, каждый процесс имеет свою собственную копию переменных среды. Процесс не может изменять среду другого процесса. По этой же причине изменение текущего рабочего каталога в процессе не меняет cwd его родительского процесса. У каждого процесса есть свой cwd.

Обычный способ обойти это ограничение состоит в том, что дочерний процесс записывает пары var=val в стандартный вывод, а затем родительская оболочка оценивает этот вывод, чтобы установить переменные в своей среде. Для иллюстрации предположим, что команда представляет собой следующий сценарий оболочки с именем myscript.sh, а не программу Java:

#!/bin/sh
echo VAR_A=val_a
echo VAR_B=val_b

Затем родительская оболочка делает

export $(./myscript.sh)
person Kurtis Rader    schedule 17.04.2019
comment
Спасибо за ваше объяснение того, почему это ожидаемое поведение. В вашем ответе я упустил, как это можно сделать из файла .jar. Должен ли я сделать вывод из вашего ответа, что: 0. Невозможно использовать только один файл .jar? 1. Возможно, но это мое самое близкое приближение (проблема XY решена, но не из файла .jar)? 2. Вы имели в виду-, но я неправильно понял, как ваше решение работает из файла .jar. Я попытаюсь запустить export $(./myscript.sh) как команду из файла .jar, чтобы проверить вашу реализацию. Предполагая, что это то, что вы имели в виду. - person a.t.; 23.04.2019
comment
Реализация, которую я считал предназначенной, дала результат: 56RUNNINGCOMMAND=export $(./myscript.sh) java.io.IOException: Cannot run program "export" (in directory "/mnt/e/somefolder"): error=2, No such file or directory. (Сначала я запустил chmod +x myscript.sh и убедился, что myscript.sh находится в /mnt/e/somefolder.) Таким образом, export рассматривается как программа, а не как синтаксис оболочки. Поэтому я в настоящее время не понимаю, как ваш ответ реализован в файле .jar. Любая разработка будет принята с благодарностью! - person a.t.; 23.04.2019
comment
@в. export это не программа. Это встроенная команда оболочки. Ваша программа jar не может изменить среду родительской оболочки без сотрудничества с этой оболочкой. Решение состоит в том, что ваша программа .jar записывает пары var=value в свой поток stdout, а родительская оболочка экспортирует их в свою среду. Мой пример myscript.sh был лишь тривиальным примером того, как это сделать. Совершенно не имеет значения, запускается ли программа в файле .jar, в сценарии оболочки или в программе, написанной на каком-то другом языке. - person Kurtis Rader; 23.04.2019