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?
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.
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
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.
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.