test_commands assumes ls is in /bin

[prjsf]

BPO	497160
Nosy	@mwhudson, @gvanrossum, @sjoerdmullender, @freddrake

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/freddrake'
closed_at = <Date 2002-04-01.23:58:00.000>
created_at = <Date 2001-12-27.21:38:45.000>
labels = ['build']
title = 'test_commands assumes ls is in /bin'
updated_at = <Date 2002-04-01.23:58:00.000>
user = 'https://bugs.python.org/prjsf'

bugs.python.org fields:

activity = <Date 2002-04-01.23:58:00.000>
actor = 'fdrake'
assignee = 'fdrake'
closed = True
closed_date = None
closer = None
components = ['Build']
creation = <Date 2001-12-27.21:38:45.000>
creator = 'prjsf'
dependencies = []
files = []
hgrepos = []
issue_num = 497160
keywords = []
message_count = 11.0
messages = ['8513', '8514', '8515', '8516', '8517', '8518', '8519', '8520', '8521', '8522', '8523']
nosy_count = 5.0
nosy_names = ['mwh', 'gvanrossum', 'sjoerd', 'fdrake', 'prjsf']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue497160'
versions = ['Python 2.2']

[prjsf]

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".

[gvanrossum]

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.

[prjsf]

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?

[gvanrossum]

Logged In: YES
user_id=6380

If the patch is so simple, why don't you provide it?

[sjoerdmullender]

Logged In: YES
user_id=43607

This bug report is related to [ bpo-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.

[gvanrossum]

Logged In: YES
user_id=6380

OK, reopening.

[gvanrossum]

Logged In: YES
user_id=6380

Assigned to Fred Drake, who wrote the test suite.

[prjsf]

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.

[prjsf]

Logged In: YES
user_id=412110

This problem still exists in 2.2.1c2. Is there something wrong
with my patch?