[Patches] [ python-Patches-460805 ] Support for unsetenv()
noreply@sourceforge.net
noreply@sourceforge.net
Wed, 12 Sep 2001 21:08:17 -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: Nobody/Anonymous (nobody)
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: 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