Find the answer to your Linux question:
Results 1 to 7 of 7
Hello everyone, A bash question. Why does Code: sudo echo -e "echo" > /etc/apt/sources.list.d/echo.txt returns Code: bash: /etc/apt/sources.list.d/echo.txt: Permission denied ? everything works well after a Code: sudo su . ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Sep 2009
    Posts
    32

    Question sudo echo"xxx" > e.txt


    Hello everyone,
    A bash question.
    Why does
    Code:
    sudo echo -e "echo" > /etc/apt/sources.list.d/echo.txt
    returns
    Code:
    bash: /etc/apt/sources.list.d/echo.txt: Permission denied
    ?
    everything works well after a
    Code:
    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.

  2. #2
    Linux Guru reed9's Avatar
    Join Date
    Feb 2009
    Location
    Boston, MA
    Posts
    4,651
    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.

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

  3. #3
    Just Joined!
    Join Date
    Sep 2009
    Posts
    32
    So one could say that actually the command in question does not have a form of
    Code:
    sudo (echo xxx > file)
    , but rather something a bit like
    Code:
    >[(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!

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru reed9's Avatar
    Join Date
    Feb 2009
    Location
    Boston, MA
    Posts
    4,651
    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.
    Code:
    echo "echo text >> /etc/apt/sources.list.d/echo.txt" | sudo sh
    Code:
    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

  6. #5
    Just Joined!
    Join Date
    Sep 2009
    Posts
    32
    Quote Originally Posted by reed9 View Post
    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.

    Code:
    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.

    Code:
    sudo sh -c 'echo "text" >> /etc/apt/sources.list.d/echo.txt'
    I understand (after some experimenting like
    Code:
    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.

  7. #6
    Linux Guru reed9's Avatar
    Join Date
    Feb 2009
    Location
    Boston, MA
    Posts
    4,651
    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
    Code:
    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)

  8. #7
    Just Joined!
    Join Date
    Sep 2009
    Posts
    32
    Quote Originally Posted by reed9 View Post
    sudo sh is opening a root shell. So this
    Code:
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •