Chapter 19. Installing and using dynamic programming languages

19.1. Introduction to Python

Python is a high-level programming language that supports multiple programming paradigms, such as object-oriented, imperative, functional, and procedural paradigms. Python has dynamic semantics and can be used for general-purpose programming.

With Red Hat Enterprise Linux, many packages that are installed on the system, such as packages providing system tools, tools for data analysis, or web applications, are written in Python. To use these packages, you must have the python* packages installed.

19.1.1. Python versions

Two incompatible versions of Python are widely used, Python 2.x and Python 3.x. RHEL 8 provides the following versions of Python.

Table 19.1. Python versions in RHEL 8
Version	Package to install	Command examples	Available since	Life cycle
Python 3.6	`python3`, `python36`	`python3`, `python3.6`, `pip3`, `pip3.6`	RHEL 8.0	full RHEL 8
Python 2.7	`python2`	`python2`, `pip2`	RHEL 8.0	shorter
Python 3.8	`python38`	`python3.8`, `pip3.8`	RHEL 8.2	shorter
Python 3.9	`python39`	`python3.9`, `pip3.9`	RHEL 8.4	shorter
Python 3.11	`python3.11`	`python3.11`, `pip3.11`	RHEL 8.8	shorter
Python 3.12	`python3.12`	`python3.12`, `pip3.12`	RHEL 8.10	shorter

For details about the length of support, see Red Hat Enterprise Linux Life Cycle and Red Hat Enterprise Linux Application Streams Life Cycle.

Each of the Python versions up to 3.9 is distributed in a separate module. Python 3.11 and Python 3.12 are distributed as suites of non-modular RPM packages, including the python3.11 and python3.12 packages.

You can install multiple Python versions in parallel on the same RHEL 8 system.

Important

Always specify the version of Python when installing it, invoking it, or otherwise interacting with it. For example, use python3 instead of python in package and command names. All Python-related commands must also include the version, for example, pip3, pip2, pip3.8, pip3.9, pip3.11, or pip3.12.

The unversioned python command (/usr/bin/python) is not available by default in RHEL 8. You can configure it using the alternatives command; for instructions, see Configuring the unversioned Python

Any manual changes to /usr/bin/python, except changes made using the alternatives command, might be overwritten upon an update.

As a system administrator, use Python 3 for the following reasons:

Python 3 represents the main development direction of the Python project.
Support for Python 2 in the upstream community ended in 2020.
Popular Python libraries are discontinuing Python 2 support in upstream.
Python 2 in Red Hat Enterprise Linux 8 will have a shorter life cycle and aims to facilitate a smoother transition to Python 3 for customers.

For developers, Python 3 has the following advantages over Python 2:

Python 3 enables you to write expressive, maintainable, and correct code more easily.
Code written in Python 3 will have greater longevity.
Python 3 has new features, including asyncio, f-strings, advanced unpacking, keyword-only arguments, and chained exceptions.

However, legacy software might require /usr/bin/python to be configured to Python 2. For this reason, no default python package is distributed with Red Hat Enterprise Linux 8, and you can choose between using Python 2 and 3 as /usr/bin/python, as described in Configuring the unversioned Python.

Important

System tools in Red Hat Enterprise Linux 8 use Python version 3.6 provided by the internal platform-python package, which is not intended to be used directly by customers. It is recommended to use the python3 or python3.6 command from the python36 package for Python 3.6, or to use later Python versions.

Do not remove the platform-python package from RHEL 8 because other packages require it.

19.1.2. Notable differences between Python versions

Python versions included in RHEL 8 differ in various aspects.

Python bindings

The python38 and python39 modules and the python3.11 and python3.12 package suites do not include the same bindings to system tools (RPM, DNF, SELinux, and others) that are provided for the python36 module. Therefore, use python36 in instances where the greatest compatibility with the base operating system or binary compatibility is necessary. In unique instances where system bindings are necessary together with later versions of various Python modules, use the python36 module in combination with third-party upstream Python modules installed through pip into Python’s venv or virtualenv environments.

Python 3.11 and Python 3.12 virtual environments must be created using venv instead of virtualenv

The virtualenv utility in RHEL 8, provided by the python3-virtualenv package, is not compatible with Python 3.11 and Python 3.12. An attempt to create a virtual environment by using virtualenv will fail with an error message, for example:

