Closed Bug 120866 Opened 23 years ago Closed 22 years ago

AutoConfig: Missing support in the autoconfig JS context to access PR_GetEnv()

Categories

(Core :: Preferences: Backend, defect)

Product:
Core
Component:
Preferences: Backend
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.0

People

(Reporter: margaret.chan, Assigned: jerry.tan)

References

Details

(Whiteboard: ns621_sun)

Attachments

(1 file, 6 obsolete files)

modified patch for sunbranch
2.31 KB, patch
dveditz
: review+
alecf
: superreview+
Details | Diff | Splinter Review 
Extracted from Brian Nesse's email:  

"There is a getenv call in the 4.x preferences JS 
context. It is mapped into an NSPR function, PR_GetEnv(),  that 
retrieves environment variables on Windows & Unix and pulls data from an 
array on the Mac.

The underlying NSPR functionality does appear to exist in mozilla. There 
is no support in preferences to access it however. It should be possible to add
this support into the AutoConfig JS context."
Whiteboard: ns621_sun
Please assign it to me.
I want to do it.

Other items which do not currently exist in the autoconfig module, but have been
requested are:
 - alert("message")
 - prompt("message")
 - versionInfo(major,minor,release,build)
 - getVersion(componet,vers)
 - getPlatform()

There are open bugs already for some of these (alert, possibly prompt) but I
just want to document the request(s) somewhere other than email. I would be
inclined to land some or all of these as a single patch rather than filing
individual bugs.

Assigning to Jerry as per his request.
Assignee: bnesse → jerry.tan
Keywords: 4xp
QA Contact: sairuh → rvelasco
I think just to implement such a function in js is not difficult.

I can apply one path.

Here is my test html code.
<SCRIPT LANGUAGE="JAVASCRIPT">
 <!--
 document.write(Math.getenv("PATH"));
 //-->
</SCRIPT>


Index: js/src/jsmath.c
===================================================================
RCS file: /mozilla/js/src/jsmath.c,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 jsmath.c
51a52
> #include "prenv.h"
389a391,404
> static JSBool
> math_getenv(JSContext *cx, JSObject *obj, uintN argc, jsval *argv, jsval *rval
)
> {
>    
>     JSString *value,*str;
>     const char *name;
>     str = JS_ValueToString(cx, argv[0]);
>     name = JS_GetStringBytes(str);    
>     value = JS_NewStringCopyZ(cx, PR_GetEnv(name));
>     if (!value)
>       return JS_FALSE;
>     *rval = STRING_TO_JSVAL(value);
>     return JS_TRUE;
> }
455a471
>     {"getenv",                math_getenv,            1, 0, 0},

But my question is  I dont know where I should put the code into.
I put it in Math object, it can work.
Status: NEW → ASSIGNED
well obviously Math is not the right place for it, not only because it's
inappropriate but because it doesn't need to exist in every JS context - only
the autoconfig one.

look at nsAutoConfig.cpp - that is the place to put it.
There is currently no way to add c based functions into this context. The
current functions are all supplied by the file prefcalls.js. As it stands right
now, implementing this through JS will require accessors which do not currently
exist. cc'ing dougt as he is currently involved in discussions pertaining to this.
nsAutoconfig.cpp is for global config,
but it is not easy to access for java script.

So IMO, just add function in the js engineer may be better.
maybe there shoule be another new object in javascript, just like Math,Date,
Blocks: 113387
I talked with brian nesse about this. 

You have to understand that we can't just go exposing getenv() to JS itself, to
be available in every JS context - that would allow random JS on web pages to
read a user's environment! This is NOT going to be added anywhere in js/src.

So, the immediate requirement is to add this capability to the autoconfig
context. Dougt pointed out on a newsgroup (n.p.m.xpcom I think) that we could
add this capability to nsIProcess (or make a new interface, nsICurrentProcess) -
that way it would be accessable to every XPConnected context. We could make this
a service, then it would be easy to get at.

then we could make global wrapper functions in prefcalls.js, something like:

function getenv(varname) {
  currentProcess =
Components.classes["@mozilla.org/xpcom/current-process;1"].getService(nsICurrentProcess);
  return currentProcess.getEnvironment(varname);
}
Attached patch one patch added to thread (obsolete) — — Splinter Review 
thank for the help of alec flett,
he gives me the tip how to do it.

