2

I am set up as a sudoer on my Debian machine, and I use it all the time to install software etc... I came across this interesting situation that I am scratching my head about:

I tried to enable the fancy progress bar in apt using this command:

sudo echo 'Dpkg::Progress-Fancy "1";' > /etc/apt/apt.conf.d/99progressbar

I have permissions issues:

/etc/apt/apt.conf.d/99progressbar: Permission denied

However, if I su, then run the command, everything just works.

Why is this so?

Questionmark
  • 3,945

3 Answers3

10

Because

 sudo cmd > file

is interpreted as 

(sudo cmd) > file

by your shell. I.e. the redirect is done as your own user.

The way I get around that is using

cmd | sudo tee file

Addition: That will also show the output of cmd on your console, if you don't want that you'll have to redirect it.

Henrik supports the community
  • 5,636
2

As far as I know, > is the command by shell itself (redirection is done by the non-root shell itself) When you use su, it runs as a root shell which allows you to redirect for root-owned files

R. Roman
  • 91
1

sudo has problems, because it runs the command portion. After the redirect, sudo is not effective anymore.

You can do this instead :

sudo bash -c "Your commands here > output_file"

carefully escaping the single or double quotes in the commands between quotes, in the nesting order you use them.

EDIT:

Explanation in a little deeper detail

When you run a script, you are actually creating a new sub-shell and your script runs in this sub-shell, but the output comes back to the current shell. Your new sub-shell where you run this script is run with sudo privileges, so the scripts runs effectively as root. But when the run finishes, the shell exits and your sudo goes * pooof *. The output comes back to your current, non-privileged shell. If you are expecting it to be written at a privileged location, it is not going to happen. Hence, running the new shell and the whole enchilada, inside a well defined bash shell, makes it possible. Because, at this point, your command and output are all handled by the sudo enabled shell, not half way as in the original case.

MelBurslan
  • 6,966
  • 1
    Partly correct, and partly backwards. Actually the shell tries to open output_file for writing before it even thinks about running sudo. But what really matters isn't the sequence of events, it's which process is responsible for what. – hobbs Mar 18 '16 at 19:53