$ virtualenv -p python3.11 venv3.11
Running virtualenv with interpreter /usr/bin/python3.11
ERROR: Virtual environments created by virtualenv < 20 are not compatible with Python 3.11.
ERROR: Use python3.11 -m venv instead.

To create Python 3.11 or Python 3.12 virtual environments, use the python3.11 -m venv or python3.12 -m venv commands instead, which use the venv module from the standard library.

19.2. Installing and using Python

In Red Hat Enterprise Linux 8, Python 3 is distributed in versions 3.6, 3.8, and 3.9, provided by the python36, python38, and python39 modules, and the python3.11 and python3.12 package suites in the AppStream repository.

Warning

Using the unversioned python command to install or run Python does not work by default due to ambiguity. Always specify the version of Python, or configure the system default version by using the alternatives command.

19.2.1. Installing Python 3

By design, you can install RHEL 8 modules in parallel, including the python27, python36, python38, and python39 modules, and the python3.11 and python3.12 package suites.

You can install Python 3.8, Python 3.9, Python 3.11, and Python 3.12, including packages built for each version, in parallel with Python 3.6 on the same system, with the exception of the mod_wsgi module. Due to a limitation of the Apache HTTP Server, only one of the python3-mod_wsgi, python38-mod_wsgi, python39-mod_wsgi, python3.11-mod_wsgi, or python3.12-mod_wsgi packages can be installed on a system.

Procedure

To install Python 3.6 from the python36 module, use:
```
# yum install python3
```
The python36:3.6 module stream is enabled automatically.
To install Python 3.8 from the python38 module, use:
```
# yum install python38
```
The python38:3.8 module stream is enabled automatically.
To install Python 3.9 from the python39 module, use:
```
# yum install python39
```
The python39:3.9 module stream is enabled automatically.
To install Python 3.11 from the python3.11 RPM package, use:
```
# yum install python3.11
```
To install Python 3.12 from the python3.12 RPM package, use:
```
# yum install python3.12
```

Verification steps

To verify the Python version installed on your system, use the --version option with the python command specific for your required version of Python.
- For Python 3.6:
```
$ python3 --version
```
- For Python 3.8:
```
$ python3.8 --version
```
- For Python 3.9:
```
$ python3.9 --version
```
- For Python 3.11:
```
$ python3.11 --version
```
- For Python 3.12:
```
$ python3.12 --version
```

Additional resources

Installing, managing, and removing user-space components

19.2.2. Installing additional Python 3 packages

Packages with add-on modules for Python 3.6 generally use the python3- prefix, packages for Python 3.8 include the python38- prefix, packages for Python 3.9 include the python39- prefix, packages for Python 3.11 include the python3.11- prefix, and packages for Python 3.12 include the python3.12- prefix. Always include the prefix when installing additional Python packages, as shown in the examples below.

Procedure

To install the Requests module for Python 3.6, use:
```
# yum install python3-requests
```
To install the Cython extension to Python 3.8, use:
```
# yum install python38-Cython
```
To install the pip package installer from Python 3.9, use:
```
# yum install python39-pip
```
To install the pip package installer from Python 3.11, use:
```
# yum install python3.11-pip
```
To install the pip package installer from Python 3.12, use:
```
# yum install python3.12-pip
```

Additional resources

Upstream documentation about Python add-on modules

19.2.3. Installing additional Python 3 tools for developers

Additional Python tools for developers are distributed mostly through the CodeReady Linux Builder (CRB) repository in the respective python38-devel or python39-devel module, or the python3.11-* or python3.12-* packages.

The python3-pytest package (for Python 3.6) and its dependencies are available in the AppStream repository.

The CRB repository provides:

The python38-devel module, which contains the python38-pytest package and its dependencies.
The python39-devel module, which contains the python39-pytest package and its dependencies, and the python39-debug and python39-Cython packages.
The python3.11-* packages, which include:
- python3.11-pytest and its dependencies
- python3.11-idle
- python3.11-debug
- python3.11-Cython
The python3.12-* packages, which include a similar set of packages as python3.11-*.

Important

The content in the CodeReady Linux Builder repository is unsupported by Red Hat.

Note

Not all upstream Python-related packages are available in RHEL.

To install the python3*-pytest package, use the following procedure.

Procedure