we can access getenv function in js just like this
function getenv(name)
{
  var currentProcess
=Components.classes["@mozilla.org/process/util;1"].getService(Components.interfaces.nsIProcess);
 
  return currentProcess.GetEnv(name);
}
Comment on attachment 66722 [details] [diff] [review]
one patch added to thread

looks good, except you completely ignored the function names in the sample code
I gave you :)

all IDL methods must begin with leading lower case (i.e. "g" instead of "G")
and
we really don't like arbitrarily shortened names.. i.e. why call it "GetEnv"
when you could call it "getEnvironment" or even "getEnvironmentValue"?


>> NS_IMETHODIMP
>> nsProcess::GetEnv(const char *name,char **value)
>> {
>>     if(!value)
>>         return NS_ERROR_NULL_POINTER;
>>     *value = (char*) nsMemory::Clone(PR_GetEnv(name), sizeof(char)*(strlen(PR_GetEnv(name))+1));
>>     return *value ? NS_OK : NS_ERROR_OUT_OF_MEMORY;
>> }

This is simply hard to read, not to mention you're calling PR_GetEnv twice on
the
same variable. Why do extra work? at the very least you could be saying:

char *val = PR_GetEnv(name);
*value = (char*)nsMemory::Clone(val, sizeof(char)*strlen(val));

however, we have nsCRT::strdup which does this for you.

Try this:

NS_METHODIMP
nsProcess::GetEnvironment(const char *name, char **value)
{
  NS_ENSURE_ARG_POINTER(name);

  *value = nsCRT::strdup(PR_GetEnv(name));
  if (!*value) return NS_ERrOR_OUT_OF_MEMORY;  

  return NS_OK;
}
Attachment #66722 - Flags: needs-work+
>we really don't like arbitrarily shortened names.. i.e. why call it "GetEnv"
>when you could call it "getEnvironment" or even "getEnvironmentValue"?
I agree that arbitrarily shortened names are hard to read and therefore should be
avoid. IMHO, if Jerry's intention is to mirror C utility function name, 
getenv(), and this is what Communicator 4.x uses, then we might want to keep it as
"getenv" for easy reference and backward compatibility reason.
sorry I was referring to the member variable of nsIProcess, not the global
getenv() ... I'm fine with the global getenv().

That said, there's no NEED to maintain 4.x compatibility, because we've already
broken it. 

When deciding 4.x compatibility issues, we need to find the appropriate balance
of changes that are better in the long term vs. changes that make 4.x migration
easier. remember, 4.x migration only happens once for a given script... if we're
renaming a function name, we can easily document this and a script author can
search-and-replace.
>That said, there's no NEED to maintain 4.x compatibility, because we've already
>broken it. 
>
>When deciding 4.x compatibility issues, we need to find the appropriate balance
>of changes that are better in the long term vs. changes that make 4.x migration
>easier. remember, 4.x migration only happens once for a given script... if we're
>renaming a function name, we can easily document this and a script author can
>search-and-replace.
I suspect our 4.x customers and our own 6.x evangelists will welcome less changes 
during migration. CC tech support.

Stephanie, jhooker - any comment?

No! Please do not turn this bug into a 4.x migration discussion. We have a fix
that does not break '4.x backwards compatibility' - I was just making a point
that we need to BALANCE 4.x compatibility vs. long term maintainability - rather
than go for 4.x compatibility at all costs.

That said, lets move on with this bug. If you want to discuss 4.x compatibility,
let's continue it over private e-mail.

I agree with Alec.  The key point here is to get a fix/solution of the problem. 
Naming convention (such as IDL methods must begin with leading lower case)
should be kept whenever possible.  I am sure that Jerry wouldn't mind changing
GetEnv() to GetEnvironment() neither if that is a better choice.  And my guess
for his choice of name is plainly from either PR_GetEnv() or some others.   Alec
also mentions that he is not objecting to the use of the global getenv(), so it
should be fine from the users' point of view.  Even though it has to be changed
to something else for a good reason, it is understandable as soon as the change
is well-documented somewhere to the user.

Jerry:  Would you make the suggested changes please?
Attached patch updated patch (obsolete) — — Splinter Review 
in js, it should be like this.

function getenv(name)
{
  var currentProcess
=Components.classes["@mozilla.org/process/util;1"].getService(Components.interfaces.nsIProcess);
 
  return currentProcess.getEnvironment(name);
}


Thanks for big help of alec flett
First, use createInstance() instead of getService() -- we don't want an
nsProcess hanging around for the rest of the session.

