Redirecting stdout to a file you don't have write permission on












104















When you attempt to modify a file without having write permissions on it, you get an error:



> touch /tmp/foo && sudo chown root /tmp/foo
> echo test > /tmp/foo
zsh: permission denied: /tmp/foo


Sudoing doesn't help, because it runs the command as root, but the shell handles redirecting stdout and opens the file as you anyway:



> sudo echo test > /tmp/foo
zsh: permission denied: /tmp/foo


Is there an easy way to redirect stdout to a file you don't have permission to write to, besides opening a shell as root and manipulating the file that way?



> sudo su
# echo test > /tmp/foo









share|improve this question




















  • 2





    Answer for a similar question from StackOverflow stackoverflow.com/questions/82256/…

    – Cristian Ciupitu
    Sep 3 '10 at 11:22













  • how can u dont have permission to a file you created yourself in tmp ? is it becuase of umask ?

    – k961
    Feb 16 '15 at 4:40











  • @k961 I used chown to change the owner; it was just an example

    – Michael Mrozek
    Feb 16 '15 at 6:56
















104















When you attempt to modify a file without having write permissions on it, you get an error:



> touch /tmp/foo && sudo chown root /tmp/foo
> echo test > /tmp/foo
zsh: permission denied: /tmp/foo


Sudoing doesn't help, because it runs the command as root, but the shell handles redirecting stdout and opens the file as you anyway:



> sudo echo test > /tmp/foo
zsh: permission denied: /tmp/foo


Is there an easy way to redirect stdout to a file you don't have permission to write to, besides opening a shell as root and manipulating the file that way?



> sudo su
# echo test > /tmp/foo









share|improve this question




















  • 2





    Answer for a similar question from StackOverflow stackoverflow.com/questions/82256/…

    – Cristian Ciupitu
    Sep 3 '10 at 11:22













  • how can u dont have permission to a file you created yourself in tmp ? is it becuase of umask ?

    – k961
    Feb 16 '15 at 4:40











  • @k961 I used chown to change the owner; it was just an example

    – Michael Mrozek
    Feb 16 '15 at 6:56














104












104








104


20






When you attempt to modify a file without having write permissions on it, you get an error:



> touch /tmp/foo && sudo chown root /tmp/foo
> echo test > /tmp/foo
zsh: permission denied: /tmp/foo


Sudoing doesn't help, because it runs the command as root, but the shell handles redirecting stdout and opens the file as you anyway:



> sudo echo test > /tmp/foo
zsh: permission denied: /tmp/foo


Is there an easy way to redirect stdout to a file you don't have permission to write to, besides opening a shell as root and manipulating the file that way?



> sudo su
# echo test > /tmp/foo









share|improve this question
















When you attempt to modify a file without having write permissions on it, you get an error:



> touch /tmp/foo && sudo chown root /tmp/foo
> echo test > /tmp/foo
zsh: permission denied: /tmp/foo


Sudoing doesn't help, because it runs the command as root, but the shell handles redirecting stdout and opens the file as you anyway:



> sudo echo test > /tmp/foo
zsh: permission denied: /tmp/foo


Is there an easy way to redirect stdout to a file you don't have permission to write to, besides opening a shell as root and manipulating the file that way?



> sudo su
# echo test > /tmp/foo






shell permissions io-redirection sudo io






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 14 '10 at 15:20









xenoterracide

25.5k52158222




25.5k52158222










asked Aug 31 '10 at 6:18









Michael MrozekMichael Mrozek

60.8k29187208




60.8k29187208








  • 2





    Answer for a similar question from StackOverflow stackoverflow.com/questions/82256/…

    – Cristian Ciupitu
    Sep 3 '10 at 11:22













  • how can u dont have permission to a file you created yourself in tmp ? is it becuase of umask ?

    – k961
    Feb 16 '15 at 4:40











  • @k961 I used chown to change the owner; it was just an example

    – Michael Mrozek
    Feb 16 '15 at 6:56














  • 2





    Answer for a similar question from StackOverflow stackoverflow.com/questions/82256/…

    – Cristian Ciupitu
    Sep 3 '10 at 11:22













  • how can u dont have permission to a file you created yourself in tmp ? is it becuase of umask ?

    – k961
    Feb 16 '15 at 4:40











  • @k961 I used chown to change the owner; it was just an example

    – Michael Mrozek
    Feb 16 '15 at 6:56








2




2





Answer for a similar question from StackOverflow stackoverflow.com/questions/82256/…

– Cristian Ciupitu
Sep 3 '10 at 11:22







Answer for a similar question from StackOverflow stackoverflow.com/questions/82256/…

– Cristian Ciupitu
Sep 3 '10 at 11:22















how can u dont have permission to a file you created yourself in tmp ? is it becuase of umask ?

– k961
Feb 16 '15 at 4:40





how can u dont have permission to a file you created yourself in tmp ? is it becuase of umask ?

– k961
Feb 16 '15 at 4:40













@k961 I used chown to change the owner; it was just an example

– Michael Mrozek
Feb 16 '15 at 6:56





@k961 I used chown to change the owner; it was just an example

– Michael Mrozek
Feb 16 '15 at 6:56










7 Answers
7






active

oldest

votes


















106














Yes, using tee. So echo test > /tmp/foo becomes



echo test | sudo tee /tmp/foo


You can also append (>>)



echo test | sudo tee -a /tmp/foo





share|improve this answer





















  • 22





    Tee will also output to stdout; sometimes you don't want the contents filling the screen. To fix this, do echo test | sudo tee /tmp/foo > /dev/null

    – Shawn J. Goff
    Dec 14 '10 at 15:20











  • How will you do it with heredoc?

    – JohnDoea
    Nov 19 '16 at 2:54



















26














To replace the content of the file with the output of echo (like the > shell redirection operator).



echo test | sudo dd of=/tmp/foo


To write into the file (at the beginning, though you can use seek to output at different offsets) without truncating (like the 1<> Bourne shell operator):



echo test | sudo dd of=/tmp/foo conv=notrunc


To append to the file (like >>), with GNU dd:



echo test | sudo dd of=/tmp/foo oflag=append conv=notrunc


See also GNU dd's conv=excl to avoid clobbering an existing file (like with set -o noclobber in POSIX shells) and conv=nocreat for the opposite (only update an existing file).