For Python 3.8 and later, enable the CodeReady Linux Builder repository:

# subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms

For Python 3.8 or 3.9, enable the respective python3*-devel module, for example:
```
# yum module enable python39-devel
```

Install the python3*-pytest package:

For Python 3.6:
```
# yum install python3-pytest
```
For Python 3.8:
```
# yum install python38-pytest
```
For Python 3.9:
```
# yum install python39-pytest
```
For Python 3.11:
```
# yum install python3.11-pytest
```
For Python 3.12:
```
# yum install python3.12-pytest
```

Additional resources

19.2.4. Installing Python 2

Some applications and scripts have not yet been fully ported to Python 3 and require Python 2 to run. Red Hat Enterprise Linux 8 allows parallel installation of Python 3 and Python 2. If you need the Python 2 functionality, install the python27 module, which is available in the AppStream repository.

Warning

Note that Python 3 is the main development direction of the Python project. Support for Python 2 is being phased out. The python27 module has a shorter support period than Red Hat Enterprise Linux 8.

Procedure

To install Python 2.7 from the python27 module, use:
```
# yum install python2
```
The python27:2.7 module stream is enabled automatically.

Packages with add-on modules for Python 2 generally use the python2- prefix. Always include the prefix when installing additional Python packages, as shown in the examples below.

To install the Requests module for Python 2, use:
```
# yum install python2-requests
```
To install the Cython extension to Python 2, use:
```
# yum install python2-Cython
```

Verification steps

To verify the Python version installed on your system, use:
```
$ python2 --version
```

Note

By design, you can install RHEL 8 modules in parallel, including the python27, python36, python38, and python39 modules.

Additional resources

Installing, managing, and removing user-space components in RHEL 8

19.2.5. Migrating from Python 2 to Python 3

As a developer, you may want to migrate your former code that is written in Python 2 to Python 3.

For more information about how to migrate large code bases to Python 3, see The Conservative Python 3 Porting Guide.

Note that after this migration, the original Python 2 code becomes interpretable by the Python 3 interpreter and stays interpretable for the Python 2 interpreter as well.

19.2.6. Using Python

When running the Python interpreter or Python-related commands, always specify the version.

Prerequisites

Ensure that the required version of Python is installed.
If you want to download and install third-party applications for Python 3.11 or Python 3.12, install the python3.11-pip or python3.12-pip package.

Procedure

To run the Python 3.6 interpreter or related commands, use, for example:

$ python3
$ python3 -m venv --help
$ python3 -m pip install package
$ pip3 install package

To run the Python 3.8 interpreter or related commands, use, for example:

$ python3.8
$ python3.8 -m venv --help
$ python3.8 -m pip install package
$ pip3.8 install package

To run the Python 3.9 interpreter or related commands, use, for example:

$ python3.9
$ python3.9 -m venv --help
$ python3.9 -m pip install package
$ pip3.9 install package

To run the Python 3.11 interpreter or related commands, use, for example:

$ python3.11
$ python3.11 -m venv --help
$ python3.11 -m pip install package
$ pip3.11 install package

To run the Python 3.12 interpreter or related commands, use, for example:

$ python3.12
$ python3.12 -m venv --help
$ python3.12 -m pip install package
$ pip3.12 install package

To run the Python 2 interpreter or related commands, use, for example:

$ python2
$ python2 -m pip install package
$ pip2 install package

19.3. Configuring the unversioned Python

System administrators can configure the unversioned python command, located at /usr/bin/python, using the alternatives command. Note that the required package, python3, python38, python39, python3.11, python3.12, or python2, must be installed before configuring the unversioned command to the respective version.

Important

The /usr/bin/python executable is controlled by the alternatives system. Any manual changes may be overwritten upon an update.

Additional Python-related commands, such as pip3, do not have configurable unversioned variants.

19.3.1. Configuring the unversioned python command directly

You can configure the unversioned python command directly to a selected version of Python.

Prerequisites

Ensure that the required version of Python is installed.

Procedure