Second, is this really the right component? Everything else in that interface
relates to the process you init-ed, sticking some global information in there
doesn't seem right. Would nsISystemInfo.idl be better? (ask shaver first, though).
Comment on attachment 66839 [details] [diff] [review]
updated patch 

looks good to me. Please add a javadoc-style comment in nsIProcess.idl just to
explain what the function is for.

Also, we generally prefer "unified" diffs, which you can get with cvs diff -u
(or by putting the line "diff -u" in your .cvsrc)
Attachment #66839 - Flags: superreview+
Comment on attachment 66839 [details] [diff] [review]
updated patch 

oh whoops, I just saw dougt's comment. doug, I thought nsIProcess was your
idea, from the post on netscape.public.mozilla.xpcom?

Dout Turner wrote: 
> How about adding a GetEnv/SetEnv method to the following interface:
>
> http://lxr.mozilla.org/seamonkey/source/xpcom/threads/nsIProcess.idl
hey alec.  I suggested putting this in nsIProcess.  There were some good
responses why this would be best on all platforms (read the ng postings).  Based
on that, maybe we should have a nsICurrentProcess interface.  

Dan, environment vars are process specific.
some *Current* process I could be on-board with, sticking it in nsIProcess seems
kludgy. It's like saying if I were hypothetically to launch a child process it
would inherit its parent's environment, therefore I'll get the environment
variable from my hypothetical child process. But why not? All the
NS_ERROR_NOT_IMPLEMENTED in nsProcessCommon.cpp shows it's not fully baked anyway.

Where's the patch to prefcalls.js ? 

Calling GetService() on some CurrentProcess thing might be kosher, but it
doesn't seem right for nsIProcess. Doug, what's your thoughts on that?
Attached patch add comment to idl (obsolete) — — Splinter Review 
add comment to idl, and add getenv() to prefcalls.js
Comment on attachment 67033 [details] [diff] [review]
add comment to idl

>+/**
>+ * for bug 120866 , add suport to access enviroment 
>+ *
>+ */ 
>+        string getEnvironment(in string name);

Not much of a comment. You should at least mention
that unset environment variables will be returned as ""
instead of NULL since that might confuse people.

We're trying to encourage javadoc style, with @param
and @return etc.


>+NS_IMETHODIMP
>+nsProcess::GetEnvironment(const char *name, char **value)
>+{
>+   NS_ENSURE_ARG_POINTER(name);
>+  *value = nsCRT::strdup(PR_GetEnv(name));
>+  if (!*value) return NS_ERROR_OUT_OF_MEMORY;  
>+  return NS_OK;
>+}

