I'm using Lubuntu 11.10. I have TeXlive 2011 full insttaled.

I've just installed TeXlive 2013 running install-tl script. Everything was fine. I choose the small scheme. No problem.

So according to the guide we should do this:

After the installation finishes, you must add the directory of TeX Live binaries to your PATH—except on Windows, where the installer takes care of this. For example:


Use the syntax for your shell, your installation directory, and your binary platform name instead of i386-linux.

No problem until here. I changed my $PATH and when executing pdflatex --version on the terminal I got

pdfTeX 3.1415926-2.5-1.40.14 (TeX Live 2013) kpathsea version 6.1.1

But I'd like to know how to take care of the last suggestion:

If you have multiple TeX installations on a given machine, you need to change the search path to switch between them.

How to do that?

  • 1
    If your TL 2011 binaries are in /usr/bin, then calling /usr/bin/pdflatex will run the TL 2011 binary and use the corresponding TeX tree.
    – egreg
    Dec 21, 2013 at 16:08
  • Are you talking about other programs? for example, when I call texdoc or dvips or even tlmgr? How to fix it? Setting up the $PATH is not enough?
    – Sigur
    Dec 21, 2013 at 16:13
  • 2
    I don't understand. Setting up $PATH is surely enough for using the most recent release. You can always change it in a shell to use the old release.
    – egreg
    Dec 21, 2013 at 17:08
  • 3
    I typically install tls in /opt/texlive so the 2013 edition is in the 2013 subfolder. I also have a softlink in /opt/texlive pointing at the current tl edition. Then in the place where I have added the tl path, I refer by edition to the softlink. Thus if I have need to use another tl edition, I only have to change the softlink, I do not have to change the path.
    – daleif
    Dec 21, 2013 at 17:20
  • 1
    I do something similar. I have 2011, 2012 and 2013 each installed in /usr/local/texlive. Then I have a symbolic link /usr/local/texlive/bin which points to e.g. 2013/bin/x86_64-linux/ and a symbolic link /usr/local/texlive/current which points to e.g. 2013/. I then add /usr/local/texlive/bin to my PATH and use this link and /usr/local/texlive/current in e.g. specifying paths etc. in my editor and other software. To switch, you then just need to change the two symbolic links. Basically, this copies the way MacTeX sets things up.
    – cfr
    Dec 21, 2013 at 23:12

2 Answers 2


Suppose you have three installations of TeX on your machine, say vanilla TeX Live 2014 and 2015, along with the TeX Live provided by Ubuntu/Debian. The binaries for the three distributions will live in


where <arch> might be i386-linux, x86_64-linux or another string relative to your machine's hardware architecture.

If you set your PATH variable with

export PATH=/usr/local/texlive/2015/bin/i386-linux:$PATH

in your .profile file or with the method of adding a file in /etc/profile.d (which I recommend), then calling

pdftex --version

from a shell will show

pdfTeX 3.14159265-2.6-1.40.16 (TeX Live 2015)
kpathsea version 6.2.1

and you're sure that any TeX program will use the tree located in


This is because of how the kpathsea library, which all TeX Live programs are linked to, works: it sets a number of runtime environment variables based on the directory where the called binary lives in.