To configure the unversioned python command to Python 3.6, use:
```
# alternatives --set python /usr/bin/python3
```
To configure the unversioned python command to Python 3.8, use:
```
# alternatives --set python /usr/bin/python3.8
```
To configure the unversioned python command to Python 3.9, use:
```
# alternatives --set python /usr/bin/python3.9
```
To configure the unversioned python command to Python 3.11, use:
```
# alternatives --set python /usr/bin/python3.11
```
To configure the unversioned python command to Python 3.12, use:
```
# alternatives --set python /usr/bin/python3.12
```
To configure the unversioned python command to Python 2, use:
```
# alternatives --set python /usr/bin/python2
```

19.3.2. Configuring the unversioned python command to the required Python version interactively

You can configure the unversioned python command to the required Python version interactively.

Prerequisites

Ensure that the required version of Python is installed.

Procedure

To configure the unversioned python command interactively, use:
```
# alternatives --config python
```
Select the required version from the provided list.
To reset this configuration and remove the unversioned python command, use:
```
# alternatives --auto python
```

19.3.3. Additional resources

alternatives(8) and unversioned-python(1) man pages

19.4. Packaging Python 3 RPMs

Most Python projects use Setuptools for packaging, and define package information in the setup.py file. For more information about Setuptools packaging, see the Setuptools documentation.

You can also package your Python project into an RPM package, which provides the following advantages compared to Setuptools packaging:

Specification of dependencies of a package on other RPMs (even non-Python)
Cryptographic signing
With cryptographic signing, content of RPM packages can be verified, integrated, and tested with the rest of the operating system.

19.4.1. The spec file description for a Python package

A spec file contains instructions that the rpmbuild utility uses to build an RPM. The instructions are included in a series of sections. A spec file has two main parts in which the sections are defined:

Preamble (contains a series of metadata items that are used in the Body)
Body (contains the main part of the instructions)

An RPM SPEC file for Python projects has some specifics compared to non-Python RPM SPEC files. Most notably, a name of any RPM package of a Python library must always include the prefix determining the version, for example, python3 for Python 3.6, python38 for Python 3.8, python39 for Python 3.9, python3.11 for Python 3.11, or python3.12 for Python 3.12.

Other specifics are shown in the following spec file example for the python3-detox package. For description of such specifics, see the notes below the example.

%global modname detox                                                1

Name:           python3-detox                                        2
Version:        0.12
Release:        4%{?dist}
Summary:        Distributing activities of the tox tool
License:        MIT
URL:            https://pypi.io/project/detox
Source0:        https://pypi.io/packages/source/d/%{modname}/%{modname}-%{version}.tar.gz

BuildArch:      noarch

BuildRequires:  python36-devel                                       3
BuildRequires:  python3-setuptools
BuildRequires:  python36-rpm-macros
BuildRequires:  python3-six
BuildRequires:  python3-tox
BuildRequires:  python3-py
BuildRequires:  python3-eventlet

%?python_enable_dependency_generator                                 4

%description

Detox is the distributed version of the tox python testing tool. It makes efficient use of multiple CPUs by running all possible activities in parallel.
Detox has the same options and configuration that tox has, so after installation you can run it in the same way and with the same options that you use for tox.

    $ detox

%prep
%autosetup -n %{modname}-%{version}

%build
%py3_build                                                           5

%install
%py3_install

%check
%{__python3} setup.py test                                           6

%files -n python3-%{modname}
%doc CHANGELOG
%license LICENSE
%{_bindir}/detox
%{python3_sitelib}/%{modname}/
%{python3_sitelib}/%{modname}-%{version}*

%changelog
...

1: The modname macro contains the name of the Python project. In this example it is detox.
2: When packaging a Python project into RPM, the python3 prefix always needs to be added to the original name of the project. The original name here is detox and the name of the RPM is python3-detox.
3: BuildRequires specifies what packages are required to build and test this package. In BuildRequires, always include items providing tools necessary for building Python packages: python36-devel and python3-setuptools. The python36-rpm-macros package is required so that files with /usr/bin/python3 interpreter directives are automatically changed to /usr/bin/python3.6.
4: Every Python package requires some other packages to work correctly. Such packages need to be specified in the spec file as well. To specify the dependencies, you can use the %python_enable_dependency_generator macro to automatically use dependencies defined in the setup.py file. If a package has dependencies that are not specified using Setuptools, specify them within additional Requires directives.
5: The %py3_build and %py3_install macros run the setup.py build and setup.py install commands, respectively, with additional arguments to specify installation locations, the interpreter to use, and other details.
6: The check section provides a macro that runs the correct version of Python. The %{__python3} macro contains a path for the Python 3 interpreter, for example /usr/bin/python3. We recommend to always use the macro rather than a literal path.

