Due to process separation, the following won't work:
script.sh:
#!/bin/sh
SOME_VAR=foobar
test.d:
import std.process;
void main()
{
system("./script.sh");
assert(environment["SOME_VAR"] == "foobar");
}
This, of course, is because the script is run in a totally separate process (AIUI). The same thing happens in Windows, too.
Is there some way to actually get the env that results from the script? I'm looking for solutions for both Posix and Windows.

On Thu, 29 Sep 2011 13:31:13 -0400, Nick Sabalausky wrote:
> Due to process separation, the following won't work:
> > script.sh:
> #!/bin/sh
> SOME_VAR=foobar
> > test.d:
> import std.process;
> void main()
> {
> system("./script.sh");
> assert(environment["SOME_VAR"] == "foobar");
> }
> > This, of course, is because the script is run in a totally separate process (AIUI). The same thing happens in Windows, too.
> > Is there some way to actually get the env that results from the script? I'm looking for solutions for both Posix and Windows.
What about "export SOME_VAR=foobar"?
Best,
Graham

On Thu, 29 Sep 2011 13:31:13 -0400, Nick Sabalausky <a@a.a> wrote:
> Due to process separation, the following won't work:
>> script.sh:
> #!/bin/sh
> SOME_VAR=foobar
>> test.d:
> import std.process;
> void main()
> {
> system("./script.sh");
> assert(environment["SOME_VAR"] == "foobar");
> }
>> This, of course, is because the script is run in a totally separate process
> (AIUI). The same thing happens in Windows, too.
>> Is there some way to actually get the env that results from the script? I'm
> looking for solutions for both Posix and Windows.
No. The way it works when you "source" a script from another script is it uses the same process to interpret the script file, which sets the environment up.
Since a D program cannot interpret shell script, all you can do is read the environment from the script (have it output the environment) and read it in:
#!/bin/sh
SOME_VAR=foobar
# note this is needed for SOME_VAR to get into the environment
export SOME_VAR
# write all environment variables to the output
env
test.d:
import std.process:
void main()
{
processEnv(system("./script.sh")); // need to write the processEnv function which processes the output from env.
}
I don't know what your real test case looks like, so I can't really comment on the approach. If it's simply loading file-defined environment variables, there are better ways (as I'm sure you're aware).
-Steve

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.v2k6axvveav7ka@localhost.localdomain...> On Thu, 29 Sep 2011 13:31:13 -0400, Nick Sabalausky <a@a.a> wrote:
>>> Due to process separation, the following won't work:
>>>> script.sh:
>> #!/bin/sh
>> SOME_VAR=foobar
>>>> test.d:
>> import std.process;
>> void main()
>> {
>> system("./script.sh");
>> assert(environment["SOME_VAR"] == "foobar");
>> }
>>>> This, of course, is because the script is run in a totally separate
>> process
>> (AIUI). The same thing happens in Windows, too.
>>>> Is there some way to actually get the env that results from the script?
>> I'm
>> looking for solutions for both Posix and Windows.
>> No. The way it works when you "source" a script from another script is it uses the same process to interpret the script file, which sets the environment up.
>
Right, that's why I wasn't surpeised about the above not working and put "Sourcing" in quotes. I was just wondering if there was some way to get the environment from the end of that process into the current process.
> Since a D program cannot interpret shell script, all you can do is read the environment from the script (have it output the environment) and read it in:
>> #!/bin/sh
> SOME_VAR=foobar
> # note this is needed for SOME_VAR to get into the environment
>> export SOME_VAR
>> # write all environment variables to the output
> env
>> test.d:
> import std.process:
> void main()
> {
> processEnv(system("./script.sh")); // need to write the processEnv
> function which processes the output from env.
> }
>
Good idea, that could work.
> I don't know what your real test case looks like, so I can't really comment on the approach. If it's simply loading file-defined environment variables, there are better ways (as I'm sure you're aware).
>
Yea, I'm not even sure what approach I'll end up taking. Hell, I'm probably over-engineering it all anyway. FWIW, the scenario is like this:
I was making a shell script for one of my open source projects to help automate doing releases. The script is supposed to connect to a file server (generally via sshfs, which is freaking awesome, btw), update some stuff, and disconnect.
I figured there was no reason not to make the script public, but also that it would make sence for various reasons to make the connect/disconnect configurable (and not included). So the way I did it was it to have the script call the optional (and user-written) serverConnect and serverDisconnect scripts. The script also needed to know the path to the specific destination in the server, so I had the serverConnect set that path as an environment var (or the user could just set the env var elsewhere, wherever/however they wanted). So my script just sources the serverConnect script:
http://www.dsource.org/projects/goldie/browser/trunk/updateServerDocs?rev=449
Then I decided to convert the script to D (partly because my script-fu isn't all that great). Obviously now the env var solution won't work anymore, at least not quite as easily, so I'm thinking about what to do.
I was about to just change it from an env var to a cmd line param, but I'm thinking now my whole connect/disconnect system (proud of it as I was) is totally backwards and over-engineered. I should just assume the computer's already connected, take the target path as a cmd line param, and let the user just wrap the whole damn thing in one "connect, run the tool, disconnect" script however they wish. That seems to make the most sense.

"Graham Fawcett" <fawcett@uwindsor.ca> wrote in message news:j62ido$1n0s$1@digitalmars.com...> On Thu, 29 Sep 2011 13:31:13 -0400, Nick Sabalausky wrote:
>>> Due to process separation, the following won't work:
>>>> script.sh:
>> #!/bin/sh
>> SOME_VAR=foobar
>>>> test.d:
>> import std.process;
>> void main()
>> {
>> system("./script.sh");
>> assert(environment["SOME_VAR"] == "foobar");
>> }
>>>> This, of course, is because the script is run in a totally separate process (AIUI). The same thing happens in Windows, too.
>>>> Is there some way to actually get the env that results from the script? I'm looking for solutions for both Posix and Windows.
>> What about "export SOME_VAR=foobar"?
>
Still doesn't work.

On Thu, 29 Sep 2011 17:02:28 -0400, Nick Sabalausky <a@a.a> wrote:
> "Graham Fawcett" <fawcett@uwindsor.ca> wrote in message
> news:j62ido$1n0s$1@digitalmars.com...>> On Thu, 29 Sep 2011 13:31:13 -0400, Nick Sabalausky wrote:
>>>>> Due to process separation, the following won't work:
>>>>>> script.sh:
>>> #!/bin/sh
>>> SOME_VAR=foobar
>>>>>> test.d:
>>> import std.process;
>>> void main()
>>> {
>>> system("./script.sh");
>>> assert(environment["SOME_VAR"] == "foobar");
>>> }
>>>>>> This, of course, is because the script is run in a totally separate
>>> process (AIUI). The same thing happens in Windows, too.
>>>>>> Is there some way to actually get the env that results from the script?
>>> I'm looking for solutions for both Posix and Windows.
>>>> What about "export SOME_VAR=foobar"?
>>>> Still doesn't work.
This only passes the environment to children started after the export is done. A child process cannot affect a parent process' environment directly. Nor can a parent affect an already-running child.
-Steve

On 2011-09-29 19:31, Nick Sabalausky wrote:
> Due to process separation, the following won't work:
>> script.sh:
> #!/bin/sh
> SOME_VAR=foobar
>> test.d:
> import std.process;
> void main()
> {
> system("./script.sh");
> assert(environment["SOME_VAR"] == "foobar");
> }
>> This, of course, is because the script is run in a totally separate process
> (AIUI). The same thing happens in Windows, too.
>> Is there some way to actually get the env that results from the script? I'm
> looking for solutions for both Posix and Windows.
Either you do it how it works in DVM or have the script write out a file that the parent process reads.
--
/Jacob Carlborg

On Fri, 30 Sep 2011 07:18:34 +0100, Jacob Carlborg <doob@me.com> wrote:
> On 2011-09-29 19:31, Nick Sabalausky wrote:
>> Due to process separation, the following won't work:
>>>> script.sh:
>> #!/bin/sh
>> SOME_VAR=foobar
>>>> test.d:
>> import std.process;
>> void main()
>> {
>> system("./script.sh");
>> assert(environment["SOME_VAR"] == "foobar");
>> }
>>>> This, of course, is because the script is run in a totally separate process
>> (AIUI). The same thing happens in Windows, too.
>>>> Is there some way to actually get the env that results from the script? I'm
>> looking for solutions for both Posix and Windows.
>> Either you do it how it works in DVM or have the script write out a file that the parent process reads.
On windows you can use:
set>file.txt
this will output the whole environment into file.txt in the form:
label=value
So, add that line to the end of script.cmd|bat|sh and then have the D program read it .. using std.getopt perhaps?
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/