[Patches] [ python-Patches-460805 ] Support for unsetenv()

noreply@sourceforge.net noreply@sourceforge.net
Fri, 14 Sep 2001 06:25:48 -0700


Patches item #460805, was opened at 2001-09-11 21:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Gonnerman (solomoriah)
Assigned to: Thomas Wouters (twouters)
Summary: Support for unsetenv()

Initial Comment:
The attached patch files implement os.unsetenv() for 
Python 2.1 and 2.2a3.  os.py is extended to call 
unsetenv() when _Environ.__delitem__ is called.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-14 06:25

Message:
Logged In: YES 
user_id=6380

On the other hand, setting to "" is better than nothing, and
I believe that (because unset isn't universally supported in
shells either) defensive programming takes an empty
environment variable the same as an absent one. That's
certainly how I've learned to use getenv(). But maybe that
qualifies me as an oldtimer. :-)

----------------------------------------------------------------------

Comment By: Chris Gonnerman (solomoriah)
Date: 2001-09-14 04:58

Message:
Logged In: YES 
user_id=321948

I didn't fake unsetenv() on all platforms because it's 
not really "fake".  putenv(key, "") actually removes the
given environment variable on Win32 ('nt') and I think on
OS/2 and DOS as well.  On Unix platforms it does not, and
I feel it's a mistake to have unsetenv() and not have it
actually work.


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-09-14 02:34

Message:
Logged In: YES 
user_id=34209

You don't have to submit a patch for 2.1, 2.1.1 was the 
final 2.1 release, and a patch like this would never make 
it into a patch release anyway.

The unsetenv function looks good. The os.py changes don't 
make a whole lot of sense, however. Why not fake unsetenv 
on all platforms ? It's a simple matter of a 'hasattr()'. 
Setting the environment variable to an empty string on 
delete is more preferable than the current behaviour, I 
think. We could also fake it in C, though that means the 
other platform modules that aren't build from posix.c 
(riscos, macos, etc). 




----------------------------------------------------------------------

Comment By: Chris Gonnerman (solomoriah)
Date: 2001-09-13 20:36

Message:
Logged In: YES 
user_id=321948

You asked for it... attached now is an updated patchfile
set for 2.1 and 2.2 with unsetenv() bindings for Windows;
I defined unsetenv(key) in terms of putenv(key, "") if
os.name is 'os2', 'nt', or 'dos' (I'm pretty sure that's 
right for DOS if anyone can build the rest of Python for
that platform; I'm not so sure about OS/2).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-13 09:33

Message:
Logged In: YES 
user_id=6380

Excellent, Thomas. I was waiting for someone to champion
this. I hope you don't mind that I assigned it to you. Go
ahead and review the code and decide what to do!

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-09-13 08:50

Message:
Logged In: YES 
user_id=34209

Sorry, Guido, but I have to agree with Chris here. You 
*can't* do without unsetenv. Setting the environment 
variable to an empty string is not the same as removing 
it. unsetenv() appeared in BSD4.3, so it is a lot more 
standard than, say, LFS support, or some of the other 
functions we define in the posix module. It's easy to test 
for, it introduces no problems wrt. prototypes or such, 
and it provides functionality that's not available 
otherwise.

Unsetting environment variables can't be done portably, 
but we can't do it *at all* right now. Making 'del' work 
the expected way (by using unsetenv, or faking it using 
os.putenv(key, "") seems very useful to me -- in fact, I 
was suprised os.environ didn't already do that! I 
definately do not see this as code bloat.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-13 08:36

Message:
Logged In: YES 
user_id=6380

Lots of speculation there, but no motivation beyond "it's
not Pythonic". IMO it's very Pythonic not to provide
features that are rarely needed and can easily be done
without. But who am I to judge. :-)

If you give me a patch that implemens "del os.environ[key]"
by calling os.putenv(key, ""), I'll accept it in a jiffy.

----------------------------------------------------------------------

Comment By: Chris Gonnerman (solomoriah)
Date: 2001-09-12 21:08

Message:
Logged In: YES 
user_id=321948

Ouch.

It's in AT&T/USL/SCO Unix AFAIK, it's in NetBSD and GNU
libc for sure, and the other BSD's also I believe; Win32
provides a different way to do it, but there is a way.
I think Solaris has it also but I can't easily check.

De facto standards are important too.

As for the bloat argument, my patch adds a tiny function
to posixmodule and a tiny method to os._Environ (in the
Unix version only at this point); my Python 2.1 
interpreter gained a couple hundred bytes.

Code bloat is when you add unnecessary features to a 
module.  Python has *no other way* to remove an 
environment variable so that child processes don't see
it, so Python's behavior is broken.  It is IMHO not
Pythonic to have 

    del os.environ["HOME"]

(for instance) not work correctly.  From the perspective
of the calling module, there is no longer a HOME variable,
but called processes will still see it.  It's true, you
can set the variable to a null string, but this isn't the
same thing and might not satisfy some secure programming
requirements.





----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-12 18:31

Message:
Logged In: YES 
user_id=6380

Code bloat. If it's not important enough to standardize in
POSIX (or one of the other standards), why should we add it?
GNU code is infamous for always including more features,
needed or not. If you're cynical, this is part of a
Microsoft-like "buy-in" strategy (code developed for GNU
libc doesn't work anywhere else).

----------------------------------------------------------------------

Comment By: Chris Gonnerman (solomoriah)
Date: 2001-09-12 18:20

Message:
Logged In: YES 
user_id=321948

By the way, I found the following note in the man pages
for NetBSD:

    The functions setenv() and unsetenv() appeared in 
    Version 7 AT&T UNIX.

so it appears, standard or not, that most real Unix systems
should have it.

Regarding the minimal utility argument, I don't currently
have a use for it, but it came up on the mailing list
so I wrote it.  It's recommended, when writing sysadmin
tools which call other programs, to "clean up" the 
environment so that only known-safe values are in there
before calling the externals.



----------------------------------------------------------------------

Comment By: Chris Gonnerman (solomoriah)
Date: 2001-09-12 18:14

Message:
Logged In: YES 
user_id=321948

Well, the only place I know of that it is standardized is 
in GNU libc.  That's not entirely the point, though.

1) If you do 'del os.environ["SOMEVAR"]' you remove SOMEVAR 
from the copy of the environment but not from the real 
environment.  This behavior IMHO is broken.

2) It's true, many OS's don't have unsetenv().  However, 
my patch falls back to the *current* behavior if unsetenv()
is not available.  In other words, this doesn't break 
Python any more than it's already broken, and it's a net
gain for operating systems that *do* have unsetenv().

I figure if some gain and none lose, why not do it?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-12 06:38

Message:
Logged In: YES 
user_id=6380

Can you point to where unsetenv is standardized? I'm worried
that it's not available on standard-conforming Unix systems,
and since it's of marginal utility at best, I'm not sure
what the point is to add it -- unless there's a clear
standard that ensures its existence.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=460805&group_id=5470