19.4.2. Common macros for Python 3 RPMs

In a spec file, always use the macros that are described in the following Macros for Python 3 RPMs table rather than hardcoding their values.

In macro names, always use python3 or python2 instead of unversioned python. Configure the particular Python 3 version in the BuildRequires section of the SPEC file to python36-rpm-macros, python38-rpm-macros, python39-rpm-macros, python3.11-rpm-macros, or python3.12-rpm-macros.

Table 19.2. Macros for Python 3 RPMs
Macro	Normal Definition	Description
%{__python3}	/usr/bin/python3	Python 3 interpreter
%{python3_version}	3.6	The full version of the Python 3 interpreter.
%{python3_sitelib}	/usr/lib/python3.6/site-packages	Where pure-Python modules are installed.
%{python3_sitearch}	/usr/lib64/python3.6/site-packages	Where modules containing architecture-specific extensions are installed.
%py3_build		Runs the `setup.py build` command with arguments suitable for a system package.
%py3_install		Runs the `setup.py install` command with arguments suitable for a system package.

19.4.3. Automatic provides for Python RPMs

When packaging a Python project, make sure that the following directories are included in the resulting RPM if these directories are present:

.dist-info
.egg-info
.egg-link

From these directories, the RPM build process automatically generates virtual pythonX.Ydist provides, for example, python3.6dist(detox). These virtual provides are used by packages that are specified by the %python_enable_dependency_generator macro.

19.5. Handling interpreter directives in Python scripts

In Red Hat Enterprise Linux 8, executable Python scripts are expected to use interpreter directives (also known as hashbangs or shebangs) that explicitly specify at a minimum the major Python version. For example:

#!/usr/bin/python3
#!/usr/bin/python3.6
#!/usr/bin/python3.8
#!/usr/bin/python3.9
#!/usr/bin/python3.11
#!/usr/bin/python3.12
#!/usr/bin/python2

The /usr/lib/rpm/redhat/brp-mangle-shebangs buildroot policy (BRP) script is run automatically when building any RPM package, and attempts to correct interpreter directives in all executable files.

The BRP script generates errors when encountering a Python script with an ambiguous interpreter directive, such as:

#!/usr/bin/python

or

#!/usr/bin/env python

19.5.1. Modifying interpreter directives in Python scripts

Modify interpreter directives in the Python scripts that cause the build errors at RPM build time.

Prerequisites

Some of the interpreter directives in your Python scripts cause a build error.

Procedure

To modify interpreter directives, complete one of the following tasks:

Apply the pathfix.py script from the platform-python-devel package:
```
# pathfix.py -pn -i %{__python3} PATH …
```
Note that multiple PATHs can be specified. If a PATH is a directory, pathfix.py recursively scans for any Python scripts matching the pattern ^[a-zA-Z0-9_]+\.py$, not only those with an ambiguous interpreter directive. Add this command to the %prep section or at the end of the %install section.
Modify the packaged Python scripts so that they conform to the expected format. For this purpose, pathfix.py can be used outside the RPM build process, too. When running pathfix.py outside an RPM build, replace %{__python3} from the example above with a path for the interpreter directive, such as /usr/bin/python3.

If the packaged Python scripts require a version other than Python 3.6, adjust the preceding commands to include the required version.

19.5.2. Changing /usr/bin/python3 interpreter directives in your custom packages

By default, interpreter directives in the form of /usr/bin/python3 are replaced with interpreter directives pointing to Python from the platform-python package, which is used for system tools with Red Hat Enterprise Linux. You can change the /usr/bin/python3 interpreter directives in your custom packages to point to a specific version of Python that you have installed from the AppStream repository.

Procedure

To build your package for a specific version of Python, add the python*-rpm-macros subpackage of the respective python package to the BuildRequires section of the spec file. For example, for Python 3.6, include the following line:
```
BuildRequires:  python36-rpm-macros
```
As a result, the /usr/bin/python3 interpreter directives in your custom package are automatically converted to /usr/bin/python3.6.

Note

To prevent the BRP script from checking and modifying interpreter directives, use the following RPM directive:

%undefine __brp_mangle_shebangs

