homepage

I got this test failure while building Python 2.2:
test test_commands failed -- Traceback (most recent
call last):
 File "./Lib/test/test_commands.py", line 43, in
test_getstatus
 self.assert_(re.match(pat, getstatus("/bin/ls"),
re.VERBOSE))
 File
"/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py",
line 262, in failUnless
 if not expr: raise self.failureException, msg
AssertionError
My ls happens to be somewhere other than /bin. It would
be nice if the test used a different file, such as "/",
".", or even "./Lib/test/test_commands.py".

Logged In: YES 
user_id=6380
I think you are going to get in a lot of trouble when
/bin/ls doesn't exist. It's not worth fixing the test suite
for this.

Logged In: YES 
user_id=412110
The test suite already uses $PATH to *run* ls (as does other
software, which is why I don't get into a lot of trouble).
It merely uses /bin/ls as a filename to pass to ls so it can
check the output. Any other filename will do just as well
here, and the fix is extremely simple; what's the benefit of
listing /bin/ls in particular that makes it worth risk
breaking on systems like this?

Logged In: YES 
user_id=6380
If the patch is so simple, why don't you provide it?

Logged In: YES 
user_id=43607
This bug report is related to [ #460613 ] test_commands fails on SGI, which nobody ever seems to have noticed 
and which is still open.
The problem there is that /bin/ls *does* exist, but is a symlink.

Logged In: YES 
user_id=6380
OK, reopening.

Logged In: YES 
user_id=6380
Assigned to Fred Drake, who wrote the test suite.

Logged In: YES 
user_id=412110
Sorry, I should have thought of providing a patch to begin
with.
<URL:http://multivac.cwru.edu./prj/python-test-commands.patch>
This regexp test is weaker than the original one, but seems to 
be still stronger than necessary. If ls is broken here, we
don't care, because it isn't part of Python. All wee need is
to be able to spawn a shell.

Logged In: YES 
user_id=412110
This problem still exists in 2.2.1c2. Is there something wrong
with my patch?

Logged In: YES 
user_id=6656
No attempt was made to fix this for 2.2.1c2.
I didn't make fixing little bugs in the tests a priority, 
sorry.
I don't think it's been fixed on the trunk.

Logged In: YES 
user_id=3066
Checked in patch as provided in Lib/test/test_commands.py
revision 1.4; closed bug #460613 as well.