share|improve this answer


























  • clever! this alleviates the need to do echo test | sudo tee /tmp/foo >/dev/null to discard the output.

    – Adam Katz
    Jan 14 '15 at 23:52






  • 2





    I may have to take that back; dd is unreliable for that unless you're using obscure GNU-only options iflag=fullblock oflag=fullblock, which remove the elegance of this answer. I'll stick with tee.

    – Adam Katz
    Jan 16 '15 at 6:32






  • 5





    dd is reliable with the non-obscure bs=1

    – umeboshi
    Jan 25 '15 at 3:50






  • 2





    @umeboshi But reliable only if you're experienced enough to know exactly what you're doing. Fordd can be fairly dangerous (if not to say: devastating) if only a slight mistake was made. So for new users, I'd rather recommend the tee method to be on the safe shore.

    – syntaxerror
    Jan 29 '16 at 17:38








  • 1





    @AdamKatz, in the case of dd of=file alone (without count/skip...), it is reliable. iflag=fullblock is not needed because here dd writes on output what it has read on input. It doesn't matter if it was not full blocks.

    – Stéphane Chazelas
    Sep 12 '17 at 11:30



















12














tee is probably the best choice, but depending on your situation something like this may be enough:



sudo sh -c 'echo test > /tmp/foo'





share|improve this answer





















  • 1





    3 problems: eval instead of a simple sh -c; -i, which will change your working dir; running the whole command as root, which might change it's behaviour or may introduce an unnecessary risk. why did this ever get an upvote?

    – user601
    Aug 31 '10 at 10:38






  • 4





    you didn't, but it is misleading, generally bad and maybe even dangerous.

    – user601
    Aug 31 '10 at 20:24



















5














While I agree, that | sudo tee is the canonical way, sometimes sed (here assuming GNU sed) may work:



cat sudotest 
line 1

sudo sed -i '1iitest' sudotest && cat sudotest
itest
line 1

sudo sed -i '$aatest' sudotest && cat sudotest
itest
line 1
atest


-i modifies the file in place. 1i means insert before line 1. $a means append after last line.



Or copy to xclipboard:



somecommand | xclip
sudo gedit sudotest
move cursor to desired place, click middle mouse button to insert, save





share|improve this answer





















  • 1





    This is worded like an Ancient Chinese riddle. Can't see to understand how this got so many upvotes. (hrmph)

    – syntaxerror
    Jan 29 '16 at 17:36











  • @syntaxerror: Sir, I'm sorry, I'm not a native English speaker. If you specify what is unclear to you, I could try to improve my answer. Compared with 65 upvotes for Gert, 4 doesn't seem to be that many upvotes, either, don't you think?

    – user unknown
    Jan 30 '16 at 1:35











  • Well I would be pretty satisfied with 4 :-D Your English is not bad at all. It's just worded in a kind of terse techie nerdspeak. I must guess you're a coder. Coders amongst each other will understand themselves perfectly that way, but a non-coder must think it's worded like...as said.

    – syntaxerror
    Jan 31 '16 at 20:22













  • Note that sed -i does not actually modify the file in place - it creates a temporary file and renames it on exiting. So you won't be able to do something like tail -f ... on the original file and see the output using sed -i ... while the pipeline is running

    – Andrew Henle
    Mar 14 '18 at 10:24













  • @AndrewHenle: Yes, since the size may be increased or shrinked, and since that's probably the case for most sed invocations, and you can't even - afaik - write to the same location on SSDs it's only a pseudo 'in place' operation. As a non native english speaker, may I ask for a brief expression, which isn't so likely misinterpreted? Just -i creates a new file of same name or is there something more compact? I guess I like in place, because it explains the i. The gnu-sed manpage calls it in place too and the long flag is --in-place.

    – user unknown
    Mar 14 '18 at 10:30





















2














I have been kicking around in the back of my mind ideas for a similar problem, and came up with the following solutions:




  • sudo uncat where uncat is a program that reads standard input and writes it to the file named on the command line, but I haven't written uncat yet.


  • sudocat the variant of sudoedit that I haven't written yet that does a cleaner sudo cat or sudo uncat.



  • or this little trick of using sudoedit with an EDITOR that is a shell script



    #!/bin/sh
    # uncat
    cat > "$1"


    which can be invoked as either |sudo ./uncat file or | EDITOR=./uncat sudoedit but that has interesting side-effects.








share|improve this answer


























  • cat takes a list of files to concatinate, therefore uncat should take a list of files to un concatinate to. It would have to use magic to decide how much to put in each file. Alternative name include dog, to-file, redirect.

    – ctrl-alt-delor
    Apr 15 '15 at 14:51













  • I can't think of any reason why I would want uncat when I have tee.

    – Wildcard
    Sep 29 '15 at 9:26






  • 1





    Well, tee has the trivial drawback that it writes its stdin to its stdout — which is trivially mitigated by redirecting the stdout to /dev/null.  Other alternatives include dd of=/tmp/foo (mentioned in another answer), which writes status information to stderr, and cp /dev/stdin /tmp/foo.

    – Scott
    Feb 17 '16 at 14:44



















1














Use sponge from the moreutils package. It has the advantage that it does not write to stdout.



echo test | sudo sponge /tmp/foo


Use the -a option to append to a file instead of overwriting it.






share|improve this answer



















  • 1





    I'm not sure what advantage not writing to stdout presents, but you could just redirect the output to /dev/null if it were an issue

    – Michael Mrozek
    Dec 18 '16 at 4:41






  • 1





    Of course I can redirect to /dev/null, but the command is easier to read and type without the redirection. The advantage of not writing to stdout is that my terminal is not filled with rubbish.

    – Hontvári Levente
    Dec 18 '16 at 22:48






  • 1





    I would not install a package to spare a redirection, but I regularly use sponge, so it is already there.

    – Hontvári Levente
    Dec 18 '16 at 22:50



















0














The error comes from the order in which the shell does things.



The redirection is handled before the shell even executes sudo, and is therefore done with the permissions of the user that you are currently working as. Since you don't have write permissions to create/truncate the target of the redirection, you get a permission denied error from the shell.



The solution is to guarantee that the output file is created under the identity given to you by sudo, e.g. with tee:



$ generate_output | sudo tee target_file