19.6. Using the PHP scripting language

Hypertext Preprocessor (PHP) is a general-purpose scripting language mainly used for server-side scripting, which enables you to run the PHP code using a web server.

In RHEL 8, the PHP scripting language is provided by the php module, which is available in multiple streams (versions).

Depending on your use case, you can install a specific profile of the selected module stream:

common - The default profile for server-side scripting using a web server. It includes several widely used extensions.
minimal - This profile installs only the command-line interface for scripting with PHP without using a web server.
devel - This profile includes packages from the common profile and additional packages for development purposes.

19.6.1. Installing the PHP scripting language

You can install a selected version of the php module.

Procedure

To install a php module stream with the default profile, use:
```
# yum module install php:stream
```
Replace stream with the version of PHP you wish to install.
For example, to install PHP 8.0:
```
# yum module install php:8.0
```
The default common profile installs also the php-fpm package, and preconfigures PHP for use with the Apache HTTP Server or nginx.
To install a specific profile of a php module stream, use:
```
# yum module install php:stream/profile
```
Replace stream with the desired version and profile with the name of the profile you wish to install.
For example, to install PHP 8.0 for use without a web server:
```
# yum module install php:8.0/minimal
```

Additional resources

If you want to upgrade from an earlier version of PHP available in RHEL 8, see Switching to a later stream.
For more information about managing RHEL 8 modules and streams, see Installing, managing, and removing user-space components.

19.6.2. Using the PHP scripting language with a web server

19.6.2.1. Using PHP with the Apache HTTP Server

In Red Hat Enterprise Linux 8, the Apache HTTP Server enables you to run PHP as a FastCGI process server. FastCGI Process Manager (FPM) is an alternative PHP FastCGI daemon that allows a website to manage high loads. PHP uses FastCGI Process Manager by default in RHEL 8.

You can run the PHP code using the FastCGI process server.

Prerequisites

The PHP scripting language is installed on your system.
See Installing the PHP scripting language.

Procedure

Install the httpd module:
```
# yum module install httpd:2.4
```
Start the Apache HTTP Server:
```
# systemctl start httpd
```
Or, if the Apache HTTP Server is already running on your system, restart the httpd service after installing PHP:
```
# systemctl restart httpd
```
Start the php-fpm service:
```
# systemctl start php-fpm
```
Optional: Enable both services to start at boot time:
```
# systemctl enable php-fpm httpd
```
To obtain information about your PHP settings, create the index.php file with the following content in the /var/www/html/ directory:
```
# echo '<?php phpinfo(); ?>' > /var/www/html/index.php
```
To run the index.php file, point the browser to:
```
http://<hostname>/
```
Optional: Adjust configuration if you have specific requirements:
- /etc/httpd/conf/httpd.conf - generic httpd configuration
- /etc/httpd/conf.d/php.conf - PHP-specific configuration for httpd
- /usr/lib/systemd/system/httpd.service.d/php-fpm.conf - by default, the php-fpm service is started with httpd
- /etc/php-fpm.conf - FPM main configuration
- /etc/php-fpm.d/www.conf - default www pool configuration

Example 19.1. Running a "Hello, World!" PHP script using the Apache HTTP Server

Create a hello directory for your project in the /var/www/html/ directory:
```
# mkdir hello
```

Create a hello.php file in the /var/www/html/hello/ directory with the following content:

# <!DOCTYPE html>
<html>
<head>
<title>Hello, World! Page</title>
</head>
<body>
<?php
    echo 'Hello, World!';
?>
</body>
</html>

Start the Apache HTTP Server:
```
# systemctl start httpd
```
To run the hello.php file, point the browser to:
```
http://<hostname>/hello/hello.php
```
As a result, a web page with the “Hello, World!” text is displayed.

Additional resources

Setting up the Apache HTTP web server

19.6.2.2. Using PHP with the nginx web server

You can run PHP code through the nginx web server.

Prerequisites

The PHP scripting language is installed on your system.
See Installing the PHP scripting language.

Procedure

