场景
当我使用ProcessBuilder
执行一系列命令时,我注意到我当前无法设置环境变量,以使它在执行一组命令后仍保持“已知”状态。
问题
如何在export TASKDDATA=/var/taskd
文件中重新创建.jar
命令的效果*?
尝试0
ProcessBuilder environment variable in 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 how to get binary output from command中编写的解决方案。但是,这不能保存第二个命令需要再次设置它的第二个任务的任务变量。但是,使用导出命令时,不需要再次设置环境变量。具体来说,当Java代码完成并且用户想要输入需要环境变量的任何其他命令时,这种区别就会显现出来。在这种情况下,用户需要先再次键入导出命令。
尝试2
打开新的外壳程序以使用sudo -s
获取root特权时,会发生另外的差异。在.jar
文件中设置环境不仅需要为每个单独的命令再次设置环境,而且还不会将环境变量通过root特权传递给新的shell。例如,执行以下命令:
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
文件外设置的,因此不在问题范围内。
注释2
我了解不宜将.jar
命令用作由processbuilder执行的命令,就像export
命令一样。
*这就是为什么问题集中在再现设置环境变量的“长期/持久”效果/可用性,而不是“如何执行导出命令”。
答案 0 :(得分:1)
当我执行该解决方案的.jar并检查执行后是否仍设置了环境变量$ u时,我发现不是。
这是预期的行为。一些操作系统支持全局“环境”变量的概念。但不是UNIX。在UNIX之类的操作系统中,每个进程都有自己的环境var私有副本。一个进程不能修改另一个进程的环境。这也是为什么更改进程中的当前工作目录不会更改其父进程的cwd的原因。每个进程都有自己的cwd。
解决此限制的常用方法是让子进程将var = val对写入stdout,然后父shell评估该输出以在其环境中设置var。为了说明起见,假设命令是以下名为 myscript.sh 的外壳脚本,而不是Java程序:
#!/bin/sh
echo VAR_A=val_a
echo VAR_B=val_b
然后父级外壳执行
export $(./myscript.sh)