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.