This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 181386 - setting env variable does not take effect while running program
Summary: setting env variable does not take effect while running program
Status: VERIFIED FIXED
Alias: None
Product: cnd
Classification: Unclassified
Component: execution (show other bugs)
Version: 6.x
Hardware: Sun Solaris
: P2 normal (vote)
Assignee: Vladimir Voskresensky
URL:
Keywords:
: 181387 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-03-01 19:43 UTC by Chihin Ko
Modified: 2010-03-18 16:36 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chihin Ko 2010-03-01 19:43:44 UTC
Step to reproduce :

- open Quote sample project 
- insert following c++ code into function main

    if (getenv("env_debug") != NULL)
        cout << "env_debug = " << getenv("env_debug") << endl;
    else
        cout << "Fail !" << endl;

- bring up Properties/Run panel, set env_debug=1 in Environment
- compile and run it
- expecting "env_debug = 1" in output terminal, but got "Fail !"

This a regression compared to NB65, which sunstuio12.1 base on, sunstudio12.1 works fine.
Comment 1 Chihin Ko 2010-03-01 19:58:05 UTC
This also cause problem for debugger gui, IZ 181387 filed against it.
This needs to be fixed to aten SSX.
Comment 2 Chihin Ko 2010-03-03 16:31:18 UTC
aten sunstudio SSX needs the fixes. aten sunstudio SSX is base on 6.8.

Another scenario found is that if I turn off profiler before running program, then the env var will be propagated to program, I don't know if profiler is related to this, or it's a timing issue.
Comment 3 Vladimir Voskresensky 2010-03-05 03:14:02 UTC
Bug is 100% reproducible in trunk in both modes: with and w/o profiler.
It's an issue in native execution.
simple program shows that all defined env variables are capitalized by the execution system.
#include <stdlib.h>
#include <iostream>
using namespace std;
extern char** environ;
int main(int argc, char** argv) {
    for (int i = 0; environ[i] != NULL; i++) {
        string env(environ[i]);
        cout << env << endl;
    }
    return (EXIT_SUCCESS);
}
Comment 4 Vladimir Voskresensky 2010-03-05 03:30:46 UTC
fixed:
http://hg.netbeans.org/cnd-main?cmd=changeset;node=bd7f5174b5af
Comment 5 Vladimir Voskresensky 2010-03-05 03:38:15 UTC
*** Bug 181387 has been marked as a duplicate of this bug. ***
Comment 6 Andrew Krasny 2010-03-05 04:10:12 UTC
Patch reviewed. I agree with the fix. It is safe and correct.
Thanks!
=Andrew
Comment 7 rbalada 2010-03-08 06:48:26 UTC
Can you verify the fix in trunk so it could be included in 6.8 patch?
Comment 8 rbalada 2010-03-09 06:27:10 UTC
Please redo the fix to avoid issue in Turkish locale. Generally when you want to effectively neutralize case, use <code>toUppercase(java.util.Locale.ENGLISH)</code> instead of just simple <code>toUppercase()</code>

For more details see article at http://java.sys-con.com/node/46241
Comment 9 Vladimir Voskresensky 2010-03-09 07:02:38 UTC
I have moved toUppercase from incorrect place into correct place, but I don't want to change other logic.
Is it possible for patch push as is? 
And in trunk I can try with your proposed approach, but it would need more testing.
Comment 10 rbalada 2010-03-10 08:24:20 UTC
Folks, it's not a change of logic, it's a fix of the broken logic to behave correctly.

In case user is running in Turkish locale and some of his/her environment variables contains lowercase "i" (i.e. "index" or "id"), then it will be ignored because it will not pass pattern matching and will fall to the continue statement in the loop. 
The code uses English alphabet in pattern definition "[A-Z0-9_]" and then tries to use this English-only pattern for comparison with string, which has been upper-cased according to user's locale. 

The issue must not be related just to Turkish locale. It's generally affecting any character set, which does not include complete English alphabet (not all character sets are based on alphabet) and correct English upper-lower case mapping. Enforcing the English character set specification makes it aligned with already introduced enforced English-only pattern matching.

Bit of stupid humor:

Evaluate following Java code 
String CAXAP = "3".toLowerCase().equals("z")?"just":"kidding";

Is sachar equal to "just" or "kidding" and how it could change in certain character sets? Not a real code, just a base for thinking through possibilities.

Put it into enforced English-only comparison, if your really want to fix the issue. Without locale spec it's not ready for porting to fixes branch.
Comment 11 Vladimir Voskresensky 2010-03-10 09:35:09 UTC
thank for the detailed explanations :-)
http://hg.netbeans.org/cnd-main?cmd=changeset;node=fbf522f7484e
Comment 12 Quality Engineering 2010-03-10 23:16:22 UTC
Integrated into 'main-golden', will be available in build *201003110200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/fbf522f7484e
User: Vladimir Voskresensky <vv159170@netbeans.org>
Log: extra fix for #181386 -  setting env variable does not take effect while running program
Comment 13 Alexander Pepin 2010-03-11 08:19:50 UTC
verified in build 201003110200
Comment 15 Alexander Pepin 2010-03-18 16:36:56 UTC
verified in patch2 candidate 20100318