Please clean up the trailing and leading spaces before you
check in. Putting if and return on the same line doesn't
fit the prevailing style in the file (there is one place
that way, but the rest aren't).

>+function getenv(name)
>+{
>+  var currentProcess=Components.classes["@mozilla.org/process/util;1"].createInstance(Components.interfaces.nsIProcess);
>+  return currentProcess.getEnvironment(name);
>+}

Use try/catch -- if you hit the out of memory condition (or
any other XPCOM error) it will throw an exception into
the autoconfig script, probably killing it.
dveditz@netscape.com:  Would you mind sending Jerry a pointer of a good javadoc
example?  Jerry is pretty new to mozilla, a good example can certainly help. 
Thanks.
javadoc is of course a Sun thing, not Mozilla, but for a Mozilla example try
http://lxr.mozilla.org/seamonkey/source/modules/libpref/public/nsIPrefBranch.idl
or another of the "@status FROZEN" .idl files
not to mention, this is Code Commenting 101. There's no need for bug numbers in
every comment especially in interfaces, and the code should clearly explain what
parameters are for, what the return value is, and where the return value should
come from. 


Very good points.  Not to say that Jerry is new to mozilla, he is new to Sun
(China) as well.  I am asking for an example recommended by the mozilla
community just in case he is not fully aware of certain coding/commenting
practices being used in the community.  dveditz@netscape.com has provided him a
very good pointer, thanks.  I think that it will help.
Attached patch modified patch (obsolete) — — Splinter Review 
I am new to mozilla, but thanks for the help of mozilla community,
including alec, margaret, bness ...
I will be more and more familiar with mozilla,
and can do more contribution.

I have told my group that if they are not familiar with the code style of
mozilla, just come to see this bug.
Attachment #68113 - Flags: review+
Comment on attachment 68113 [details] [diff] [review]
modified patch

>+        /**
>+         * Called to get the value of environment variable
>+         *
>+         * @param aName     The string enviroment variable name
>+         * @param aValue    The string value of the enviroment variable
>+         *
>+         * @return NS_OK The value was retrieved successfully.
>+         * @return Other The value could not be retrieved.
>+         *
>+         */
>+        string getEnvironment(in string aName);

It was pointed out to me that nsIPrefBranch.idl (which I picked arbitrarily
as looking good at first glance) does some odd things with @return.

Logically from the idl syntax and, more importantly, when used from JavaScript,
the return value is the string environment variable. That's what the @return
should describe. The "nsresult" return values in the C++ implementation end
up being exceptions as seen from JavaScript and should be documented using
@exception (or @throws)

Note that you had to use try{}catch{}. Documenting @exception is
important so unsuspecting future users of this class don't get hit
with an unexpected throw.

I don't seen the aValue param you document

Please change the comment to something like

>+        /**
>+         * Called to get the value of environment variable
>+         *
>+         * @param aName     The string enviroment variable name
>+         * @exception       NS_ERROR_OUT_OF_MEMORY
>+         *
>+         * @return the environment variable string
>+         */

r=dveditz on the code itself
Comment on attachment 68113 [details] [diff] [review]
modified patch

dveditz: actually you'll see the @return stuff documented in similar ways all
over the frozen interfaces.. that's actually the "right" way to do
things...(though I am with you - I think its wierd)

however, since that is the convention, sr=alecf on the whole patch.
Attachment #68113 - Flags: superreview+
alecf: I completely disagree that the way nsIPrefBranch.idl's style of
documenting exceptions is the "right way."  What makes you say it is?
http://lxr.mozilla.org/seamonkey/source/embedding/browser/webBrowser/nsIWebBrowser.idl
is one example.... Adding Chak, master of frozen interfaces, to see if he has a
reference to a document that documents documenting.

The fact it's used incorrectly in frozen interfaces doesn't make it right.
oops, actually add chak. My understanding was that @return was the way we were
going to document this - I'm not saying "a frozen interface does it, so we
should too".. 
You can use the following link as a starting point for info. on Javadoc : 
  http://java.sun.com/j2se/javadoc/writingdoccomments/index.html

Chak: that doesn't help at all. We *know* the Javadoc syntax, we want to know
about our weird mis-use of them. Many frozen interfaces appear to use tags
defining the C++ implementation rather than the IDL/javascript interface
directly below the documentation.

For example, a non-success nsresult is defined as the @return instead of the
@throws/@exception it would appear to be from javascript, and the thing that
appears to the the return value in the idl or in javascript is listed as just
another @param.

The question: Are those examples wrong? Should we instead use standard Javadoc
as the link you provided shows, or have we documented some alternate format
somewhere?
Hi Dan : The only place where i've seen somewhat of a "spec" on how to doc idl
interfaces is at http://www.mozilla.org/projects/embedding/EmbedInterfaceFreeze.html
[There's a section titled "How to mark an interface as frozen?" towards the end
of that page. You'll notice that it is not really all that specific and refers
you to  the Javadoc link]

I'm fine with using the standard Javadoc convention - which is what we're
encouraging for embedding interfaces. May be someone else(not sure who) can comment?
While working on the documentation for the preferences idl files, I looked at
the javadoc guidelines, the interface freeze document, and other frozen idls.
The guidelines don't, as others have noted, provide any real guidance. The
others are somewhat indeterminate.

It seems to me that the real question is... Are we documenting for C/C++ users
or Java users. Once we determine that, the answer to the question of what
belongs there becomes much clearer.
We're documenting for any users of any IDL binding.  The concept here is that
these are exceptions; this is in part evidenced by the fact that they are bound
to them in the JS binding (XPConnect).  As far as I know, the only reason these
"return values" aren't bound to C++ exceptions in that binding is that we have
these unfortunate portability restrictions with having to support crufty C++
compilers.
Hi all:

Since there is no spec or guidelines laid out upfront on how exactly such a
documentation should be done, it seems to me that it's difficult to say that
this is right or that is wrong.  We can continue to debate on this issue without
a conclusion due to the missing spec/guidelines.  In order to move on with
this bug, I would like to propose Jerry to make the change as suggested by
dveditz@netscape.com, i.e., something like: 

        /**
         * Called to get the value of environment variable
         *
         * @param aName     The string enviroment variable name 
         * @exception       NS_ERROR_OUT_OF_MEMORY
         *
         * @return 	    The value of the requested string environment variable
name
         */

By doing so, I am not saying that this is the only right way to do such a
comment, I just think that this is a way which is:

1.  not so weird as it seems to be agreed by everybody
2.  has a good reasoning behind 
3.  we are not the only one who breaks the convention
e.g., there are some comments like this:

114   /**
115    * Called to get the state of an individual string preference.
116    *
117    * @param aPrefName The string preference to retrieve.
118    *
119    * @return string   The value of the requested string preference.
120    *
121    * @see setCharPref
122    */
123   string getCharPref(in string aPrefName);

in
http://lxr.mozilla.org/seamonkey/source/modules/libpref/public/nsIPrefBranch.idl

If there is no objection, I would suggest Jerry to make such a change.
Works for me.  Alec?
yes fine with me too.. let's move forward on this. I'll continue to review,
someone post a patch.
Great.  Jerry is off till 2/18, and I don't have the latest trunk build.  I'll
see if I can find someone to update the patch and keep it going.  If not, we'll
just have to wait for Jerry to come back.  Thanks everybody.
Attached patch patch (obsolete) — — Splinter Review 

    
    

    
  
Can we have r= & sr= and get it check in?  Thanks, Margaret

    
    

    
  
Comment on attachment 70215 [details] [diff] [review]
patch

THanks for making that comment change. sr=dveditz, I don't think you need a
re-review (r=) for just a comment change.

        Attachment #70215 -
        Flags: superreview+

        Attachment #70215 -
        Flags: review+

    
    

    
  
Margaret, the tree is frozen.... please mail drivers@mozilla.org requesting
approval for checkin.

    
    

    
  
Comment on attachment 70215 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to 0.9.9 and the trunk.

        Attachment #70215 -
        Flags: approval+

    
    

    
  
Has this fix been checked in?

I can not find it on current trunk.


    
    

    
  
I'm confused, the bug is assigned to you but someone else is checking in? 
Shouldn't you know who and ask them directly?

    
    

    
  
Sorry for the confusion.  Jerry does not have checkin privilege yet.  I have 
got Asa's approval last Friday, but do not get the time to do the checkin for 
Jerry.  Can someone do that for him?  If not, I'll try to get to that tomorrow.


    
    

    
  
I want to apply the patch for sunbranch.
but sunbranch's codebase is 094,
it doesnot have autoconfig module.

Should I add getenv() function into 
$mozilla_source/modules/libpref/src/initpref.js, just like that
function getenv(name) {
     try {
       var currentProcess=Components.classes
["@mozilla.org/process/util;1"].createInstance
(Components.interfaces.nsIProcess);
       return currentProcess.getEnvironment(name);
   }
   catch(e) {
       displayError("getEnvironment failed with error: " + e);
   }
}



    
    

    
  
oh.. to do this on 0.9.4, you're going to have to take a completely different
approach and hack prefapi.c

My recommendation: get off of 0.9.4 :)


    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch added to prefapi.c (obsolete)
        — 
          — Splinter Review
      

    


  
