[erlang-questions] erlexec and its environment
Bengt Kleberg
bengt.kleberg@REDACTED
Fri May 10 11:18:23 CEST 2013
Erlang/OTP is inconsistent. Setting the env with tuples, getting it with strings. You either will be consistent with OTP, or consistent setting/ getting with yourself.
IMHO name/ value pairs in OTP are mostly tuples so that is what I would like.
Bengt
Sent from Moxier Mail
(http://www.moxier.com)
----- Ursprungligt meddelande -----
Från: Serge Aleynikov <serge@REDACTED>
Till: "erlang-questions@REDACTED" <erlang-questions@REDACTED>
Skickat: 09-05-2013 1:47 em
Ämne: Re: [erlang-questions] erlexec and its environment
Actually both representations are used in parts of Erlang/OTP, e.g.:
1> os:getenv().
["DISPLAY=:0","WINDOWPATH=1", ...].
2> Env = [{"ABC", "Test"}],
3> erlang:open_port({spawn, "echo -n $ABC"}, [{env, Env}]).
4> f(X), receive {_, {data, X}} -> X end.
"Test"
But I'll mention this in the erlexec's doc.
On 5/8/2013 2:54 AM, Bengt Kleberg wrote:
> Please document which one of these is used else where in Erlang/OTP, and
> that the other is not.
>
>
> bengt
>
> On Tue, 2013-05-07 at 12:42 -0400, Serge Aleynikov wrote:
>> The master branch of erlexec now has support for both {Name, Val} and
>> "VAR=VALUE" environment options.
>>
>> On 5/7/2013 4:55 AM, Bengt Kleberg wrote:
>>> Greetings,
>>>
>>> There are some Erlang functions that have {env, [...]} argument. Ex:
>>> erlang:open_port/2.
>>>
>>> I think it would be good to have the same syntax ("a list of tuples
>>> {Name, Val}, where Name is the name of an environment variable, and Val
>>> is the value it is to have in the spawned port process." and the same
>>> semantics for exec:run_link/2's {env, [...]}.
>>>
>>>
>>> bengt
>>>
>>> On Tue, 2013-05-07 at 10:34 +0200, David Welton wrote:
>>>> Hi,
>>>>
>>>> We're doing some work to fix up a few things we perceive as
>>>> deficiencies in erlexec, and thought about asking for a community
>>>> opinion.
>>>>
>>>> Currently, this:
>>>>
>>>> exec:run_link("exec /tmp/print_env.sh", [])
>>>>
>>>> Launches the child process with no environment, which was quite a
>>>> surprise to us - the default on Unix systems is to have child
>>>> processes inherit the parent process' environment. We're hacking the
>>>> system so that it'll behave like we expect.
>>>>
>>>> When an environment is specified, we were thinking to use that to say
>>>> "ok, clear out the environment and don't inherit it":
>>>>
>>>> exec:run_link("/tmp/print_env.sh", [{env, ["VIVA=ERLANG"]}])
>>>>
>>>> So that if you really needed to pass it in, you could do:
>>>>
>>>> exec:run_link("/tmp/print_env.sh", [{env, os:getenv() ++ ["VIVA=ERLANG"]}])
>>>>
>>>> Thoughts?
>>>> --
>>>> David N. Welton
>>>>
>>>> http://www.welton.it/davidw/
>>>>
>>>> http://www.dedasys.com/
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED
http://erlang.org/mailman/listinfo/erlang-questions
More information about the erlang-questions
mailing list