Thanks for the replies. A few initial thoughts.
> Charlie and I were talking about this email yesterday afternoon and
> we were hoping to not have those system-dependent callouts/heuristics in here.
Understand
> The other solution we thought of was passing an env string in as
> a system property (then jruby.bat and jruby.sh would need to be
> updated to provide this). This also should be more friendly to
> embedders who do not want to external call to get env (much less let
> anyone see it).
Fine in principle. Messy in practice?
On the linux side,.
My first thought was a simple -DALL_ENV_VARS=`env` and parse the (big) string in
java. But this would NOT be ok.
The string does not include the newlines from the env command, they are
converted to spaces. A concatenated ALL_ENV_VARS cannot be parsed unabiguously
because of possible embedded spaces and equals in the values.
So another option is to parse the "env" output into individual variables
(-DENVVAR1=val1 -DENVVAR2=val2) in the shell file. Not being a linux guru, I
would need some time to think about this...
Another option is common with the windows environment...
In windows...,
IMO, a simple windows batch file would not even be able to do
-DALL_ENV_VARS=one_big_long_set_of_env_vars
Also, IMO, a simple windows batch file would NOT be able to
parse the output of the "set" command into -DENVVAR1=val1 -DENVVAR2=val2.
So the only thing I can think of is to dump the "set" outut to a ~/.jruby_env
file in the users home directory and then pass the filename into jruby for java
parsing. That *would* work but obviously there are issues writing files to home
directories.
(Please let me know if you think my assumptions are wrong above.)
Maybe the most reliable solution for windows *and* linux is via the the
~/.jruby_env file because it minimises dependencies on available shell commands.
Perhaps whatever solution could be pluggable, with a default implementation of
either the ~/.jruby_env solution or the
Runtime.getRuntime().exec()/System.getenv() solution.
But implementations could be plugged in for example for the embedders...
-DJRUBY_ENV_METHOD=com.embedded.app.Runtime.getRuntime().getEnvHash()
or for people who want to link to ant.jar
-DJRUBY_ENV_METHOD=org.apache.tools.ant.taskdefs.Execute.getProcEnvironment()
the default implementation would be the equivalent of
-DJRUBY_ENV_METHOD=org.jruby.env.EnvGetter.getEnvHashFromJrubyEnvFile()
or
-DJRUBY_ENV_METHOD=org.jruby.env.EnvGetter.getEnvHashFromOS()
>
> No solution sounds wonderful. Is the above solution better or
> worse than the original proprosed solutions?
>
> -Tom
Charles O Nutter wrote:
I agree with the reflective bit; Tom and I discussed this yesterday as
an ugly but warranted solution for 1.5ers who have access to the new
getenv stuff.
Ok
I also agree that system property namespace and ENV namespace should
be kept separate.
Ok
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jruby-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jruby-devel