Alecf, I have made another patch for it according to your suggestion.
Can you review it?
I need to apply the bug fix to sunbranch.

    
    

    
  
Jerry, your patch does the right thing. As is sounds like this is going on a sun 
specific branch, I doubt you need r/sr approval.

I will note, however, that you are not doing any validation on the incoming 
parameters. Unless you know how PR_GetEnv will act given bad data, or can 
guarantee that users won't pass bad data, you might consider validating argv (and 
possible argc as well.)


    
    

    
  
oh, Bness, you are right
I do a little change ,just like this.

JSBool PR_CALLBACK pref_GetEnvironment(JSContext *cx, JSObject *obj, unsigned 
int argc, jsval *argv, jsval *rval)
{
    if (JSVAL_IS_STRING(argv[0])){
        JSString *value,*str;
        const char *name;
        str = JS_ValueToString(cx, argv[0]);
        name = JS_GetStringBytes(str);    
        value = JS_NewStringCopyZ(cx, PR_GetEnv(name));
        if (!value)
          return JS_FALSE;
        *rval = STRING_TO_JSVAL(value);    
   }
   return JS_TRUE;       
}

is it right?


    
    

    
  
Comment on attachment 72916 [details] [diff] [review]
patch added to prefapi.c

yeah, I'm with brian - there is no error checking here, which means someone
could easily crash the browser just by saying
getEnv(null);

Also, you're using a different function name from the other patch (getEnv vs.
getenv) which means all your users will have to tweak their scripts when they
upgrade to a mozilla 1.0 based browser.

