I think you're spot on with your concerns about the -D env string passed in via the startup script; at a minimum we'd have to do a little preprocessing in *nix and you're right about it likely being difficult in Windows, though I think by using %% variables you can cram a lot more into a given command. Still, it's problematic.
I was thinking about the .jruby_env-file solution too. It's also not great, as it means the startup script has to be able to modify a file in some home dir, and the executing JRuby program also has to read that file. We're also faced with the issue of cleaning up after ourselves, since I for one really hate programs that leave MORE dotfiles lying around. We don't have a great option. I think perhaps our best choice is what you suggest: implement all the alternatives, choose the least-intrusive version by default, and allow users /embedders to specify an alternative. This also fits in somewhat with plans to make all of JRuby a bit more pluggable. I think we should just quickly mock up all the alternatives and see what works and what doesn't. They're not any of them very difficult to implement. - Charlie On 2/5/06, Tim Azzopardi <[EMAIL PROTECTED]> wrote: > 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 > -- Charles Oliver Nutter @ headius.blogspot.com JRuby Developer @ jruby.sourceforge.net Application Architect @ www.ventera.com ------------------------------------------------------- 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&kid3432&bid#0486&dat1642 _______________________________________________ Jruby-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jruby-devel
