Bug 49366 - Differences between system.getenv and Ant 1.8.1 <property env=""/>
Differences between system.getenv and Ant 1.8.1 <property env=""/>
Status: RESOLVED FIXED
Product: Ant
Classification: Unclassified
Component: Core
nightly
All All
: P2 normal (vote)
: ---
Assigned To: Ant Notifications List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2010-06-01 10:00 UTC by Stefan Bodewig
Modified: 2010-11-29 10:48 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Bodewig 2010-06-01 10:00:57 UTC
On Windows System.getenv returns a few environment variables that Ant's
1.8.1 would not return via <property environment=""/>.  The keys "=::" and
"=C:" seem to be always be available and sometimes tehere also is
"=ExitCode".

We will need to decide what to do with the new variables.  Documenting them
will probably be fine, Maarten[1] suggests:

 *   - There are magic environment variables maintained by Windows
 *   that start with a `=' (!) character.  These are used for
 *   Windows drive current directory (e.g. "=C:=C:\WINNT") or the
 *   exit code of the last command (e.g. "=ExitCode=0000001").

Cygwin's /usr/bin/env replaces the "=" in the keys with a "!", we'll likely
need to do something similar or else Execute#patchEnvironment is getting into
trouble.

[1] http://mail-archives.apache.org/mod_mbox/ant-dev/201005.mbox/%3C377355.14246.qm@web30801.mail.mud.yahoo.com%3E
Comment 1 Stefan Bodewig 2010-06-01 10:02:50 UTC
(In reply to comment #0)


> We will need to decide what to do with the new variables.  Documenting them
> will probably be fine, Maarten[1] suggests:
> 
>  *   - There are magic environment variables maintained by Windows
>  *   that start with a `=' (!) character.  These are used for
>  *   Windows drive current directory (e.g. "=C:=C:\WINNT") or the
>  *   exit code of the last command (e.g. "=ExitCode=0000001").
> 

After re-reading Maarten's post I see it's not his suggestion but the Javadoc
for ProcessEnvironment - would be useful on the property manual page as well,
though.
Comment 2 Maarten Coene 2010-06-01 16:12:05 UTC
Here is some more information about these environment variables:
http://blogs.msdn.com/b/oldnewthing/archive/2010/05/06/10008132.aspx

I took a quick look at the JDK ProcessBuilder code and it seems to me that these variables are passed unmodified to any process it creates.

Maaren
Comment 3 Gilles Scokart 2010-06-10 03:39:00 UTC
I got an other difference when launched from cygwin :
A PROMPT variable is not returned anymore in 1.8.2.

----
Detected OS_NAME: windows xp
Detected OS_ARCH: x86
Detected OS_VERSION: 5.1
Detected Java Version: 1.5.0_17
Detected Java Vendor: Sun Microsystems Inc.
Detected Java VM Version: 1.5.0_17-b04
Detected Java VM Name: Java HotSpot(TM) Client VM

Only in 1.8.1: PROMPT=$P$G
----

From windows on the same machine:
----
Detected OS_NAME: windows xp
Detected OS_ARCH: x86
Detected OS_VERSION: 5.1
Detected Java Version: 1.5.0_17
Detected Java Vendor: Sun Microsystems Inc.
Detected Java VM Version: 1.5.0_17-b04
Detected Java VM Name: Java HotSpot(TM) Client VM

Only in 1.8.2: =C:=C:\Documents and Settings\gscokart
Only in 1.8.2: =D:=D:\temp
Only in 1.8.2: =ExitCode=00000000
----




I tested also from cygwin using the ibm jvm 1.5 and the sun jvm 1.6 and got the same result than with the sun jvm 1.5:
----
Detected OS_NAME: windows xp
Detected OS_ARCH: x86
Detected OS_VERSION: 5.1 build 2600 service pack 2
Detected Java Version: 1.5.0
Detected Java Vendor: IBM Corporation
Detected Java VM Version: 2.3
Detected Java VM Name: IBM J9 VM

Only in 1.8.1: PROMPT=$P$G
----
Detected OS_NAME: windows xp
Detected OS_ARCH: x86
Detected OS_VERSION: 5.1
Detected Java Version: 1.6.0_12
Detected Java Vendor: Sun Microsystems Inc.
Detected Java VM Version: 11.2-b01
Detected Java VM Name: Java HotSpot(TM) Client VM

