chutney fails on systems with python2, but no python

I forgot brackets when I rewrite the command checks.

added component::core tor/chutney owner::nickm priority::medium resolution::fixed severity::normal status::closed type::defect labels

See my branch bug17631-python on https://github.com/teor2345/chutney.git

Trac:
Status: new to needs_review

Replying to teor:

See my branch bug17631-python on https://github.com/teor2345/chutney.git

I'm rewriting the Python detection to use a loop and run through a list of python versions which easier to extend with future Python releases and less error-prone than the current one-liner.

During the rewrite i stumbled upon

# Use python2 if the checks that use "command" fail
${PYTHON:=python2} -m chutney.TorNet "$@

which is at the end of the chutney shell script. I believe this isn't going to work if the previous command checks didn't find python2 already. Isn't it better to display an error message and abort further execution of Chutney?

Trac:
Status: needs_review to needs_information

It's a last-ditch measure in case "command" is broken in the shell.

Replying to teor:

It's a last-ditch measure in case "command" is broken in the shell. I get what it's trying to do but I'm doubting it's effectiveness. Are there shells where command is broken?

Replying to cypherpunks:

Replying to teor:

It's a last-ditch measure in case "command" is broken in the shell. I get what it's trying to do but I'm doubting it's effectiveness. Are there shells where command is broken?

It's hard to say, but historically, different shells used different builtins to implement the functionality of "command".

So any shell that only conforms to Issue 3 of "The Open Group Base Specifications", and any shell that doesn't fully conform to Issues 4 and onwards when implementing "command".

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html

And perhaps there are environments where the configuration breaks "command", but not normal execution. For example, if you delete /usr/bin/command on my machine, it stops working for some reason.

Trac:
Status: needs_information to needs_revision

I have looked into how Autoconf checks for programs in order to avoid the possible issues with command.

Autoconf can check for programs through the AC_CHECK_PROG function (which is implemented in _AC_CHECK_PROG) which uses _AS_PATH_WALK for walking through PATH and AS_EXECUTABLE_P (which is implemented in _AS_TEST_PREPARE) for checking if the file is an executable regular file.

As these functions do not use command i believe this may be the solution for checking for Python versions in a portable fashion. If you agree i will change the Python detection to use this solution.

Sure, that sounds ok.

Trac:
0001-Rewrite-Python-detection-in-Chutney-shell-script.patch

Here's a patch for review.

I have removed detection for Python 3 since it was commented out already. It can be added again by adding it the binaries variable once #16904 (moved) is fixed.

Additionally i found PEP-0394 which has some recommendations on how to maintain cross-platform support now that Arch Linux links python to python3. I believe that in our case that means we should change the detection order to python2 python3 python once #16904 (moved) is fixed.

Trac:
Status: needs_revision to needs_review

Thanks, looks good, let's get this merged!

Merged it; thanks!

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

closed

moved to tpo/core/chutney#17631 (closed)