This question already has an answer here:

For ubuntu 12.04 bash scripts, I used to be able to run commands like the example below to overwrite files:

sudo echo 'line1   
line3' > /etc/some/config/file.conf

Ever since Ubuntu 14.04, I now have to break it up to get the same behaviour like so:

sudo echo 'line1
line3' | sudo tee /etc/some/config/file.conf

I am guessing this is an extra security measure? Is there some way to go back to the old behaviour?


As some have correctly pointed out, this behaviour is consistent across Ubuntu 12.04 and Ubuntu 14.04. I believe I got mixed but because if one runs the command in a bash script called with sudo, then it executes fine, however, pasting the command into the CLI, it results in permission denied. I was comparing apples with oranges.

marked as duplicate by user117103, Programster, Eric Carvalho, karel, bain Jun 21 '14 at 10:54

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 2
    I seriously doubt you can do that on 12.04 or for that matter any version of ubuntu. – jobin Jun 20 '14 at 11:13
  • This 'old behaviour' never existed in any version of Bash (or any other POSIX compatible shell). – Florian Diesch Jun 20 '14 at 11:18
  • 1
    Why the -1? He is wrong, but does that really deserve a downvote? – kraxor Jun 20 '14 at 11:23
  • 1
    Have updated my answer to reflect why it works with scripts. – jobin Jun 20 '14 at 11:55

You cannot directly use > with sudo the way you are doing it, the reason is the redirection is performed by the shell and not by sudo and hence the command will fail to write to the file because of permissions.

Refer to this question for appropriate solutions for this:


In case you copy:

sudo echo 'line1   
line3' > /etc/some/config/file.conf

to a file, say scrip.sh, and then execute the script as

sudo bash script.sh

you won't get an error and the script will execute successfully because in this case, you are running the script by providing the shell with appropriate permissions(sudo bash).

Not the answer you're looking for? Browse other questions tagged or ask your own question.