This adds unsetenv to posix, and uses it in the __delitem__ method of
os.environ.
(XXX Should we change the preferred name for putenv to setenv, for
consistency?)
This is a big one, touching lots of files. Some of the platforms
aren't tested yet. Briefly, this changes the return value of the
os/posix functions stat(), fstat(), statvfs(), fstatvfs(), and the
time functions localtime(), gmtime(), and strptime() from tuples into
pseudo-sequences. When accessed as a sequence, they behave exactly as
before. But they also have attributes like st_mtime or tm_year. The
stat return value, moreover, has a few platform-specific attributes
that are not available through the sequence interface (because
everybody expects the sequence to have a fixed length, these couldn't
be added there). If your platform's struct stat doesn't define
st_blksize, st_blocks or st_rdev, they won't be accessible from Python
either.
(Still missing is a documentation update.)
Curious: the MS docs say stati64 etc are supported even on Win95, but
Win95 doesn't support a filesystem that allows partitions > 2 Gb.
test_largefile: This was opening its test file in text mode. I have no
idea how that worked under Win64, but it sure needs binary mode on Win98.
BTW, on Win98 test_largefile runs quickly (under a second).
pyport.h: typedef a new Py_intptr_t type.
DELICATE ASSUMPTION: That HAVE_UINTPTR_T implies intptr_t is
available as well as uintptr_t. If that turns out not to be
true, things must get uglier (C99 wants both, so I think it's
an assumption we're *likely* to get away with).
thread_nt.h, PyThread_start_new_thread: MS _beginthread is documented
as returning unsigned long; no idea why uintptr_t was being used.
Others: Always use Py_[u]intptr_t, never [u]intptr_t directly.
Also note that it isn't just Linux nice() that is broken: at least FreeBSD
and BSDI also have this problem. os.nice() should probably just be emulated
using getpriority()/setpriority(), if they are available, but I'll get to
that later.
"Partial" as the code uses sys.prefix in an attempt to locate 'w9xpopen.exe', but sys.prefix is not set if Python can't find it itself. So this _still_ fails in Pythonwin, but I am committing the patch for 2 reasons:
* Embedded apps that set sys.prefix or use PYTHONHOME will work
* The exception raised on failure to find the executable is far more obvious
subset of Win32 ShellExecute's functionality. Guido wants this because
IDLE's Help -> Docs function currently crashes his machine because of a
conflict between his version of Norton AntiVirus (6.10.20) and MS's
_popen. Docs for startfile are being mailed to Fred (or just read the
docstring -- it tells the whole story).
Changed webbrowser.py to use os.startfile instead of os.popen on Windows.
Changed IDLE's EditorWindow.py to pass an absolute path for the docs
(hardcoding ShellExecute's "directory" arg to "." as used to be done let
IDLE work, but made the startfile command exceedingly obscure for other
uses -- the MS docs are terrible, of course, & still not sure I
understand it).
Note that Windows Python must link with shell32.lib now! That's where
ShellExecute lives.
glob.glob("k:*py") (i.e., a raw drive letter + colon at the start) were
using the root of the drive rather than the expected Windows behavior
of using the drive's "current directory".
implementation. You don't want to know. I've asked Guido to give this
a critical review (we agreed on the approach, but the implementation
proved more ... interesting ... than anticipated). This will almost
certainly be the highlight of Mark Hammond's day <wink>.
Minor updates for BeOS R5.
Use of OSError in test.test_fork1 changed to TestSkipped, with corresponding
change in BeOS/README (by Fred).
This closes SourceForge patch #100978.
This is an enhancement to a prior patch (100941) ...
[T]his patch removes the risk of deadlock waiting for the child previously present in certain cases. It adds tracking of all file handles returned from an os.popen* call and only waits for the child process, returning the exit code, on the closure of the final file handle to that child.
for systems that are missing those declarations from system include files.
Start by moving a pointy-haired ones from their previous locations to the
new section.
(The gethostname() one, for instance, breaks on several systems, because
some define it as (char *, size_t) and some as (char *, int).)
I purposely decided not to include the summary of used #defines like Tim did
in the first section of pyport.h. In my opinion, the number of #defines
likedly to be used by this section would make such an overview unwieldy. I
would suggest documenting the non-obvious ones, though.
and a couple of functions that were missed in the previous batches. Not
terribly tested, but very carefully scrutinized, three times.
All these were found by the little findkrc.py that I posted to python-dev,
which means there might be more lurking. Cases such as this:
long
func(a, b)
long a;
long b; /* flagword */
{
and other cases where the last ; in the argument list isn't followed by a
newline and an opening curly bracket. Regexps to catch all are welcome, of
course ;)
comments, docstrings or error messages. I fixed two minor things in
test_winreg.py ("didn't" -> "Didn't" and "Didnt" -> "Didn't").
There is a minor style issue involved: Guido seems to have preferred English
grammar (behaviour, honour) in a couple places. This patch changes that to
American, which is the more prominent style in the source. I prefer English
myself, so if English is preferred, I'd be happy to supply a patch myself ;)
windows.
- added optional mode argument to popen2/popen3
for unix; if the second argument is an integer,
it's assumed to be the buffer size.
- changed nt.popen2/popen3/popen4 return values
to match the popen2 module (stdout first, not
stdin).
cast to make sure Py_BuildValue gets the right thing.
this change eliminates bogus return codes from successful
spawn calls (e.g. 2167387144924954624 instead of 0).
staring at the diffs before checking this one in. let me know
asap if it breaks things on your platform.
-- ANSI-fying
(patch #100763 by Peter Schneider-Kamp, minus the
indentation changes and minus the changes the broke
the windows build)
In posixmodule.c:posix_fork, the function PyOS_AfterFork is called for
both the parent and the child, despite the docs stating that it should
be called in the new (child) process.
This causes problems in the parent since the forking thread becomes the
main thread according to the signal module.
Calling PyOS_AfterFork() only in the child fixes this. Changed for both
fork() and forkpty().
This patch fixes the posix module for large file support mainly on
Win64, although some general cleanup is done as well.
The changes are:
- abstract stat->STAT, fstat->FSTAT, and struct stat->STRUCT_STAT
This is because stat() etc. are not the correct functions to use on
Win64 (nor maybe on other platforms?, if not then it is now trivial to
select the appropriate one). On Win64 the appropriate system functions
are _stati64(), etc.
- add _pystat_fromstructstat(), it builds the return tuple for the
fstat system call. This functionality was being duplicated. As well
the construction of the tuple was modified to ensure no overflow of
the time_t elements (sizeof(time_t) > sizeof(long) on Win64).
- add overflow protection for the return values of posix_spawnv and
posix_spawnve
- use the proper 64-bit capable lseek() on Win64
- use intptr_t instead of long where appropriate from Win32/64 blocks
(sizeof(void*) > sizeof(long) on Win64)
This closes SourceForge patch #100513.
This patch adds the openpty() and forkpty() library calls to posixmodule.c,
when they are available on the target
system. (glibc-2.1-based Linux systems, FreeBSD and BSDI at least, probably
the other BSD-based systems as well.)
Lib/pty.py is also rewritten to use openpty when available, but falls
back to the old SGI method or the "manual" BSD open-a-pty
code. Openpty() is necessary to use the Unix98 ptys under Linux 2.2,
or when using non-standard tty names under (at least) BSDI, which is
why I needed it, myself ;-) forkpty() is included for symmetry.
Checkin 2.131 of posixmodule.c changed os.stat on Windows, so that
"/bin/" type notation (trailing backslash) would work on Windows to
be consistent with Unix.
However, the patch broke the simple case of: os.stat("\\")
This did work in 1.5.2, and obviously should!
This patch addresses this, and restores the correct behaviour.
utime(path, NULL) call, setting the atime and mtime of the file to the
current time. The previous signature utime(path, (atime, mtime)) is
of course still allowed.
This patch changes posixmodule.c:execv to
a) check for zero length args (does this to execve, too), raising
ValueError.
b) raises more rational exceptions for various flavours of duff arguments.
I *hate*
TypeError: "illegal argument type for built-in operation"
It has to be one of the most frustrating error messages ever.
backslash from the pathname argument to stat() on Windows -- while on
Unix, stat("/bin/") succeeds and does the same thing as stat("/bin"),
on Windows, stat("\\windows\\") fails while stat("\\windows") succeeds.
This modified version of the patch recognizes both / and \.
(This is odd behavior of the MS C library, since
os.listdir("\\windows\\") succeeds!)
(1) In opendir(), don't call the lock-release macros; we're
manipulating list objects and that shouldn't be done in unlocked
state.
(2) Don't use posix_strint() for chmod() -- the mode_t arg might be a
64 bit int (reported by Nick Maclaren).
building the dicts used to inform the user about the defined
constants when using the *conf*() APIs.
Thanks to Mark Hammond <mhammond@skippinet.com.au>.
strings to integers for the *conf*() functions.
Added code to sort the tables at module initialization. Three
dictionaries, confstr_names, sysconf_names, and pathconf_names, are
added to the module as well. These map known configuration setting
names to the numeric value which is used to represent the setting in
the system call. This code is always called.
Updated related comments.
pathconf() names, from Sjoerd.
Added code to verify that these tables are properly ordered, only
included and used when CHECK_CONFNAME_TABLES is defined. This is only
needed to test the tables, so I haven't enabled this by default.
available since the interface is poorly defined on at least one major
platform (Solaris).
Moved table of constant names for fpathconf() & pathconf() into the
conditional that defines the conv_path_confname() helper; Mark Hammond
reported that defining the table when none of the constants were
defined causes the compiler to complain (won't allow 0-length array,
imagine that!).
In posix_fpathconf(), use conv_path_confname() as the O& conversion
function, instead of the conv_confname() helper, which has the wrong
signature (posix_pathconf() already used the right thing).
and TMP_MAX.
Converted all functions that used PyArg_Parse() or PyArg_NoArgs() to
use PyArg_ParseTuple() and specified all function names using the
:name syntax in the format strings, to allow better error messages
when TypeError is raised for parameter type mismatches.
Treat them as read-only, and make a copy as appropriately. This was
first reported by Bill Janssend and later by Craig Rowland and Ron
Sedlmeyer. This fix is mine.
different values in the environ dict with the same key (although he
couldn't explain exactly how this came to be). Since getenv() uses
the first one, Python should do too. (Some doubts about case
sensitivity, but for now this at least seems the right thing to do
regardless of platform.)
f_fsid field, since it's not a scalar on all systems supporting this
call (in particular, it's a tuple of two longs on AIX). Since it's
not particularly useful, just nuke it. Adapted the doc strings too.
exceptions:
posix_error_with_filename(): New function which calls
PyErr_SetFromErrnoWithFilename()
The following methods have been changed to call
posix_error_with_filename():
posix_1str()
posix_strint()
posix_strintint()
posix_do_stat()
posix_mkdir()
posix_utime()
posix_readlink()
posix_open()
INITFUNC(): os.error (nee PosixError) is PyExc_OSError
signal handlers in a fork()ed child process when Python is compiled with
thread support. The bug was reported by Scott <scott@chronis.icgroup.com>.
What happens is that after a fork(), the variables used by the signal
module to determine whether this is the main thread or not are bogus,
and it decides that no thread is the main thread, so no signals will
be delivered.
The solution is the addition of PyOS_AfterFork(), which fixes the signal
module's variables. A dummy version of the function is present in the
intrcheck.c source file which is linked when the signal module is not
used.
(1) Use PyErr_NewException("module.class", NULL, NULL) to create the
exception object.
(2) Remove all calls to Py_FatalError(); instead, return or
ignore the errors -- the import code now checks PyErr_Occurred()
after calling a module's init function, so it's no longer a
fatal error for the initialization to fail.
Also did some small cleanups, e.g. removed unnecessary test for
"already initialized" from initfpectl(), and unified
initposix()/initnt().
I haven't checked this very thoroughly, so while the changes are
pretty trivial -- beware of untested code!
Martin v. Löwis
Guido van Rossum
Tim Peters
Skip Montanaro
Fred Drake
Thomas Wouters
Mark Hammond
Neil Schemenauer
Peter Schneider-Kamp
Fredrik Lundh
Andrew M. Kuchling
Jeremy Hylton
Barry Warsaw
Greg Ward
Roger E. Masse