Project

General

Profile

Actions

Feature #82559

closed

Configurable discovery (path/name) in CommandUtility for tools like python

Added by Stefan Neufeind about 7 years ago. Updated almost 7 years ago.

Status:
Rejected
Priority:
Should have
Assignee:
-
Category:
System/Bootstrap/Configuration
Target version:
-
Start date:
2017-09-25
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

In typo3/sysext/core/Classes/Utility/CommandUtility.php holds list of self::$applications which specify on how to call that binary. So as soon as an extension (like EXT:sphinx) wants to call "python" it has a central point to find a path and possibly also name for that binary.

On some systems the autodetection might fail. Or you might have several versions installed in parallel which have a slightly changed binary name. For older CentOS-version for example there is a python-version 3.4 that can be installed in parallel but "python" is still the original 2.x-version and "python3.4" is the one for python 3.4.

We should invent some way to configure certain commands for which not to use auto-detection but instead provide a fixed path/name. And/or we might want to create a hook where an extension could offer such functionality.

Actions #1

Updated by Stefan Neufeind about 7 years ago

Hack for that mentioned case where "python3.4" needs to be called instead:

// Unix-like OS
$filePath = realpath($path . $cmd);
if ($filePath && @is_executable($filePath)) {
if ($cmd == 'python') {
self::$applications[$cmd]['app'] = 'python3.4';
} else {
self::$applications[$cmd]['app'] = $cmd;
}
self::$applications[$cmd]['path'] = $path;
self::$applications[$cmd]['valid'] = true;
return true;
}
Actions #2

Updated by Bernd Wilke about 7 years ago

As far as I understand these special assignements are dependend on server (or installation).
So this array should be configurable instead of hardcoded in the core.

Actions #3

Updated by Stefan Neufeind about 7 years ago

Sure it should. The question stands if we want to have such configuration-options provided by the core or find that "nobody needed it so far" so that a hook-point for an extension would suffice.

Actions #4

Updated by Nicole Cordes almost 7 years ago

  • Status changed from New to Needs Feedback

Hi Stefan,

As far as I understand your problem, you want to configure SYS -> binSetup. I think your configuration is already possible. Am I right?

Actions #5

Updated by Stefan Neufeind almost 7 years ago

  • Status changed from Needs Feedback to Rejected

Oh, great! Works as expected. Tested on CentOS 6 with TYPO3 6.2.x and CentOS 7 with TYPO3 8 LTS - where using binSetup worked fine to point them to a python3.4. Although Sphinx said it should work on a Python 2.7 it didn't work for me with the 2.7-version that CentOS 7 ships (default-python). But they also have a python34.

Actions

Also available in: Atom PDF