Install an nginx module stream:
```
# yum module install nginx:stream
```
Replace stream with the version of nginx you wish to install.
For example, to install nginx version 1.18:
```
# yum module install nginx:1.18
```
Start the nginx server:
```
# systemctl start nginx
```
Or, if the nginx server is already running on your system, restart the nginx service after installing PHP:
```
# systemctl restart nginx
```
Start the php-fpm service:
```
# systemctl start php-fpm
```
Optional: Enable both services to start at boot time:
```
# systemctl enable php-fpm nginx
```
To obtain information about your PHP settings, create the index.php file with the following content in the /usr/share/nginx/html/ directory:
```
# echo '<?php phpinfo(); ?>' > /usr/share/nginx/html/index.php
```
To run the index.php file, point the browser to:
```
http://<hostname>/
```
Optional: Adjust configuration if you have specific requirements:
- /etc/nginx/nginx.conf - nginx main configuration
- /etc/nginx/conf.d/php-fpm.conf - FPM configuration for nginx
- /etc/php-fpm.conf - FPM main configuration
- /etc/php-fpm.d/www.conf - default www pool configuration

Example 19.2. Running a "Hello, World!" PHP script using the nginx server

Create a hello directory for your project in the /usr/share/nginx/html/ directory:
```
# mkdir hello
```

Create a hello.php file in the /usr/share/nginx/html/hello/ directory with the following content:

# <!DOCTYPE html>
<html>
<head>
<title>Hello, World! Page</title>
</head>
<body>
<?php
    echo 'Hello, World!';
?>
</body>
</html>

Start the nginx server:
```
# systemctl start nginx
```
To run the hello.php file, point the browser to:
```
http://<hostname>/hello/hello.php
```
As a result, a web page with the “Hello, World!” text is displayed.

Additional resources

Setting up and configuring NGINX

19.6.3. Running a PHP script using the command-line interface

A PHP script is usually run using a web server, but also can be run using the command-line interface.

If you want to run php scripts using only command-line, install the minimal profile of a php module stream.

See Installing the PHP scripting language.

Prerequisites

The PHP scripting language is installed on your system.
See Installing the PHP scripting language.

Procedure

In a text editor, create a filename.php file
Replace filename with the name of your file.
Execute the created filename.php file from the command line:
```
# php filename.php
```

Example 19.3. Running a "Hello, World!" PHP script using the command-line interface

Create a hello.php file with the following content using a text editor:
```
<?php
    echo 'Hello, World!';
?>
```
Execute the hello.php file from the command line:
```
# php hello.php
```
As a result, “Hello, World!” is printed.

19.6.4. Additional resources

httpd(8) — The manual page for the httpd service containing the complete list of its command-line options.
httpd.conf(5) — The manual page for httpd configuration, describing the structure and location of the httpd configuration files.
nginx(8) — The manual page for the nginx web server containing the complete list of its command-line options and list of signals.
php-fpm(8) — The manual page for PHP FPM describing the complete list of its command-line options and configuration files.

19.7. Getting started with Tcl/Tk

19.7.1. Introduction to Tcl/Tk

Tool command language (Tcl) is a dynamic programming language. The interpreter for this language, together with the C library, is provided by the tcl package.

Using Tcl paired with Tk (Tcl/Tk) enables creating cross-platform GUI applications. Tk is provided by the tk package.

Note that Tk can refer to any of the following:

A programming toolkit for multiple languages
A Tk C library bindings available for multiple languages, such as C, Ruby, Perl and Python
A wish interpreter that instantiates a Tk console
A Tk extension that adds a number of new commands to a particular Tcl interpreter

For more information about Tcl/Tk, see the Tcl/Tk manual or Tcl/Tk documentation web page.

19.7.2. Notable changes in Tcl/Tk 8.6

Red Hat Enterprise Linux 7 used Tcl/Tk 8.5. With Red Hat Enterprise Linux 8, Tcl/Tk version 8.6 is provided in the Base OS repository.

Major changes in Tcl/Tk 8.6 compared to Tcl/Tk 8.5 are:

Object-oriented programming support
Stackless evaluation implementation
Enhanced exceptions handling
Collection of third-party packages built and installed with Tcl
Multi-thread operations enabled
SQL database-powered scripts support
IPv6 networking support
Built-in Zlib compression
List processing
Two new commands, lmap and dict map are available, which allow the expression of transformations over Tcl containers.
Stacked channels by script
Two new commands, chan push and chan pop are available, which allow to add or remove transformations to or from I/O channels.

Major changes in Tk include:

