sudo echo"xxx" > e.txt

[ivanhelguera]

Hello everyone,
A bash question.
Why does

sudo echo -e "echo" > /etc/apt/sources.list.d/echo.txt

returns

bash: /etc/apt/sources.list.d/echo.txt: Permission denied

?
everything works well after a

sudo su

.
I understand that the sudo operator does not include the redirected output. Could anyone explain that, or point toward some online resource?
Thanks in advance.

[reed9]

It doesn't work because there are two parts to it, and "sudo" is only applying to the first part. You need to use the tee command.

echo echo | sudo tee -a /etc/apt/sources.list.d/echo.txt

[ivanhelguera]

So one could say that actually the command in question does not have a form of

sudo (echo xxx > file)

, but rather something a bit like

>[(sudo echo), file]

by which I meant to say that it is actually the redirect operator that has the highest priority (much as division has higher priority the addition).
Except that > is not a command as such, and it cannot be sudo'ed.
And the tee command you mentioned is, actually, the very '>' as a command.
If that makes any sense .
Thank you!

[reed9]

The more complete answer is that the shell is running with your user's permissions, and only echo is running with sudo permissions, and it's the shell that handles redirecting the output.

Su works because you're logging in as root, not running just one process with root permissions.

You can also apply sudo to the whole pipeline.

echo "echo text >> /etc/apt/sources.list.d/echo.txt" | sudo sh

sudo sh -c 'echo "text" >> /etc/apt/sources.list.d/echo.txt'

I'm using the two >> for append, and one > will overwrite with a new file.

Sudo Manual

[ivanhelguera]

The more complete answer is that the shell is running with your user's permissions, and only echo is running with sudo permissions, and it's the shell that handles redirecting the output.

OK so the | is actually a shell command, and as long as the shell has oridinary perimissions, it can't write /etc/xxxxx. And when I su, the whole shell is getting admin rights.

echo "echo text >> /etc/apt/sources.list.d/echo.txt" | sudo sh

OK, so that puts the "echo text >> /etc/apt/sources.list.d/echo.txt" as the input for sudo sh. As the command is run with sudo, it does what it wants.

sudo sh -c 'echo "text" >> /etc/apt/sources.list.d/echo.txt'

I understand (after some experimenting like

sh  'ls'
sh: Can't open ls
sh -c  'ls'
debian-testing-i386-netinst.iso
...

and some reading that what the command does is to treat the
the input as the list of commands to be executed (and not the file name as it would without the -c switch).

Thank you very much for the examples and explanations. sh has its quirks which are not evident, though with every small point one gets a part of the big image.

[reed9]

OK so the | is actually a shell command, and as long as the shell has oridinary perimissions, it can't write /etc/xxxxx. And when I su, the whole shell is getting admin rights.

The pipe | is connecting the standard output of a command to the standard input of another command. If your first example of sudo echo "echo", you have a command, running as root, that outputs "echo", and then the shell redirects that output and tries to write to a restricted file.

sudo sh is opening a root shell. So this

echo "echo text >> /etc/apt/sources.list.d/echo.txt" | sudo sh

outputs echo text >> /etc/apt/sources.list.d/echo.txt and plugs that into a root shell. It's like if you had logged into the shell as root with su and typed that line.

http://en.wikipedia.org/wiki/Pipeline_(Unix)

[ivanhelguera]

sudo sh is opening a root shell. So this

echo "echo text >> /etc/apt/sources.list.d/echo.txt" | sudo sh

outputs echo text >> /etc/apt/sources.list.d/echo.txt and plugs that into a root shell. It's like if you had logged into the shell as root with su and typed that line.

Good. I understand all(?) that.
What surprised me initially is that the pipeline is somehow not treated as an argument of sudo. Understanding those things make you see some of the internals of sh.
Thanks again,
IH