I'd say you should fix that. :)

        Attachment #72916 -
        Flags: needs-work+

    
    

    
  
You don't want to return JS_FALSE -- that will throw an exception and 
likely crash the autoconfig script. Are autoconfig script writers expected to 
use try/catch as a matter of course?

Better might be 
   if (!value)
     *rval = JSVAL_NULL;
   else
     *rval = STRING_TO_JSVAL(value);
   return JS_TRUE;

unless you really want the exception thrown in the not-unlikely case someone 
tests for an environment variable that isn't set.

You should test that there *is* an argv[0] before calling JSVAL_IS_STRING() on 
it.  "if (argc > 0)"

I'm fine with JSVAL_IS_STRING() if you want to force people to use only true 
strings, but js is pretty liberal about converting to strings in a string 
context and you might want to fit in. Your old code that simply called 
JS_ValueToString() on whatever the user passed in wasn't wrong -- everything in 
js can be converted into a string. What was missing was the argc > 0 check, and 
adding the JSVAL_IS_STRING() didn't fix that problem.

Whether you keep the JSVAL_IS_STRING() check is up to you. Are there any 
config objects people get which aren't technically strings but are often 
manipulated as strings because they have a friendly toString() method? I'm not 
familiar enough with the config context or what functions like getPref() or 
getLDAPAttributes() return.

    
    

    
  


  

    
    

    
  
Comment on attachment 73610 [details] [diff] [review]
modified patch for sunbranch

this seems much better. sr=alecf

        Attachment #73610 -
        Flags: superreview+

    
    

    
  
the patch for trunk has not been checkin, can someone help me?


BTW: I have no privilege on bugzilla, can someone help me to make old patch as 
obsolete? it looks ugly for one bug has so many patch.
(browser-china@sun.com)



    
    

    
  
Comment on attachment 73610 [details] [diff] [review]
modified patch for sunbranch

getenv() now returns junk instead of crashing. I can live with that, but
initializing *rval to JSVAL_NULL might have been better. In any case passing no
args is a bug in on the script-authors part so I'm not so worried.

r=dveditz

        Attachment #73610 -
        Flags: review+

        Attachment #66722 -
        Attachment is obsolete: true

        Attachment #66839 -
        Attachment is obsolete: true

        Attachment #67033 -
        Attachment is obsolete: true

        Attachment #68113 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 72916 [details] [diff] [review]
patch added to prefapi.c

To get your bugzilla permissions changed contact asa@mozilla.org

        Attachment #72916 -
        Attachment is obsolete: true

    
    

    
  
Can I ask someone to check in the attachment 70215 [details] [diff] [review] for us please?  Sorry that I
am so swamp with other things that I cannot get to do this.  Considering Jerry
has spent so much time on this problem and we have gone all the way to get a=
from asa, I hate to see this not going in to 1.0.  My apologies for not getting
to this sooner.  Any help?  Brian?
Target Milestone: --- → mozilla1.0

    
    

    
  
I'll apply the patch to a tree and try an land it today.

    
    

    
  
Really appreciated it, Brian.  Margaret


    
    

    
  
Patch is checked in to the 1.0 trunk.

I have no idea what the status of the sunbranch checkin is, so I will leave the
bug open.

    
    

    
  
Comment on attachment 70215 [details] [diff] [review]
patch

obsoleting checked in patch.

        Attachment #70215 -
        Attachment is obsolete: true

    
    

    
  
as the patches have been checked into trunk and sunbranch,
I think this bug can be marked as fixed.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

    
  
Thanks Brian for checking it in to the trunk for us.  Margaret

    
  
QA Contact: rvelasco → lrg

    
    

    
  
I have noticed that the getenv() function doesn't seem to be working for MacOSX,
has this functionality been implemented there?

It working on windows and linux in the most recent trunk build.

    
    

    
  
well um, did you try a Carbon or MachO build? if you're using carbon, then 
you're using a stub which will allow you to set and get env vars (in that 
order, since you start out with no vars).

I've looked into MPW-GM\Interfaces&Libraries\Interfaces\CIncludes\stdlib.h
and it does define a getenv/setenv pair.  I filed bug 154052 against 
nspr because the fault lies there.
Depends on: 154052

    
    

    
  
Sorry, I will give you specific platform info:
OS= MacOS 10.1
Netscape=(macintosh; U; PPC Mac OS X; en-US, rv 1.1.a+) gecko/20020624
Netscape/7.0b1+
Autocofig.jsc file is hosted on a linux machine running apache. 

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: