sudo: tlmgr: command not found

[rafaeln]

Even though /opt/texbin was automagically added to $PATH (as seen from the output of echo $PATH), when I try to run tlmgr as root with sudo tlmgr I get sudo: tlmgr: command not found. My ugly workaround is to go cd /opt/texbin and then sudo ./tlmgr.

I'm running Ubuntu 14.04

[scottkosty]

Thanks for the report. I will have to think about this. First, an explanation: yes, /opt/texbin is added to your PATH by adding it to /etc/environment. However, the root's PATH is special and it's that path that is searched when you run sudo ./tlmgr. To see that /opt/texbin is not added to root's PATH, run e.g. sudo env | grep PATH (note that you should not run sudo echo $PATH because that will substitute whatever PATH is currently in your shell, which is probably your user path and thus misleading). I don't add /opt/texbin automatically to root's PATH (although this would be easy to do) because security experts might be upset and I don't want to make that assumption on behalf of users. However, I will ask the TeX Live experts and see what they recommend. In the meantime, you can add it to root's path yourself, or you might be interested in a little trick/hack: you can use (e.g. in .bashrc):

alias sudo='sudo env PATH=$PATH'

Or you can make an alias just for tlmgr, perhaps something like

tlmgr-update='sudo /opt/texbin/tlmgr update --self --all'

[rafaeln]

Thanks for the explanation.

One detail of this story I don't understand, though, and whose explanation maybe you know: It is not actually the case that the root's PATH is special. If I do

$ sudo su
# echo $PATH

My system gives me

/opt/texbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

[scottkosty]

Thanks for catching me on that. You are right. Apparently this is an Ubuntu-specific behavior because Ubuntu builds sudo with --with-secure-path [1]. For more information, see [2]. To modify the secure path, you can run sudo visudo and then prepend "/opt/texbin:" to the "secure_path" line.

I see a few options now:

(1) tell the users (through output from install-tl-ubuntu) that they might want to add the following line to their .bashrc file: alias tlmgr-update='sudo /opt/texbin/tlmgr update --self --all'.

(2) add alias tlmgr='/opt/texbin/tlmgr' automatically to the user's .bashrc.

(3) set the secure path in sudoers as described above.

(4) recommend to the user that to use tlmgr they do sudo su and then tlmgr.

Do you have any suggestions on which you think is best for install-tl-ubuntu to do? (note that your answer here might be different from what you personally would want).

Thanks for the feedback.

[1] http://stackoverflow.com/questions/257616/sudo-changes-path-why
[2] http://askubuntu.com/questions/128413/setting-the-path-so-it-applies-to-all-users-including-root-sudo

[rafaeln]

I think if a user is installing Texlive manually, they are ready to apply other manual tweaks if they are told to. I will personally just employ the visudo solution, The other solutions seem a bit too clunky to my ears.

I would suggest the installer should, at the end of the install process, explain the problem briefly, offer to add an alias (I think 2 is more general and easier to understand) and tell the user they can also apply the visudo solution by themself. I suppose the visudo solution has to be done manually, but if I'm wrong, then I think the installer should offer to apply it rather than the alias workout.

[scottkosty]

Thanks for your suggestions. I appreciate your thinking this through with me. I will think about this some more and ask others for advice on the best way to proceed. I'll post back here once I've decided what to do.

[josombio]

My way to solve this issue:

1. Execute 'tlmgr gui' as a super user using the full path to the binary. In my case
   sudo /opt/texlive/2014/bin/x86_64-linux/tlmgr gui
2. Select Actions->Handle symlinks in system dirs
3. Select Update symbolic links

This made the trick for me

[scottkosty]

Thank you for posting your approach, Jose. I will take a look at this next time I work on this script.

[anandumdas]

The error happens because the binary you are trying to call from command line is only part of the current user's PATH variable, but not a part of root user's PATH.

You can verify this by locating the path of the binary you are trying to access. In my case I was trying to call "bettercap-ng". So I ran,

$ which bettercap-ng

output: /home/user/work/bin/bettercap

I checked whether this location is part of my root user's PATH.

$ sudo env | grep ^PATH

output: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

So sudo cannot find the binary that I am trying to call from commandline. Hence returns the error command not found.

You can direct sudo to use the current user's PATH when calling a binary like below.

$ sudo -E env "PATH=$PATH" [command] [arguments]

In fact, one can make an alias out of it:

$ alias mysudo='sudo -E env "PATH=$PATH"'

It's also possible to name the alias itself sudo, replacing the original sudo.

Please refer to this video for step by step solution

[the1byo]

Hi all!

I see the thread is quite old and so is the last post. I am not aware if something has changed in all this time, but since I am still facing a similar issue in 2018, (and also since this issue is still open), I have assumed it is still that way. I am a relatively inexperienced programmer, but I thought I'd share something. If the veterans here have the time, I would definitely appreciate the feedback.

---

Idea

1. Add a directory in (say for instance) /usr/local/bin called say, texlive and so on (until an required directory structure is made).

   The choice of /usr/local/bin is because this seems the most appropriate out of the ones typically listed in /etc/environment.

   The complex directory structure is to maybe allow for existence of multiple versions of TeXLive in this scheme of solution (which keeps coming up in the documentation). Each installation is maintained under it's own, separate directory.

2. The core of the solution is to let the installation itself take care of this by creating and adding system links of the binary directories (of TeXLive) to this created directory structure (for the example used above, it would be: /usr/local/bin/texlive/<version>/), instead of the current alternative, which expects the user to take care of this post installation (add a bunch of paths to the PATH).

   Even after which, there seems to be some issue when accessing the same as the root/superuser.

---

Why?

And as I see the existing solutions look like patches more than permanent elegant solutions. And as an average user who wants to install the TeXLive essentials manually, it shouldn't be so complicated. To be honest, this was a good experience for me personally as I learned a lot about the Linux/Ubuntu system (not a complement!).

Why not (maybe)?

• This definitely increases the footprint of the program in the system. Also, I'd understand if it is viewed as making it "messier". (But since this is just adding links to binaries elsewhere, I thought it would'nt matter as much)
• I am not sure if this introduces potential security risks to the system that I am not aware of and overlooking.
• Ultimately, I am not sure if this is a good fix to the issue. I don't even know if this is a working solution! I have not tried it myself. I needed a second opinion.

[scottkosty]

@the1byo thank you very much for taking the time to write that up! Unfortunately, I still don't have time to allocate to this issue. I hope there is discussion from others, and I will try to follow when I can.

[the1byo]

I was glad to see your prompt response. Thank you for taking the time. Let's hope we get to the bottom of this soon!

Cheers! :)