Luke Kenneth Casson Leighton added the comment: hi ned,
well, the situation surrounding the bug-reporting that i was doing at the time was a general campaign of "this person is obviously wasting our time because they're developing yet another port/platform, that is obviously a waste of our time, therefore we will shut him down and ban him from the bugtracker and thus generally make our lives easier". so against that background i really wasn't inclined to contribute to the development of python. the argument given for this specific bug [off-list because i had been ordered not to use the bugtracker] was "it's not a supported combination therefore obviously it's not a bug". leaving that aside, and assuming that things have moved on from there and that improvements to python and its expansion into areas beyond where it is currently entrenched are welcomed, the arguments given 3 years ago are actually valid... but from a different perspective: the combination of win32 and bash is particularly weird [i.e. borderline] and thus the test is incomplete. so it would be best i feel to consider what the test is trying to achieve: set environment variables, and then execute a command that results in that environment variable being passed and read back with python's popen command. in the POSIX case, the easiest way to do that would involve using /bin/sh - a pretty standard baseline application that can be expected to exist on every POSIX platform under the sun. but the most "generic" case would actually involve compiling a small c application which read - in c - a standard environment variable - and printf'd it then exited. a quick google search "c getenv" shows a perfect example: http://msdn.microsoft.com/en-gb/library/aa246422%28v=vs.60%29.aspx so the *ideal* situation i feel would be to use a shortened version of that, with the env variable "HELLO" printf'd out. if python popen returns "world", the test can be deemed to be successful. the less-than-ideal situation would be, rather than to skip the test, to use command.com or cmd.exe under win32 rather than executing /bin/sh... ... but the irony is that even if you did that, you would run into the same bug because the os.environ.clear() destroys the COMSPEC environment variable! soooOoo.. to fix that, you'd need to record the COMSPEC environment variable just before the os.environ.clear() and re-establish it prior to the popen. so it's a tricky one! * the ideal test is to actually compile up some c code. that would however mean shipping a binary with the python distribution as part of the test suite [eek! there must be other solutions...] * the less-than-ideal test is to use a pre-existing application, but then you have to work out, on a per-supported-platform basis, an OS-specific method of echoing an environment variable * the least perfect method is to skip the test entirely on platforms that don't have /bin/sh, but then you have the situation where the regression tests aren't actually doing their job, thus defeating the goal of python being a platform-independent environment because you can't rely on code working across all platforms. tricky one! ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5051> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
