This looks great, Tim. I had to hack a bit recently to get some basic ENV stuff working (testing dispatch.rb as a CGI) so this will be a welcome addition.On 3/29/06,
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Tryjruby -e "puts ENV['JAVA_HOME']"jruby -e "puts ENV['JRUBY_HOME']"etcorjruby -e "puts
I have your old patch in my tree right now. I will reapply this version.
Thanks for working on this.
-Tom
On Wed, 29 Mar 2006, Tim Azzopardi defenestrated me:
> Congratulations on the 0.8.3 release. Outstanding.
>
> Hopefully you'll like this patch a little better as there are no changes to
Try
jruby -e "puts ENV['JAVA_HOME']"
jruby -e "puts ENV['JRUBY_HOME']"
etc
or
jruby -e "puts ENV_JAVA['java.home']"
jruby -e "puts ENV_JAVA['java.version']"
etc
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
th
Congratulations on the 0.8.3 release. Outstanding.
Hopefully you'll like this patch a little better as there are no changes to
jruby.bat or jruby.sh.
First, if the Java 5 Systen.getenv is available, then that is used to get the
environment. If not then the Runtime.getRuntime() technique is us
Or even just checking System property java.version.
-Tom
On Fri, 17 Feb 2006, Charles O Nutter defenestrated me:
> The getenv from 1.4- is, as you mention, deprecated. That won't
> prevent it from being called. However the 1.5 version has a new
> signature, so searching for it using reflection
The getenv from 1.4- is, as you mention, deprecated. That won't
prevent it from being called. However the 1.5 version has a new
signature, so searching for it using reflection and catching NSME
should be fine.
1.4- version: String getenv(String)
1.5 version: Map getenv()
On 2/17/06, Galarneau, Ne
A comment on this implementation:
My impression is that Java 1.4.2 won't throw NoSuchMethodException
as getenv in that version is deprecated, not missing.
This would mean that you could call getenv() directly instead of
reflectively as long as it was only called on Java 5.
Neil
+protected
I will be taking a look at this soon (though may be weekend as
real life is interfering :))...
-Tom
On Wed, 15 Feb 2006, Tim Azzopardi defenestrated me:
> If anybody is interested...
>
> The attached patch is a first stab at a pluggable ENV implementation with
> reasonable default implementa
If anybody is interested...
The attached patch is a first stab at a pluggable ENV implementation with
reasonable default implementations.
The Java5 System.getenv method is tried first by reflection and then if its
unavailable it falls through to the "set/env > ~/.jrubyenv" method. (Only
jrub
Neil,
This is a very good point. I think this means that the Runtime.exec() approach
is a last resort solution compared to the others.
Tim
Galarneau, Neil wrote:
It seems to me that the Runtime.exec() approach is not guaranteed to
find the actual value of the environment variable, only some
in the doc.
Neil
> Message: 2
> Date: Sat, 4 Feb 2006 09:35:25 -0600
> From: Charles O Nutter <[EMAIL PROTECTED]>
> To: [email protected]
> Subject: Re: [Jruby-devel] Suggestion for an ENV implementation
> Reply-To: [email protected]
>
> I
Another thought on the .jrubyenv thing is to write it into a tmp file
instead of the users home directory.
-Tom
On Tue, 07 Feb 2006, Charles O Nutter defenestrated me:
> It's not a high priority on my list right now, and I know Tom is also
> heavy into getting RoR working...if you can get some
It's not a high priority on my list right now, and I know Tom is also
heavy into getting RoR working...if you can get some preliminaries
done it would certainly be helpful to move it along. We'll get to it
eventually, of course, but there's only so many hours in the day :)
On 2/7/06, [EMAIL PROTEC
Ok, I'll give it a go unless you want to look at it(?) Probably will not be able
to look at it before at least the weekend though.
Quoting Charles O Nutter <[EMAIL PROTECTED]>:
> I think you're spot on with your concerns about the -D env string
> passed in via the startup script; at a minimum we
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 comm
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 proper
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.
I also agree that system property namespace and ENV namespace should
be kept separate.
Tom's reply covered the rest of our discussion.
- Charl
Charlie and I were talking about this email yesterday afternoon and
we were hoping to not have those system-dependent callouts/heuristics in here.
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 th
On Thursday 02 February 2006 05:36 pm, Tim Azzopardi wrote:
> While testing the AntBuilder stuff, I found that ENV['RUBY_HOME'] is nil in
> jruby but works in cruby. (There is only one environment variable that
> works in jruby which is HOME because of a specific bit of code.)
>
> I had a go at fix
While testing the AntBuilder stuff, I found that ENV['RUBY_HOME'] is nil in
jruby but works in cruby. (There is only one environment variable that works in
jruby which is HOME because of a specific bit of code.)
I had a go at fixing this initially using System.getenv() which returned a
hashmap
20 matches
Mail list logo