Only in 1.8.1: PROMPT=$P$G
----



My cygwin version is, and I have no PROMPT env variable.  I have PS1 and PS2 (not sure if they are linked):
---
$ uname
CYGWIN_NT-5.1
$ env | grep PROMPT

$ echo $PS1
\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$

$ echo $PS2
>
---


On Windows however I have a PROMPT variable:
---
D:\temp>echo %PROMPT%
$P$G
---
Comment 4 Dmitry A. Kuminov 2010-06-11 08:56:23 UTC
Here is the result of the ant-env.jar invocation on OS/2, as requested by  Stefan Bodewig:

---------------------------------------------------
Detected OS_NAME: os/2
Detected OS_ARCH: x86
Detected OS_VERSION: 20.45
Detected Java Version: 1.5.0_07
Detected Java Vendor: Sun Microsystems Inc.
Detected Java VM Version: 1.5.0_07-b03
Detected Java VM Name: Java HotSpot(TM) Client VM

Only in 1.8.1: BEGINLIBPATH=D:\DEV\JAVA150\JRE\BIN;
---------------------------------------------------

Note that BEGINLIBPATH is not a real environment variable to the effect that it is not listed by the 'cmd /c set' command although it can be changed using the 'cmd /c set BEGINLIBPATH=<value>' command like any other environment variable. Note also that this variable is not present in the LIBC's environ array on OS/2 (which means it's not part of the process environment at all and cannot be acessed with getenv()/setenv(), there is a special Dos* API for that). The reason why it appears in the System.getenv() map is because it is specifically added there by the "native" code (I placed "native" in quotes because JDK 1.5 for OS/2 is only available as an Odin-based port where Odin is a Win32 emulation layer similar to Wine; so this comes from its GetEnvironmentStrings() implementation AFAIR).

And there is another similar environment variable, ENDLIBPATH. As far as I remember, these two are the only tricky ones.

I hope I provided enough details, but feel free to ask if you need more.
Comment 5 Stefan Bodewig 2010-06-14 04:49:57 UTC
(In reply to comment #3)
> My cygwin version is, and I have no PROMPT env variable.  I have PS1 and PS2
> (not sure if they are linked):
> ---
> $ uname
> CYGWIN_NT-5.1
> $ env | grep PROMPT

I don't see what you get with "CYGWIN_NT-6.1-WOW64".  We probably need to document certain differences for Cygwin.  IMHO it is unlikely to cause real issues.
Comment 6 Stefan Bodewig 2010-06-14 04:59:36 UTC
(In reply to comment #4)

> Only in 1.8.1: BEGINLIBPATH=D:\DEV\JAVA150\JRE\BIN;

> Note also that this variable is not present in the LIBC's environ array on OS/2
> (which means it's not part of the process environment at all and cannot be
> acessed with getenv()/setenv(), there is a special Dos* API for that).

So it likely doesn't hurt if it is no longer there in the future.  Just something
we need to document.

> The reason why it appears in the System.getenv() map is because it is
> specifically added there by the "native" code

It is not part of getenv but of our old codebase which just invokes
cmd /c set for us.

> I hope I provided enough details, but feel free to ask if you need more.

yes you did, many thanks.
Comment 7 Stefan Bodewig 2010-06-16 07:38:24 UTC
Oliver Deakin reports no differences for z/OS.  Good news.
Comment 8 wwalsh 2010-09-23 07:48:18 UTC
In response to Bug 49969 I've run this on SUSE Linux Enterprise Server (SLES 10 SP2):

anthill@zlinuxs1:~/JDE015/ANT-ENV> java -jar ant-env.jar
Detected OS_NAME: linux
Detected OS_ARCH: s390x
Detected OS_VERSION: 2.6.16.60-0.21-default
Detected Java Version: 1.6.0
Detected Java Vendor: IBM Corporation
Detected Java VM Version: 2.4
Detected Java VM Name: IBM J9 VM

Both methods returned the same environment information


Thanks,
www
Comment 9 Stefan Bodewig 2010-11-29 10:48:53 UTC
I've added a Map-returning methode getEnvironmentVariables to Execute that is used by most classes now and helps anybody who parses for the equals signs as separator between key and value.

All known differences are now documented in svn 0