share|improve this answer























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f1416%2fredirecting-stdout-to-a-file-you-dont-have-write-permission-on%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    7 Answers
    7






    active

    oldest

    votes








    7 Answers
    7






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    106














    Yes, using tee. So echo test > /tmp/foo becomes



    echo test | sudo tee /tmp/foo


    You can also append (>>)



    echo test | sudo tee -a /tmp/foo





    share|improve this answer





















    • 22





      Tee will also output to stdout; sometimes you don't want the contents filling the screen. To fix this, do echo test | sudo tee /tmp/foo > /dev/null

      – Shawn J. Goff
      Dec 14 '10 at 15:20











    • How will you do it with heredoc?

      – JohnDoea
      Nov 19 '16 at 2:54
















    106














    Yes, using tee. So echo test > /tmp/foo becomes



    echo test | sudo tee /tmp/foo


    You can also append (>>)



    echo test | sudo tee -a /tmp/foo





    share|improve this answer





















    • 22





      Tee will also output to stdout; sometimes you don't want the contents filling the screen. To fix this, do echo test | sudo tee /tmp/foo > /dev/null

      – Shawn J. Goff
      Dec 14 '10 at 15:20











    • How will you do it with heredoc?

      – JohnDoea
      Nov 19 '16 at 2:54














    106












    106








    106







    Yes, using tee. So echo test > /tmp/foo becomes



    echo test | sudo tee /tmp/foo


    You can also append (>>)



    echo test | sudo tee -a /tmp/foo





    share|improve this answer















    Yes, using tee. So echo test > /tmp/foo becomes



    echo test | sudo tee /tmp/foo


    You can also append (>>)



    echo test | sudo tee -a /tmp/foo






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Aug 31 '10 at 6:59









    Warren Young

    54.8k10143147




    54.8k10143147










    answered Aug 31 '10 at 6:47









    GertGert

    7,03122934




    7,03122934








    • 22





      Tee will also output to stdout; sometimes you don't want the contents filling the screen. To fix this, do echo test | sudo tee /tmp/foo > /dev/null

      – Shawn J. Goff
      Dec 14 '10 at 15:20











    • How will you do it with heredoc?

      – JohnDoea
      Nov 19 '16 at 2:54














    • 22





      Tee will also output to stdout; sometimes you don't want the contents filling the screen. To fix this, do echo test | sudo tee /tmp/foo > /dev/null

      – Shawn J. Goff
      Dec 14 '10 at 15:20











    • How will you do it with heredoc?

      – JohnDoea
      Nov 19 '16 at 2:54








    22




    22





    Tee will also output to stdout; sometimes you don't want the contents filling the screen. To fix this, do echo test | sudo tee /tmp/foo > /dev/null

    – Shawn J. Goff
    Dec 14 '10 at 15:20





    Tee will also output to stdout; sometimes you don't want the contents filling the screen. To fix this, do echo test | sudo tee /tmp/foo > /dev/null

    – Shawn J. Goff
    Dec 14 '10 at 15:20













    How will you do it with heredoc?

    – JohnDoea
    Nov 19 '16 at 2:54





    How will you do it with heredoc?

    – JohnDoea
    Nov 19 '16 at 2:54













    26














    To replace the content of the file with the output of echo (like the > shell redirection operator).



    echo test | sudo dd of=/tmp/foo


    To write into the file (at the beginning, though you can use seek to output at different offsets) without truncating (like the 1<> Bourne shell operator):



    echo test | sudo dd of=/tmp/foo conv=notrunc


    To append to the file (like >>), with GNU dd:



    echo test | sudo dd of=/tmp/foo oflag=append conv=notrunc


    See also GNU dd's conv=excl to avoid clobbering an existing file (like with set -o noclobber in POSIX shells) and conv=nocreat for the opposite (only update an existing file).






    share|improve this answer


























    • clever! this alleviates the need to do echo test | sudo tee /tmp/foo >/dev/null to discard the output.

      – Adam Katz
      Jan 14 '15 at 23:52






    • 2





      I may have to take that back; dd is unreliable for that unless you're using obscure GNU-only options iflag=fullblock oflag=fullblock, which remove the elegance of this answer. I'll stick with tee.

      – Adam Katz
      Jan 16 '15 at 6:32






    • 5





      dd is reliable with the non-obscure bs=1

      – umeboshi
      Jan 25 '15 at 3:50






    • 2





      @umeboshi But reliable only if you're experienced enough to know exactly what you're doing. Fordd can be fairly dangerous (if not to say: devastating) if only a slight mistake was made. So for new users, I'd rather recommend the tee method to be on the safe shore.

      – syntaxerror
      Jan 29 '16 at 17:38








    • 1





      @AdamKatz, in the case of dd of=file alone (without count/skip...), it is reliable. iflag=fullblock is not needed because here dd writes on output what it has read on input. It doesn't matter if it was not full blocks.

      – Stéphane Chazelas
      Sep 12 '17 at 11:30
















    26














    To replace the content of the file with the output of echo (like the > shell redirection operator).



    echo test | sudo dd of=/tmp/foo


    To write into the file (at the beginning, though you can use seek to output at different offsets) without truncating (like the 1<> Bourne shell operator):



    echo test | sudo dd of=/tmp/foo conv=notrunc


    To append to the file (like >>), with GNU dd:



    echo test | sudo dd of=/tmp/foo oflag=append conv=notrunc


    See also GNU dd's conv=excl to avoid clobbering an existing file (like with set -o noclobber in POSIX shells) and conv=nocreat for the opposite (only update an existing file).






    share|improve this answer


























    • clever! this alleviates the need to do echo test | sudo tee /tmp/foo >/dev/null to discard the output.

      – Adam Katz
      Jan 14 '15 at 23:52






    • 2





      I may have to take that back; dd is unreliable for that unless you're using obscure GNU-only options iflag=fullblock oflag=fullblock, which remove the elegance of this answer. I'll stick with tee.

      – Adam Katz
      Jan 16 '15 at 6:32






    • 5





      dd is reliable with the non-obscure bs=1

      – umeboshi
      Jan 25 '15 at 3:50






    • 2





      @umeboshi But reliable only if you're experienced enough to know exactly what you're doing. Fordd can be fairly dangerous (if not to say: devastating) if only a slight mistake was made. So for new users, I'd rather recommend the tee method to be on the safe shore.

      – syntaxerror
      Jan 29 '16 at 17:38








    • 1





      @AdamKatz, in the case of dd of=file alone (without count/skip...), it is reliable. iflag=fullblock is not needed because here dd writes on output what it has read on input. It doesn't matter if it was not full blocks.

      – Stéphane Chazelas
      Sep 12 '17 at 11:30














    26












    26








    26







    To replace the content of the file with the output of echo (like the > shell redirection operator).



    echo test | sudo dd of=/tmp/foo


    To write into the file (at the beginning, though you can use seek to output at different offsets) without truncating (like the 1<> Bourne shell operator):



    echo test | sudo dd of=/tmp/foo conv=notrunc


    To append to the file (like >>), with GNU dd:



    echo test | sudo dd of=/tmp/foo oflag=append conv=notrunc


    See also GNU dd's conv=excl to avoid clobbering an existing file (like with set -o noclobber in POSIX shells) and conv=nocreat for the opposite (only update an existing file).






    share|improve this answer















    To replace the content of the file with the output of echo (like the > shell redirection operator).



    echo test | sudo dd of=/tmp/foo


    To write into the file (at the beginning, though you can use seek to output at different offsets) without truncating (like the 1<> Bourne shell operator):



    echo test | sudo dd of=/tmp/foo conv=notrunc


    To append to the file (like >>), with GNU dd:



    echo test | sudo dd of=/tmp/foo oflag=append conv=notrunc


    See also GNU dd's conv=excl to avoid clobbering an existing file (like with set -o noclobber in POSIX shells) and conv=nocreat for the opposite (only update an existing file).







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Mar 13 '18 at 13:20









    Stéphane Chazelas

    301k55564916




    301k55564916










    answered Sep 3 '10 at 4:19









    Chris JepewayChris Jepeway

    26122




    26122













    • clever! this alleviates the need to do echo test | sudo tee /tmp/foo >/dev/null to discard the output.

      – Adam Katz
      Jan 14 '15 at 23:52






    • 2





      I may have to take that back; dd is unreliable for that unless you're using obscure GNU-only options iflag=fullblock oflag=fullblock, which remove the elegance of this answer. I'll stick with tee.

      – Adam Katz
      Jan 16 '15 at 6:32






    • 5





      dd is reliable with the non-obscure bs=1

      – umeboshi
      Jan 25 '15 at 3:50






    • 2





      @umeboshi But reliable only if you're experienced enough to know exactly what you're doing. Fordd can be fairly dangerous (if not to say: devastating) if only a slight mistake was made. So for new users, I'd rather recommend the tee method to be on the safe shore.

      – syntaxerror
      Jan 29 '16 at 17:38








    • 1





      @AdamKatz, in the case of dd of=file alone (without count/skip...), it is reliable. iflag=fullblock is not needed because here dd writes on output what it has read on input. It doesn't matter if it was not full blocks.

      – Stéphane Chazelas
      Sep 12 '17 at 11:30



















    • clever! this alleviates the need to do echo test | sudo tee /tmp/foo >/dev/null to discard the output.

      – Adam Katz
      Jan 14 '15 at 23:52






    • 2





      I may have to take that back; dd is unreliable for that unless you're using obscure GNU-only options iflag=fullblock oflag=fullblock, which remove the elegance of this answer. I'll stick with tee.

      – Adam Katz
      Jan 16 '15 at 6:32






    • 5





      dd is reliable with the non-obscure bs=1

      – umeboshi
      Jan 25 '15 at 3:50






    • 2





      @umeboshi But reliable only if you're experienced enough to know exactly what you're doing. Fordd can be fairly dangerous (if not to say: devastating) if only a slight mistake was made. So for new users, I'd rather recommend the tee method to be on the safe shore.

      – syntaxerror
      Jan 29 '16 at 17:38








    • 1





      @AdamKatz, in the case of dd of=file alone (without count/skip...), it is reliable. iflag=fullblock is not needed because here dd writes on output what it has read on input. It doesn't matter if it was not full blocks.

      – Stéphane Chazelas
      Sep 12 '17 at 11:30

















    clever! this alleviates the need to do echo test | sudo tee /tmp/foo >/dev/null to discard the output.

    – Adam Katz
    Jan 14 '15 at 23:52





    clever! this alleviates the need to do echo test | sudo tee /tmp/foo >/dev/null to discard the output.

    – Adam Katz
    Jan 14 '15 at 23:52




    2




    2





    I may have to take that back; dd is unreliable for that unless you're using obscure GNU-only options iflag=fullblock oflag=fullblock, which remove the elegance of this answer. I'll stick with tee.

    – Adam Katz
    Jan 16 '15 at 6:32





    I may have to take that back; dd is unreliable for that unless you're using obscure GNU-only options iflag=fullblock oflag=fullblock, which remove the elegance of this answer. I'll stick with tee.

    – Adam Katz
    Jan 16 '15 at 6:32




    5




    5





    dd is reliable with the non-obscure bs=1

    – umeboshi
    Jan 25 '15 at 3:50





    dd is reliable with the non-obscure bs=1

    – umeboshi
    Jan 25 '15 at 3:50




    2




    2





    @umeboshi But reliable only if you're experienced enough to know exactly what you're doing. Fordd can be fairly dangerous (if not to say: devastating) if only a slight mistake was made. So for new users, I'd rather recommend the tee method to be on the safe shore.

    – syntaxerror
    Jan 29 '16 at 17:38







    @umeboshi But reliable only if you're experienced enough to know exactly what you're doing. Fordd can be fairly dangerous (if not to say: devastating) if only a slight mistake was made. So for new users, I'd rather recommend the tee method to be on the safe shore.

    – syntaxerror
    Jan 29 '16 at 17:38






    1




    1





    @AdamKatz, in the case of dd of=file alone (without count/skip...), it is reliable. iflag=fullblock is not needed because here dd writes on output what it has read on input. It doesn't matter if it was not full blocks.

    – Stéphane Chazelas
    Sep 12 '17 at 11:30





    @AdamKatz, in the case of dd of=file alone (without count/skip...), it is reliable. iflag=fullblock is not needed because here dd writes on output what it has read on input. It doesn't matter if it was not full blocks.

    – Stéphane Chazelas
    Sep 12 '17 at 11:30











    12














    tee is probably the best choice, but depending on your situation something like this may be enough:



    sudo sh -c 'echo test > /tmp/foo'





    share|improve this answer





















    • 1





      3 problems: eval instead of a simple sh -c; -i, which will change your working dir; running the whole command as root, which might change it's behaviour or may introduce an unnecessary risk. why did this ever get an upvote?

      – user601
      Aug 31 '10 at 10:38






    • 4





      you didn't, but it is misleading, generally bad and maybe even dangerous.

      – user601
      Aug 31 '10 at 20:24
















    12














    tee is probably the best choice, but depending on your situation something like this may be enough:



    sudo sh -c 'echo test > /tmp/foo'





    share|improve this answer





















    • 1





      3 problems: eval instead of a simple sh -c; -i, which will change your working dir; running the whole command as root, which might change it's behaviour or may introduce an unnecessary risk. why did this ever get an upvote?

      – user601
      Aug 31 '10 at 10:38






    • 4





      you didn't, but it is misleading, generally bad and maybe even dangerous.

      – user601
      Aug 31 '10 at 20:24














    12












    12








    12







    tee is probably the best choice, but depending on your situation something like this may be enough:



    sudo sh -c 'echo test > /tmp/foo'





    share|improve this answer















    tee is probably the best choice, but depending on your situation something like this may be enough:



    sudo sh -c 'echo test > /tmp/foo'






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jan 20 '18 at 8:41

























    answered Aug 31 '10 at 7:28









    phunehehephunehehe

    12.2k1782138




    12.2k1782138








    • 1





      3 problems: eval instead of a simple sh -c; -i, which will change your working dir; running the whole command as root, which might change it's behaviour or may introduce an unnecessary risk. why did this ever get an upvote?

      – user601
      Aug 31 '10 at 10:38






    • 4





      you didn't, but it is misleading, generally bad and maybe even dangerous.

      – user601
      Aug 31 '10 at 20:24














    • 1





      3 problems: eval instead of a simple sh -c; -i, which will change your working dir; running the whole command as root, which might change it's behaviour or may introduce an unnecessary risk. why did this ever get an upvote?

      – user601
      Aug 31 '10 at 10:38






    • 4





      you didn't, but it is misleading, generally bad and maybe even dangerous.

      – user601
      Aug 31 '10 at 20:24








    1




    1





    3 problems: eval instead of a simple sh -c; -i, which will change your working dir; running the whole command as root, which might change it's behaviour or may introduce an unnecessary risk. why did this ever get an upvote?

    – user601
    Aug 31 '10 at 10:38





    3 problems: eval instead of a simple sh -c; -i, which will change your working dir; running the whole command as root, which might change it's behaviour or may introduce an unnecessary risk. why did this ever get an upvote?

    – user601
    Aug 31 '10 at 10:38




    4




    4





    you didn't, but it is misleading, generally bad and maybe even dangerous.

    – user601
    Aug 31 '10 at 20:24





    you didn't, but it is misleading, generally bad and maybe even dangerous.

    – user601
    Aug 31 '10 at 20:24











    5














    While I agree, that | sudo tee is the canonical way, sometimes sed (here assuming GNU sed) may work:



    cat sudotest 
    line 1

    sudo sed -i '1iitest' sudotest && cat sudotest
    itest
    line 1

    sudo sed -i '$aatest' sudotest && cat sudotest
    itest
    line 1
    atest


    -i modifies the file in place. 1i means insert before line 1. $a means append after last line.



    Or copy to xclipboard:



    somecommand | xclip
    sudo gedit sudotest
    move cursor to desired place, click middle mouse button to insert, save





    share|improve this answer





















    • 1





      This is worded like an Ancient Chinese riddle. Can't see to understand how this got so many upvotes. (hrmph)

      – syntaxerror
      Jan 29 '16 at 17:36











    • @syntaxerror: Sir, I'm sorry, I'm not a native English speaker. If you specify what is unclear to you, I could try to improve my answer. Compared with 65 upvotes for Gert, 4 doesn't seem to be that many upvotes, either, don't you think?

      – user unknown
      Jan 30 '16 at 1:35











    • Well I would be pretty satisfied with 4 :-D Your English is not bad at all. It's just worded in a kind of terse techie nerdspeak. I must guess you're a coder. Coders amongst each other will understand themselves perfectly that way, but a non-coder must think it's worded like...as said.

      – syntaxerror
      Jan 31 '16 at 20:22













    • Note that sed -i does not actually modify the file in place - it creates a temporary file and renames it on exiting. So you won't be able to do something like tail -f ... on the original file and see the output using sed -i ... while the pipeline is running

      – Andrew Henle
      Mar 14 '18 at 10:24













    • @AndrewHenle: Yes, since the size may be increased or shrinked, and since that's probably the case for most sed invocations, and you can't even - afaik - write to the same location on SSDs it's only a pseudo 'in place' operation. As a non native english speaker, may I ask for a brief expression, which isn't so likely misinterpreted? Just -i creates a new file of same name or is there something more compact? I guess I like in place, because it explains the i. The gnu-sed manpage calls it in place too and the long flag is --in-place.

      – user unknown
      Mar 14 '18 at 10:30


















    5














    While I agree, that | sudo tee is the canonical way, sometimes sed (here assuming GNU sed) may work:



    cat sudotest 
    line 1

    sudo sed -i '1iitest' sudotest && cat sudotest
    itest
    line 1

    sudo sed -i '$aatest' sudotest && cat sudotest
    itest
    line 1
    atest


    -i modifies the file in place. 1i means insert before line 1. $a means append after last line.



    Or copy to xclipboard:



    somecommand | xclip
    sudo gedit sudotest
    move cursor to desired place, click middle mouse button to insert, save





    share|improve this answer





















    • 1





      This is worded like an Ancient Chinese riddle. Can't see to understand how this got so many upvotes. (hrmph)

      – syntaxerror
      Jan 29 '16 at 17:36











    • @syntaxerror: Sir, I'm sorry, I'm not a native English speaker. If you specify what is unclear to you, I could try to improve my answer. Compared with 65 upvotes for Gert, 4 doesn't seem to be that many upvotes, either, don't you think?

      – user unknown
      Jan 30 '16 at 1:35











    • Well I would be pretty satisfied with 4 :-D Your English is not bad at all. It's just worded in a kind of terse techie nerdspeak. I must guess you're a coder. Coders amongst each other will understand themselves perfectly that way, but a non-coder must think it's worded like...as said.

      – syntaxerror
      Jan 31 '16 at 20:22













    • Note that sed -i does not actually modify the file in place - it creates a temporary file and renames it on exiting. So you won't be able to do something like tail -f ... on the original file and see the output using sed -i ... while the pipeline is running

      – Andrew Henle
      Mar 14 '18 at 10:24













    • @AndrewHenle: Yes, since the size may be increased or shrinked, and since that's probably the case for most sed invocations, and you can't even - afaik - write to the same location on SSDs it's only a pseudo 'in place' operation. As a non native english speaker, may I ask for a brief expression, which isn't so likely misinterpreted? Just -i creates a new file of same name or is there something more compact? I guess I like in place, because it explains the i. The gnu-sed manpage calls it in place too and the long flag is --in-place.

      – user unknown
      Mar 14 '18 at 10:30
















    5












    5








    5







    While I agree, that | sudo tee is the canonical way, sometimes sed (here assuming GNU sed) may work:



    cat sudotest 
    line 1

    sudo sed -i '1iitest' sudotest && cat sudotest
    itest
    line 1

    sudo sed -i '$aatest' sudotest && cat sudotest
    itest
    line 1
    atest


    -i modifies the file in place. 1i means insert before line 1. $a means append after last line.



    Or copy to xclipboard:



    somecommand | xclip
    sudo gedit sudotest
    move cursor to desired place, click middle mouse button to insert, save





    share|improve this answer















    While I agree, that | sudo tee is the canonical way, sometimes sed (here assuming GNU sed) may work:



    cat sudotest 
    line 1

    sudo sed -i '1iitest' sudotest && cat sudotest
    itest
    line 1

    sudo sed -i '$aatest' sudotest && cat sudotest
    itest
    line 1
    atest


    -i modifies the file in place. 1i means insert before line 1. $a means append after last line.



    Or copy to xclipboard:



    somecommand | xclip
    sudo gedit sudotest
    move cursor to desired place, click middle mouse button to insert, save






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Sep 12 '17 at 21:24

























    answered Jul 19 '11 at 2:11









    user unknownuser unknown

    7,23312248




    7,23312248








    • 1





      This is worded like an Ancient Chinese riddle. Can't see to understand how this got so many upvotes. (hrmph)

      – syntaxerror
      Jan 29 '16 at 17:36











    • @syntaxerror: Sir, I'm sorry, I'm not a native English speaker. If you specify what is unclear to you, I could try to improve my answer. Compared with 65 upvotes for Gert, 4 doesn't seem to be that many upvotes, either, don't you think?

      – user unknown
      Jan 30 '16 at 1:35











    • Well I would be pretty satisfied with 4 :-D Your English is not bad at all. It's just worded in a kind of terse techie nerdspeak. I must guess you're a coder. Coders amongst each other will understand themselves perfectly that way, but a non-coder must think it's worded like...as said.

      – syntaxerror
      Jan 31 '16 at 20:22













    • Note that sed -i does not actually modify the file in place - it creates a temporary file and renames it on exiting. So you won't be able to do something like tail -f ... on the original file and see the output using sed -i ... while the pipeline is running

      – Andrew Henle
      Mar 14 '18 at 10:24













    • @AndrewHenle: Yes, since the size may be increased or shrinked, and since that's probably the case for most sed invocations, and you can't even - afaik - write to the same location on SSDs it's only a pseudo 'in place' operation. As a non native english speaker, may I ask for a brief expression, which isn't so likely misinterpreted? Just -i creates a new file of same name or is there something more compact? I guess I like in place, because it explains the i. The gnu-sed manpage calls it in place too and the long flag is --in-place.

      – user unknown
      Mar 14 '18 at 10:30
















    • 1





      This is worded like an Ancient Chinese riddle. Can't see to understand how this got so many upvotes. (hrmph)

      – syntaxerror
      Jan 29 '16 at 17:36











    • @syntaxerror: Sir, I'm sorry, I'm not a native English speaker. If you specify what is unclear to you, I could try to improve my answer. Compared with 65 upvotes for Gert, 4 doesn't seem to be that many upvotes, either, don't you think?

      – user unknown
      Jan 30 '16 at 1:35











    • Well I would be pretty satisfied with 4 :-D Your English is not bad at all. It's just worded in a kind of terse techie nerdspeak. I must guess you're a coder. Coders amongst each other will understand themselves perfectly that way, but a non-coder must think it's worded like...as said.

      – syntaxerror
      Jan 31 '16 at 20:22













    • Note that sed -i does not actually modify the file in place - it creates a temporary file and renames it on exiting. So you won't be able to do something like tail -f ... on the original file and see the output using sed -i ... while the pipeline is running

      – Andrew Henle
      Mar 14 '18 at 10:24













    • @AndrewHenle: Yes, since the size may be increased or shrinked, and since that's probably the case for most sed invocations, and you can't even - afaik - write to the same location on SSDs it's only a pseudo 'in place' operation. As a non native english speaker, may I ask for a brief expression, which isn't so likely misinterpreted? Just -i creates a new file of same name or is there something more compact? I guess I like in place, because it explains the i. The gnu-sed manpage calls it in place too and the long flag is --in-place.

      – user unknown
      Mar 14 '18 at 10:30










    1




    1





    This is worded like an Ancient Chinese riddle. Can't see to understand how this got so many upvotes. (hrmph)

    – syntaxerror
    Jan 29 '16 at 17:36





    This is worded like an Ancient Chinese riddle. Can't see to understand how this got so many upvotes. (hrmph)

    – syntaxerror
    Jan 29 '16 at 17:36













    @syntaxerror: Sir, I'm sorry, I'm not a native English speaker. If you specify what is unclear to you, I could try to improve my answer. Compared with 65 upvotes for Gert, 4 doesn't seem to be that many upvotes, either, don't you think?

    – user unknown
    Jan 30 '16 at 1:35





    @syntaxerror: Sir, I'm sorry, I'm not a native English speaker. If you specify what is unclear to you, I could try to improve my answer. Compared with 65 upvotes for Gert, 4 doesn't seem to be that many upvotes, either, don't you think?

    – user unknown
    Jan 30 '16 at 1:35













    Well I would be pretty satisfied with 4 :-D Your English is not bad at all. It's just worded in a kind of terse techie nerdspeak. I must guess you're a coder. Coders amongst each other will understand themselves perfectly that way, but a non-coder must think it's worded like...as said.

    – syntaxerror
    Jan 31 '16 at 20:22







    Well I would be pretty satisfied with 4 :-D Your English is not bad at all. It's just worded in a kind of terse techie nerdspeak. I must guess you're a coder. Coders amongst each other will understand themselves perfectly that way, but a non-coder must think it's worded like...as said.

    – syntaxerror
    Jan 31 '16 at 20:22















    Note that sed -i does not actually modify the file in place - it creates a temporary file and renames it on exiting. So you won't be able to do something like tail -f ... on the original file and see the output using sed -i ... while the pipeline is running

    – Andrew Henle
    Mar 14 '18 at 10:24







    Note that sed -i does not actually modify the file in place - it creates a temporary file and renames it on exiting. So you won't be able to do something like tail -f ... on the original file and see the output using sed -i ... while the pipeline is running

    – Andrew Henle
    Mar 14 '18 at 10:24















    @AndrewHenle: Yes, since the size may be increased or shrinked, and since that's probably the case for most sed invocations, and you can't even - afaik - write to the same location on SSDs it's only a pseudo 'in place' operation. As a non native english speaker, may I ask for a brief expression, which isn't so likely misinterpreted? Just -i creates a new file of same name or is there something more compact? I guess I like in place, because it explains the i. The gnu-sed manpage calls it in place too and the long flag is --in-place.

    – user unknown
    Mar 14 '18 at 10:30







    @AndrewHenle: Yes, since the size may be increased or shrinked, and since that's probably the case for most sed invocations, and you can't even - afaik - write to the same location on SSDs it's only a pseudo 'in place' operation. As a non native english speaker, may I ask for a brief expression, which isn't so likely misinterpreted? Just -i creates a new file of same name or is there something more compact? I guess I like in place, because it explains the i. The gnu-sed manpage calls it in place too and the long flag is --in-place.

    – user unknown
    Mar 14 '18 at 10:30













    2














    I have been kicking around in the back of my mind ideas for a similar problem, and came up with the following solutions:




    • sudo uncat where uncat is a program that reads standard input and writes it to the file named on the command line, but I haven't written uncat yet.


    • sudocat the variant of sudoedit that I haven't written yet that does a cleaner sudo cat or sudo uncat.



    • or this little trick of using sudoedit with an EDITOR that is a shell script



      #!/bin/sh
      # uncat
      cat > "$1"


      which can be invoked as either |sudo ./uncat file or | EDITOR=./uncat sudoedit but that has interesting side-effects.








    share|improve this answer


























    • cat takes a list of files to concatinate, therefore uncat should take a list of files to un concatinate to. It would have to use magic to decide how much to put in each file. Alternative name include dog, to-file, redirect.

      – ctrl-alt-delor
      Apr 15 '15 at 14:51













    • I can't think of any reason why I would want uncat when I have tee.

      – Wildcard
      Sep 29 '15 at 9:26






    • 1





      Well, tee has the trivial drawback that it writes its stdin to its stdout — which is trivially mitigated by redirecting the stdout to /dev/null.  Other alternatives include dd of=/tmp/foo (mentioned in another answer), which writes status information to stderr, and cp /dev/stdin /tmp/foo.

      – Scott
      Feb 17 '16 at 14:44
















    2














    I have been kicking around in the back of my mind ideas for a similar problem, and came up with the following solutions:




    • sudo uncat where uncat is a program that reads standard input and writes it to the file named on the command line, but I haven't written uncat yet.


    • sudocat the variant of sudoedit that I haven't written yet that does a cleaner sudo cat or sudo uncat.



    • or this little trick of using sudoedit with an EDITOR that is a shell script



      #!/bin/sh
      # uncat
      cat > "$1"


      which can be invoked as either |sudo ./uncat file or | EDITOR=./uncat sudoedit but that has interesting side-effects.








    share|improve this answer


























    • cat takes a list of files to concatinate, therefore uncat should take a list of files to un concatinate to. It would have to use magic to decide how much to put in each file. Alternative name include dog, to-file, redirect.

      – ctrl-alt-delor
      Apr 15 '15 at 14:51













    • I can't think of any reason why I would want uncat when I have tee.

      – Wildcard
      Sep 29 '15 at 9:26






    • 1





      Well, tee has the trivial drawback that it writes its stdin to its stdout — which is trivially mitigated by redirecting the stdout to /dev/null.  Other alternatives include dd of=/tmp/foo (mentioned in another answer), which writes status information to stderr, and cp /dev/stdin /tmp/foo.

      – Scott
      Feb 17 '16 at 14:44














    2












    2








    2







    I have been kicking around in the back of my mind ideas for a similar problem, and came up with the following solutions:




    • sudo uncat where uncat is a program that reads standard input and writes it to the file named on the command line, but I haven't written uncat yet.


    • sudocat the variant of sudoedit that I haven't written yet that does a cleaner sudo cat or sudo uncat.



    • or this little trick of using sudoedit with an EDITOR that is a shell script



      #!/bin/sh
      # uncat
      cat > "$1"


      which can be invoked as either |sudo ./uncat file or | EDITOR=./uncat sudoedit but that has interesting side-effects.








    share|improve this answer















    I have been kicking around in the back of my mind ideas for a similar problem, and came up with the following solutions:




    • sudo uncat where uncat is a program that reads standard input and writes it to the file named on the command line, but I haven't written uncat yet.


    • sudocat the variant of sudoedit that I haven't written yet that does a cleaner sudo cat or sudo uncat.



    • or this little trick of using sudoedit with an EDITOR that is a shell script



      #!/bin/sh
      # uncat
      cat > "$1"


      which can be invoked as either |sudo ./uncat file or | EDITOR=./uncat sudoedit but that has interesting side-effects.









    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Sep 12 '17 at 11:44









    Stéphane Chazelas

    301k55564916




    301k55564916










    answered Nov 20 '13 at 2:16









    hildredhildred

    4,73622137




    4,73622137













    • cat takes a list of files to concatinate, therefore uncat should take a list of files to un concatinate to. It would have to use magic to decide how much to put in each file. Alternative name include dog, to-file, redirect.

      – ctrl-alt-delor
      Apr 15 '15 at 14:51













    • I can't think of any reason why I would want uncat when I have tee.

      – Wildcard
      Sep 29 '15 at 9:26






    • 1





      Well, tee has the trivial drawback that it writes its stdin to its stdout — which is trivially mitigated by redirecting the stdout to /dev/null.  Other alternatives include dd of=/tmp/foo (mentioned in another answer), which writes status information to stderr, and cp /dev/stdin /tmp/foo.

      – Scott
      Feb 17 '16 at 14:44



















    • cat takes a list of files to concatinate, therefore uncat should take a list of files to un concatinate to. It would have to use magic to decide how much to put in each file. Alternative name include dog, to-file, redirect.

      – ctrl-alt-delor
      Apr 15 '15 at 14:51













    • I can't think of any reason why I would want uncat when I have tee.

      – Wildcard
      Sep 29 '15 at 9:26






    • 1





      Well, tee has the trivial drawback that it writes its stdin to its stdout — which is trivially mitigated by redirecting the stdout to /dev/null.  Other alternatives include dd of=/tmp/foo (mentioned in another answer), which writes status information to stderr, and cp /dev/stdin /tmp/foo.

      – Scott
      Feb 17 '16 at 14:44

















    cat takes a list of files to concatinate, therefore uncat should take a list of files to un concatinate to. It would have to use magic to decide how much to put in each file. Alternative name include dog, to-file, redirect.

    – ctrl-alt-delor
    Apr 15 '15 at 14:51







    cat takes a list of files to concatinate, therefore uncat should take a list of files to un concatinate to. It would have to use magic to decide how much to put in each file. Alternative name include dog, to-file, redirect.

    – ctrl-alt-delor
    Apr 15 '15 at 14:51















    I can't think of any reason why I would want uncat when I have tee.

    – Wildcard
    Sep 29 '15 at 9:26





    I can't think of any reason why I would want uncat when I have tee.

    – Wildcard
    Sep 29 '15 at 9:26




    1




    1





    Well, tee has the trivial drawback that it writes its stdin to its stdout — which is trivially mitigated by redirecting the stdout to /dev/null.  Other alternatives include dd of=/tmp/foo (mentioned in another answer), which writes status information to stderr, and cp /dev/stdin /tmp/foo.

    – Scott
    Feb 17 '16 at 14:44





    Well, tee has the trivial drawback that it writes its stdin to its stdout — which is trivially mitigated by redirecting the stdout to /dev/null.  Other alternatives include dd of=/tmp/foo (mentioned in another answer), which writes status information to stderr, and cp /dev/stdin /tmp/foo.

    – Scott
    Feb 17 '16 at 14:44











    1














    Use sponge from the moreutils package. It has the advantage that it does not write to stdout.



    echo test | sudo sponge /tmp/foo


    Use the -a option to append to a file instead of overwriting it.






    share|improve this answer



















    • 1





      I'm not sure what advantage not writing to stdout presents, but you could just redirect the output to /dev/null if it were an issue

      – Michael Mrozek
      Dec 18 '16 at 4:41






    • 1





      Of course I can redirect to /dev/null, but the command is easier to read and type without the redirection. The advantage of not writing to stdout is that my terminal is not filled with rubbish.

      – Hontvári Levente
      Dec 18 '16 at 22:48






    • 1





      I would not install a package to spare a redirection, but I regularly use sponge, so it is already there.

      – Hontvári Levente
      Dec 18 '16 at 22:50
















    1














    Use sponge from the moreutils package. It has the advantage that it does not write to stdout.



    echo test | sudo sponge /tmp/foo


    Use the -a option to append to a file instead of overwriting it.






    share|improve this answer



















    • 1





      I'm not sure what advantage not writing to stdout presents, but you could just redirect the output to /dev/null if it were an issue

      – Michael Mrozek
      Dec 18 '16 at 4:41






    • 1





      Of course I can redirect to /dev/null, but the command is easier to read and type without the redirection. The advantage of not writing to stdout is that my terminal is not filled with rubbish.

      – Hontvári Levente
      Dec 18 '16 at 22:48






    • 1





      I would not install a package to spare a redirection, but I regularly use sponge, so it is already there.

      – Hontvári Levente
      Dec 18 '16 at 22:50














    1












    1








    1







    Use sponge from the moreutils package. It has the advantage that it does not write to stdout.



    echo test | sudo sponge /tmp/foo


    Use the -a option to append to a file instead of overwriting it.






    share|improve this answer













    Use sponge from the moreutils package. It has the advantage that it does not write to stdout.



    echo test | sudo sponge /tmp/foo


    Use the -a option to append to a file instead of overwriting it.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Dec 17 '16 at 21:46









    Hontvári LeventeHontvári Levente

    42147




    42147








    • 1





      I'm not sure what advantage not writing to stdout presents, but you could just redirect the output to /dev/null if it were an issue

      – Michael Mrozek
      Dec 18 '16 at 4:41






    • 1





      Of course I can redirect to /dev/null, but the command is easier to read and type without the redirection. The advantage of not writing to stdout is that my terminal is not filled with rubbish.

      – Hontvári Levente
      Dec 18 '16 at 22:48






    • 1





      I would not install a package to spare a redirection, but I regularly use sponge, so it is already there.

      – Hontvári Levente
      Dec 18 '16 at 22:50














    • 1





      I'm not sure what advantage not writing to stdout presents, but you could just redirect the output to /dev/null if it were an issue

      – Michael Mrozek
      Dec 18 '16 at 4:41






    • 1





      Of course I can redirect to /dev/null, but the command is easier to read and type without the redirection. The advantage of not writing to stdout is that my terminal is not filled with rubbish.

      – Hontvári Levente
      Dec 18 '16 at 22:48






    • 1





      I would not install a package to spare a redirection, but I regularly use sponge, so it is already there.

      – Hontvári Levente
      Dec 18 '16 at 22:50








    1




    1





    I'm not sure what advantage not writing to stdout presents, but you could just redirect the output to /dev/null if it were an issue

    – Michael Mrozek
    Dec 18 '16 at 4:41





    I'm not sure what advantage not writing to stdout presents, but you could just redirect the output to /dev/null if it were an issue

    – Michael Mrozek
    Dec 18 '16 at 4:41




    1




    1





    Of course I can redirect to /dev/null, but the command is easier to read and type without the redirection. The advantage of not writing to stdout is that my terminal is not filled with rubbish.

    – Hontvári Levente
    Dec 18 '16 at 22:48





    Of course I can redirect to /dev/null, but the command is easier to read and type without the redirection. The advantage of not writing to stdout is that my terminal is not filled with rubbish.

    – Hontvári Levente
    Dec 18 '16 at 22:48




    1




    1





    I would not install a package to spare a redirection, but I regularly use sponge, so it is already there.

    – Hontvári Levente
    Dec 18 '16 at 22:50





    I would not install a package to spare a redirection, but I regularly use sponge, so it is already there.

    – Hontvári Levente
    Dec 18 '16 at 22:50











    0














    The error comes from the order in which the shell does things.



    The redirection is handled before the shell even executes sudo, and is therefore done with the permissions of the user that you are currently working as. Since you don't have write permissions to create/truncate the target of the redirection, you get a permission denied error from the shell.



    The solution is to guarantee that the output file is created under the identity given to you by sudo, e.g. with tee:



    $ generate_output | sudo tee target_file





    share|improve this answer




























      0














      The error comes from the order in which the shell does things.



      The redirection is handled before the shell even executes sudo, and is therefore done with the permissions of the user that you are currently working as. Since you don't have write permissions to create/truncate the target of the redirection, you get a permission denied error from the shell.



      The solution is to guarantee that the output file is created under the identity given to you by sudo, e.g. with tee:



      $ generate_output | sudo tee target_file





      share|improve this answer


























        0












        0








        0







        The error comes from the order in which the shell does things.



        The redirection is handled before the shell even executes sudo, and is therefore done with the permissions of the user that you are currently working as. Since you don't have write permissions to create/truncate the target of the redirection, you get a permission denied error from the shell.



        The solution is to guarantee that the output file is created under the identity given to you by sudo, e.g. with tee:



        $ generate_output | sudo tee target_file





        share|improve this answer













        The error comes from the order in which the shell does things.



        The redirection is handled before the shell even executes sudo, and is therefore done with the permissions of the user that you are currently working as. Since you don't have write permissions to create/truncate the target of the redirection, you get a permission denied error from the shell.



        The solution is to guarantee that the output file is created under the identity given to you by sudo, e.g. with tee:



        $ generate_output | sudo tee target_file






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Feb 4 '17 at 9:36









        KusalanandaKusalananda

        124k16234385




        124k16234385






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f1416%2fredirecting-stdout-to-a-file-you-dont-have-write-permission-on%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Morgemoulin

            Scott Moir

            Souastre