Built-in PNG image support
Busy windows
A new command, tk busy is available, which disables user interaction for a window or a widget and shows the busy cursor.
New font selection dialog interface
Angled text support
Moving things on a canvas support

For the detailed list of changes between Tcl 8.5 and Tcl 8.6, see Changes in Tcl/Tk 8.6.

19.7.3. Migrating to Tcl/Tk 8.6

Red Hat Enterprise Linux 7 used Tcl/Tk 8.5. With Red Hat Enterprise Linux 8, Tcl/Tk version 8.6 is provided in the Base OS repository.

This section describes migration path to Tcl/Tk 8.6 for:

Developers writing Tcl extensions or embedding Tcl interpreter into their applications
Users scripting tasks with Tcl/Tk

19.7.3.1. Migration path for developers of Tcl extensions

To make your code compatible with Tcl 8.6, use the following procedure.

Procedure

Rewrite the code to use the interp structure. For example, if your code reads interp→errorLine, rewrite it to use the following function:
```
Tcl_GetErrorLine(interp)
```
This is necessary because Tcl 8.6 limits direct access to members of the interp structure.
To make your code compatible with both Tcl 8.5 and Tcl 8.6, use the following code snippet in a header file of your C or C++ application or extension that includes the Tcl library:
```
# include <tcl.h>
# if !defined(Tcl_GetErrorLine)
# define Tcl_GetErrorLine(interp) (interp→errorLine)
# endif
```

19.7.3.2. Migration path for users scripting their tasks with Tcl/Tk

In Tcl 8.6, most scripts work the same way as with the previous version of Tcl.

To migrate you code into Tcl 8.6, use this procedure.

Procedure

When writing a portable code, make sure to not use the commands that are no longer supported in Tk 8.6:

tkIconList_Arrange
tkIconList_AutoScan
tkIconList_Btn1
tkIconList_Config
tkIconList_Create
tkIconList_CtrlBtn1
tkIconList_Curselection
tkIconList_DeleteAll
tkIconList_Double1
tkIconList_DrawSelection
tkIconList_FocusIn
tkIconList_FocusOut
tkIconList_Get
tkIconList_Goto
tkIconList_Index
tkIconList_Invoke
tkIconList_KeyPress
tkIconList_Leave1
tkIconList_LeftRight
tkIconList_Motion1
tkIconList_Reset
tkIconList_ReturnKey
tkIconList_See
tkIconList_Select
tkIconList_Selection
tkIconList_ShiftBtn1
tkIconList_UpDown

Note that you can check the list of unsupported commands also in the /usr/share/tk8.6/unsupported.tcl file.

Chapter 19. Installing and using dynamic programming languages

19.1. Introduction to Python

19.1.1. Python versions

19.1.2. Notable differences between Python versions

19.2. Installing and using Python

19.2.1. Installing Python 3

19.2.2. Installing additional Python 3 packages

19.2.3. Installing additional Python 3 tools for developers

19.2.4. Installing Python 2

19.2.5. Migrating from Python 2 to Python 3

19.2.6. Using Python

19.3. Configuring the unversioned Python

19.3.1. Configuring the unversioned python command directly

19.3.2. Configuring the unversioned python command to the required Python version interactively

19.3.3. Additional resources

19.4. Packaging Python 3 RPMs

19.4.1. The spec file description for a Python package

19.4.2. Common macros for Python 3 RPMs

19.4.3. Automatic provides for Python RPMs

19.5. Handling interpreter directives in Python scripts

19.5.1. Modifying interpreter directives in Python scripts

19.5.2. Changing /usr/bin/python3 interpreter directives in your custom packages

19.6. Using the PHP scripting language

19.6.1. Installing the PHP scripting language

19.6.2. Using the PHP scripting language with a web server

19.6.2.1. Using PHP with the Apache HTTP Server

19.6.2.2. Using PHP with the nginx web server

19.6.3. Running a PHP script using the command-line interface

19.6.4. Additional resources

19.7. Getting started with Tcl/Tk

19.7.1. Introduction to Tcl/Tk

19.7.2. Notable changes in Tcl/Tk 8.6

19.7.3. Migrating to Tcl/Tk 8.6

19.7.3.1. Migration path for developers of Tcl extensions

19.7.3.2. Migration path for users scripting their tasks with Tcl/Tk

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links