On Ubuntu 11.04, a Debian derivative, and Tex Live installed in /home/mas/texlive on an x86_64 system then the following additions at the end of ~/.profile:
PATH=/home/mas/texlive/2011/bin/x86_64-linux:/home/mas/bin/:$PATH; export PATH
MANPATH=/home/mas/texlive/2011/texmf/doc/man:$MANPATH; export MANPATH
INFOPATH=/home/mas/texlive/2011/texmf/doc/info:$INFOPATH; export INFOPATH
get TeX Live working without a problem, including latexmk
from the command line.
I have the Ubuntu TeX packages installed as well but, where the same command exists in /home/mas/texlive/2011/bin/x86_64-linux (or in /home/mas/bin/ for some manually-installed software) then that version will be used in preference.
I am using a locally-installed download of TeXworks with the modification you show: In Edit -> Preferences -> Paths frame the path '/home/mas/texlive/2011/bin/x86_64-linux' has been put at the top of the list.
Coming on to latex-mk
. This is not in the default list for TeXworks processing tools, although latexmk
is (as LaTeXmk on my systems as they are not the latest versions: see the question latexmk-not-accompanying-texworks-0-5 for the change that TeXworks not longer lists latexmk
in recent builds). If you want latex-mk
and have it installed (it is not part of TeX Live but will probably be in the repositories for many GNU/Linux distributions) then it can be added to the list of processing tools. In TeXworks I added it via Edit -> Preferences in the Processing Tools frame, click '+' to add and fill in the new window appropriately (I used 'LaTeX-mk' for name, 'latex-mk' for program (no path needed unless you have more than one installed and don't want the default), and options '--pdflatex' followed by '$fullname') and that seems to behave reasonably. If you wanted to add any other processing tools the procedure is similar, though the parameters will probably be different, of course.
This looks very much like a permissions problem. I've encountered this when I've done an installation using tlmgr
, though I'm surprised at its rearing its ugly head when installation is done using apt-get
.
The Likely Problem
At some point in the installation, files were installed that were only usable by the root
account. That is, ordinary users do not have permission to read the necessary files for latex
to work.
In brief, every file and directory on a UNIX system has three sets of three permissions (sort of). The three sets are: owner
, group
, world
and the three permissions are read
, write
, execute
. In order to use a file or directory you have to have sufficient permissions to carry out the activity. Which permissions apply depend on your relationship to the file (or directory) in question. For the files installed in a TeXLive installation, the most likely situation is that you do not own the files (root
does) nor are you in the same group as the files (probably something like admin
) so the world
permissions apply to you. When you do ls -l <file name>
then the first block looks something like -rw-r--r--
. It is the last three that therefore concern you. What you need is to have r--
for ordinary files and r-x
for directories and executable files.
Diagnosing the Problem
To check this hypothesis, you need to find the permissions of (some of) the files. From the comments, the first thing to try is:
ls -l /usr/share/texmf-texlive/tex/latex/base/article.cls
With a bit of luck, this will complain:
cannot access /usr/share/texmf-texlive/tex/latex/base/article.cls: Permission denied
If so, it's a permissions problem. (It might be that the message is cannot open directory
and that the path is only a part of the path given.)
Making sure it doesn't happen again
When software is installed, it tries to install it as permissively as possible so that any user can use it. However, when you create a file in your own directory you don't want this behaviour: you want it so that you can use it, but no other user can do so. Unfortunately, the system can't tell the difference between these two cases and just sees the instruction "Create a file/directory". Now you can say "Create a file/directory with these permissions" but then that's hard for a user to override if they want to do a local installation. So what happens is the request is "Create a file/directory and suggest these permissions". The "suggestion" is then matched against something called the umask
to get the real permissions. You can think of the umask
as a polariser: it only allows certain permissions to get through.
Permissions are stored as octal numbers, with 4 = read, 2 = write, 1 = executable. An installer might say "This is an executable file, I suggest permissions 755" meaning everyone can read and execute it, and the owner can write to it. This is then checked against the umask
to see which of these permissions can be set. A common user umask
is 077. This allows through all user permissions but none of the others so the resulting file permissions are 700. On the other hand, the standard umask
for a system installation is 022
. This guards against files being writeable by non-owners but otherwise lets everything else through. Then the 755 would work.
What is likely to have happened here is that the umask
in effect was 077 instead of 022. This can sometimes happen when using sudo
since then the umask
is not changed from its user setting. To avoid this happening again, the command umask 022
changes the umask
to 022 (umask
by itself displays the current setting) so this can be done before the installation, and then reset afterwards.
(However, as I said, I'm a little surprised at this happening with apt-get
since I would expect that to be umask
-savvy and sort itself out. tlmgr
does not, though.)
Fixing Things Afterwards
Deleting and reinstalling is one option, but given the size of TeXLive it's a bit of a sledgehammer. A little more refined is fixing the permissions.
The first thing to do is work out where the problem starts. To do that, start with the article.cls
path that you have and find out where you first lose permission:
ls -l /usr/share/texmf-texlive/tex/latex/base/article.cls
ls -ld /usr/share/texmf-texlive/tex/latex/base
ls -ld /usr/share/texmf-texlive/tex/latex
ls -ld /usr/share/texmf-texlive/tex
ls -ld /usr/share/texmf-texlive
ls -ld /usr/share
(If you get to the bottom one and still have problems, then you have big problems.)
Most likely, it is /usr/share/texmf-texlive
. Next is to get a sense of the scale of the problem:
sudo find /usr/share/texmf-texlive -not -perm -004
This gives you a list of all the files and folders below texmf-texlive
which are not world-readable. It might just be that it is only the top directory that has the wrong permissions, if so then do the following:
- Give a small "whoop" of joy
sudo chmod 755 /usr/share/texmf-texlive
If the list is very short, you can do something similar to the above on each of the files/directories. The rules are that the permission to give is whatever the owner has without the writeable one. chmod
can take "symbolic" permissions so you don't have to remember the octal notation (symbolic is actually better here as the syntax for adding permissions is simple). In short:
- Do
sudo ls -l <filename>
- Examine the first bit, it will start with one of
drwx
, -rwx
, or -rw-
- If one of the first two, do
sudo chmod go+rx <filename>
- If the last one, do
sudo chmod go+r <filename>
If the list is quite long, going through each one is a pain. Fortunately, find
can iterate through the list of files and execute a command on each one. We have to do it twice to fix the two situations.
First, we go through and add the read
bit to all files and folders.
sudo find /usr/share/texmf-texlive -not -perm -004 -exec chmod go+r {} ';'
Then, we go through and add the execute
bit to all executable files and all folders.
sudo find /usr/share/texmf-texlive -perm +100 -not -perm -001 -exec chmod go+x {} ';'
At this point, everything should have the right permissions.
Caveat
There is a faint chance that there are some files which aren't meant to be world readable in the TeXLive tree, or executable files which aren't meant to be executable by anyone but root. However, I doubt that.
(Unfortunately, as I can't guarantee that my last TL installation didn't need this permission fix, I can't trust that the permissions in my installation are all as they were intended so I can't test this myself.)
Best Answer
MacOS X has an additional mechanism to add to the path. If you read
/etc/profile
you will find the linesThe
path_helper
program uses the directory/etc/paths.d
to add items to the path. Inside/etc/paths.d
, each file should be a list of items to add to the path. So there is a file there calledTeX
which contains one lineIt is this line which makes the 'magic' work. See http://www.softec.lu/site/DevelopersCorner/MasteringThePathHelper for more on this.