You can try seeing this by doing the following distinct calls from the shell (again, use the string for <arch> corresponding to your machine's architecture)

kpsewhich plain.tex
/usr/local/texlive/2014/bin/x86_64-linux/kpsewhich plain.tex
/usr/bin/kpsewhich plain.tex

and you'll receive three different answers:


The program kpsewhich is the public interface to the kpathsea library.

You may get into big problems if your PATH is not set in such a way that the GUI applications see the vanilla TeX Live binary directory before /usr/bin. In my test virtual machines I place a file called texlive.sh in /etc/profile.d containing

export PATH=/opt/texbin:${PATH}

and I make a symbolic link /opt/texbin pointing to the most recent TeX Live I have on the machine, by doing

sudo rm /opt/texbin
sudo ln -s /usr/local/texlive/2015/bin/x86_64-linux /opt/texbin

In this way echo $PATH will show something like


provided no later file in /etc/profile.d adds something in front of PATH. The important thing is that /opt/texbin is before /usr/bin.

At a new release of TeX Live you just have to reset the symbolic link and do nothing else: the GUI programs and the shell will find the correct binaries. But, as seen above, you can still run the programs in other TeX distributions.

Remember: when you install a vanilla TeX Live, never set the option “Create symlink in system directories” to “Yes”. Be sure it's set to “No”, particularly on GNU/Linux systems, where a distribution provided TeX Live would take over in case of upgrades.

  • This is not wise on all systems. My distro's package manager installs certain packages into /opt so installing stuff manually there is not a great idea. If I wanted to use this method, I'd need to make a package to install the symbolic link. On the other hand, my package manager doesn't manage /usr/local so creating symbolic links in /usr/local/texlive (or elsewhere in /usr/local) works fine. This is especially useful if you follow the recommendation not to install as root, which also means the installation script cannot write symbolic links into your system directories.
    – cfr
    Oct 19, 2015 at 22:35
  • @cfr Keeping up with all GNU/Linux systems is a battle lost in advance, I'm afraid.
    – egreg
    Oct 19, 2015 at 22:42
  • Especially where /opt is concerned, I think. That seems to be the place all distros consign things they'd rather not examine too closely. Since the reasons vary, so does what ends up in /opt ;).
    – cfr
    Sep 5, 2017 at 15:24

I appreciate the answer of @egreg and I based my own solution on it, since I wrote a book that uses TL 2017 but I wanted to do package maintenance using TL 2019.

Since, however, Debian-based systems will not work well with this solution due to how they compile sudo, I created a solution and a BASH script at: https://github.com/ServusCarolus/tl-switch

Further below is the README.md file from the repo as of this post. Here is the TL;DR:

  1. I downloaded the net installer for TexLive 2019 and installed it as root under the default: /usr/local/texlive/2019

  2. I did this for root and for my normal user account:

    sudo mkdir -p /opt/tex/root
    sudo mkdir /opt/tex/charles
    sudo chown charles:charles /opt/tex/charles
  3. I modded root's .bashrc and my user .profile like so:

    if [ -d "/opt/tex/$USER/bin" ] ; then
  4. I installed the script as shown in the README below on my 32-bit machine and my 64-bit machine. The script knows how to find both binary directory types.

As a normal user, I can switch TL distributions without becoming root simply by typing tl-switch yes and tl-switch no. When new releases appear, I can switch via tl-switch yes 2020 and so on.

Similar to the answer above, the script either creates or destroys a symlink to the vanilla TL distribution(s) in the user's writable directory under /opt/tex But it does some error checking in the process and saves time.

I become root via sudo su and I can switch distributions the same way, update and do maintenance with tlmgr and do so without altering the context of my normal user. Moreover, this approach scales to as many users and TL distributions that I might want.

Below I talk about other possible solutions because different people have different needs. But at least this approach might help avoid the automatic fallback to the distro packages due to sudo and secure_path. Thanks again to @egreg for providing a good basis and framework.


Switch context between vanilla TeXLive installed under /usr/local/texlive and the Linux distro version of TeXLive installed on a system like Debian, Ubuntu, Mint, etc.

The script and installation are based on ths answers at: Multiple TeXlive installations

Caveat: A Word about sudo

Even if one creates a shell script in /etc/profile.d in order to put a symbolic link to the vanilla TL path before /usr/bin in the command search path, the sudo command will not follow the link by default.

The issue is that Debian and friends build sudo to use secure_path. There are various workarounds to this issue, depending on the user's preference. See: https://stackoverflow.com/questions/257616/why-does-sudo-change-the-path

When installing vanilla TL as root and using this script, one must type, e.g., sudo su to switch contexts to the superuser before running tlmgr. Alternatives include:

  1. The least invasive route, e.g.:

    sudo env PATH=$PATH tlmgr -gui
  2. Use the common group route below and do not use sudo, but set the directories to exist under /usr/local/texlive/ as you would, had you installed via sudo.

  3. Redefine sudo in various ways, as the link above discusses. YMMV.

Regardless of the issues above, normal use works as expected.

Observe caution when editing files. For example, sudo echo "$USER" should point to the regular user, not root. That means one should avoid shortcuts like ~./ in file paths. One should use unambiguous, full paths.

Although the GUI interface of tlmgr will not create files owned by root when run via sudo, one should avoid using many desktop-integrated GUI programs while running sudo. Doing so may create files owned by root in one's home directory tree. That can prevent user programs from saving information properly.

To do a full context switch, do either su or sudo su, depending on the distribution.

Excursus: Make a Group

Another way to avoid problems with sudo is to make the TeXLive installation writeable to all TeX users. The problem here is that chaos might ensue if multiple users meddle with the installation. We include this for completeness:

sudo addgroup texusers
sudo addgroup "$USER" texusers
sudo mkdir -p /usr/local/texlive
sudo chgrp -R texusers /usr/local/texlive
sudo chmod -R 2775 /usr/local/texlive

Note that adduser and addgroup are Debian-isms; other distributions (and Debian-based ones too) have the commands useradd and groupadd. See the man pages for those commands. Thus, you would use instead:

sudo groupadd texusers
sudo usermod -a -G texusers "$USER"

Then one can install TL as part of the texusers group. See also: https://www.tecmint.com/create-a-shared-directory-in-linux/

Step 1: Install Vanilla TL

For installing vanilla TL see: https://www.tug.org/texlive/acquire.html

Note: Never install the symbolic links when installing vanilla TL.

Step 2: Create Directories

We create paths for each user to create directory links:

sudo mkdir -p /opt/tex/root
sudo mkdir "/opt/tex/$USER"
sudo chown "$USER":$USER" "/opt/tex/$USER"

We repeat the final two lines for each user, most likely substituting each username for $USER, e.g.:

sudo mkdir /opt/tex/bob
sudo chown bob:bob /opt/tex/bob

Step 3: Modifying profiles

We put this snippet in each user's .profile and in root's .bashrc:

if [ -d "/opt/tex/$USER/bin" ] ; then

Another approach would put the snippet in everyone's .bashrc, then add source .bashrc to everyone's .profile. That would renew the path environment every time one opens a terminal. Or one can set terminals to open a login shell.

When editing root's .bashrc, remember to use sudo su or specify /root/.bashrc as the file. Otherwise sudo nano ~/.bashrc refers to the user's .bashrc file instead.

Step 4: Install the Script

We go to the directory where we downloaded or cloned the repository and locate the tl-switch script. We then type:

sudo cp ./tl-switch /usr/local/bin
chmod +x /usr/local/bin/tl-switch

All users now will have access to running the script.

Step 5: Reboot

After the install procedure is done, it is good to restart the machine before using TeXLive so that the paths for root and the users can be updated properly.

Step 6: Switching to and from Vanilla TeXLive

When a user (or root) wants to enable access to vanilla TL 2019, one need only type:

tl-switch yes

To specify another installation under /usr/local/texlive, use, e.g.:

tl-switch yes 2018

To disable vanilla TL and use the distro version, one need only type:

tl-switch no

If one changes context in the middle of a session, the search paths will not change. One way to tackle that (somewhat) is mentioned in Step 3 above.

Final Thoughts

An immediate downside to this method is needing to, e.g., sudo su to switch contexts to the superuser before running tlmgr. Its benefits include isolating users from each other and allowing one to change contexts without extensive system modification. Yet contexts only should be changed before logging out and back in again to avoid problems.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .