How do I use sudo to redirect output to a location I don't have permission to write to?

Multi tool use
I've been given sudo access on one of our development RedHat linux boxes, and I seem to find myself quite often needing to redirect output to a location I don't normally have write access to.
The trouble is, this contrived example doesn't work:
sudo ls -hal /root/ > /root/test.out
I just receive the response:
-bash: /root/test.out: Permission denied
How can I get this to work?
linux permissions sudo io-redirection permission-denied
add a comment |
I've been given sudo access on one of our development RedHat linux boxes, and I seem to find myself quite often needing to redirect output to a location I don't normally have write access to.
The trouble is, this contrived example doesn't work:
sudo ls -hal /root/ > /root/test.out
I just receive the response:
-bash: /root/test.out: Permission denied
How can I get this to work?
linux permissions sudo io-redirection permission-denied
1
use chmod u+w filename
– Szabolcs Dombi
Jul 10 '16 at 15:33
@DombiSzabolcs You are suggesting that I create the file as sudo first, then give myself permission? Good idea.
– Jonathan
Jul 10 '16 at 15:36
add a comment |
I've been given sudo access on one of our development RedHat linux boxes, and I seem to find myself quite often needing to redirect output to a location I don't normally have write access to.
The trouble is, this contrived example doesn't work:
sudo ls -hal /root/ > /root/test.out
I just receive the response:
-bash: /root/test.out: Permission denied
How can I get this to work?
linux permissions sudo io-redirection permission-denied
I've been given sudo access on one of our development RedHat linux boxes, and I seem to find myself quite often needing to redirect output to a location I don't normally have write access to.
The trouble is, this contrived example doesn't work:
sudo ls -hal /root/ > /root/test.out
I just receive the response:
-bash: /root/test.out: Permission denied
How can I get this to work?
linux permissions sudo io-redirection permission-denied
linux permissions sudo io-redirection permission-denied
edited Oct 24 '17 at 22:09
smci
14.9k673104
14.9k673104
asked Sep 17 '08 at 11:44
JonathanJonathan
15.1k105677
15.1k105677
1
use chmod u+w filename
– Szabolcs Dombi
Jul 10 '16 at 15:33
@DombiSzabolcs You are suggesting that I create the file as sudo first, then give myself permission? Good idea.
– Jonathan
Jul 10 '16 at 15:36
add a comment |
1
use chmod u+w filename
– Szabolcs Dombi
Jul 10 '16 at 15:33
@DombiSzabolcs You are suggesting that I create the file as sudo first, then give myself permission? Good idea.
– Jonathan
Jul 10 '16 at 15:36
1
1
use chmod u+w filename
– Szabolcs Dombi
Jul 10 '16 at 15:33
use chmod u+w filename
– Szabolcs Dombi
Jul 10 '16 at 15:33
@DombiSzabolcs You are suggesting that I create the file as sudo first, then give myself permission? Good idea.
– Jonathan
Jul 10 '16 at 15:36
@DombiSzabolcs You are suggesting that I create the file as sudo first, then give myself permission? Good idea.
– Jonathan
Jul 10 '16 at 15:36
add a comment |
15 Answers
15
active
oldest
votes
Your command does not work because the redirection is performed by your shell which does not have the permission to write to /root/test.out
. The redirection of the output is not performed by sudo.
There are multiple solutions:
Run a shell with sudo and give the command to it by using the
-c
option:
sudo sh -c 'ls -hal /root/ > /root/test.out'
Create a script with your commands and run that script with sudo:
#!/bin/sh
ls -hal /root/ > /root/test.out
Run
sudo ls.sh
. See Steve Bennett's answer if you don't want to create a temporary file.
Launch a shell with
sudo -s
then run your commands:
[nobody@so]$ sudo -s
[root@so]# ls -hal /root/ > /root/test.out
[root@so]# ^D
[nobody@so]$
Use
sudo tee
(if you have to escape a lot when using the-c
option):
sudo ls -hal /root/ | sudo tee /root/test.out > /dev/null
The redirect to
/dev/null
is needed to stop tee from outputting to the screen. To append instead of overwriting the output file
(>>
), usetee -a
ortee --append
(the last one is specific to GNU coreutils).
Thanks go to Jd, Adam J. Forster and Johnathan for the second, third and fourth solutions.
1
There's a great answer that tells you how to redirect STDERR and STDOUT separately here: stackoverflow.com/questions/692000/… ... basicallyperl -e 'print "STDINn"; print STDERR "STDERRn"; ' > >( tee stdout.log ) 2> >( tee stderr.log >&2 )
– errant.info
Jun 13 '13 at 11:40
2
You'll want to do 'sudo -E ...' in order to use variables in the shelled out command (when using this in a script, for instance).
– Urhixidur
Feb 14 '14 at 21:28
1
Redirecting tee output to /dev/null is probably not necessary in a lot of cases where echoing the output to screen is harmless. For example, when dealing just with output of regular commands or contents of small text files.
– thomasrutter
Jul 7 '15 at 1:36
add a comment |
Someone here has just suggested sudoing tee:
sudo ls -hal /root/ | sudo tee /root/test.out > /dev/null
This could also be used to redirect any command, to a directory that you do not have access to. It works because the tee program is effectively an "echo to a file" program, and the redirect to /dev/null is to stop it also outputting to the screen to keep it the same as the original contrived example above.
3
In many cases, namely if the normal user has prmissions to perform the command and "only" cannot write to the desired output file, the firstsudo
(i.e., for the command itself) might be omitted
– Hagen von Eitzen
Aug 26 '16 at 8:38
add a comment |
A trick I figured out myself was
sudo ls -hal /root/ | sudo dd of=/root/test.out
14
sudo dd
is better than thesudo tee /root/file > /dev/null
examples above!
– kristianlm
Mar 6 '13 at 12:45
10
dd is not a weird obscure command. It is used whenever you need to copy large amounts of data with buffering between two block devices. The syntax is actually pretty simple,dd
is the command name,of=/root/test.out
is the argument which tellsdd
what the Output Files is.
– rhlee
Jul 24 '13 at 18:48
11
@steve Everything is 'obscure' until you learn what it is.of
means output file anddd
is a very popular tool used in both Linux and OSX (mostly for writing images to disks). This is a neat trick for sure.
– blockloop
Apr 14 '14 at 19:24
10
dd
is probably equally useful astee
here. In both cases you're using a common, well-known command for a purpose that, while slightly different to its original intended purpose, is still well-known and well-documented. Whiledd
is good at copying huge amounts of data, it doesn't suck with small amounts. It has the benefit here of not echoing the output to standard output as well.
– thomasrutter
Jul 7 '15 at 1:39
19
Whenever you type wordssudo dd
next to one another, you want to make very, very sure that the arguments that follow are correct (especially considering its non-standard syntax). They don't call it "disk destroyer" for nothing...
– ali_m
Jan 5 '16 at 21:44
|
show 5 more comments
The problem is that the command gets run under sudo
, but the redirection gets run under your user. This is done by the shell and there is very little you can do about it.
sudo command > /some/file.log
`-----v-----'`-------v-------'
command redirection
The usual ways of bypassing this are:
Wrap the commands in a script which you call under sudo.
If the commands and/or log file changes, you can make the
script take these as arguments. For example:
sudo log_script command /log/file.txt
Call a shell and pass the command line as a parameter with
-c
This is especially useful for one off compound commands.
For example:
sudo bash -c "{ command1 arg; command2 arg; } > /log/file.txt"
add a comment |
Yet another variation on the theme:
sudo bash <<EOF
ls -hal /root/ > /root/test.out
EOF
Or of course:
echo 'ls -hal /root/ > /root/test.out' | sudo bash
They have the (tiny) advantage that you don't need to remember any arguments to sudo
or sh
/bash
add a comment |
Clarifying a bit on why the tee option is preferable
Assuming you have appropriate permission to execute the command that creates the output, if you pipe the output of your command to tee, you only need to elevate tee's privledges with sudo and direct tee to write (or append) to the file in question.
in the example given in the question that would mean:
ls -hal /root/ | sudo tee /root/test.out
for a couple more practical examples:
# kill off one source of annoying advertisements
echo 127.0.0.1 ad.doubleclick.net | sudo tee -a /etc/hosts
# configure eth4 to come up on boot, set IP and netmask (centos 6.4)
echo -e "ONBOOT="YES"nIPADDR=10.42.84.168nPREFIX=24" | sudo tee -a /etc/sysconfig/network-scripts/ifcfg-eth4
In each of these examples you are taking the output of a non-privileged command and writing to a file that is usually only writable by root, which is the origin of your question.
It is a good idea to do it this way because the command that generates the output is not executed with elevated privileges. It doesn't seem to matter here with echo
but when the source command is a script that you don't completely trust, it is crucial.
Note you can use the -a option to tee to append append (like >>
) to the target file rather than overwrite it (like >
).
Sorry js3, but this has already been suggested (back in 2008) and is sitting at the second highest answer: stackoverflow.com/a/82553/6910
– Jonathan
Nov 6 '13 at 10:24
2
You're right, Jonathan, I'll update my answer to expand on the reasons why this is a preferable option. Thanks for the helpful feedback.
– jg3
Nov 7 '13 at 18:23
add a comment |
Make sudo run a shell, like this:
sudo sh -c "echo foo > ~root/out"
add a comment |
The way I would go about this issue is:
If you need to write/replace the file:
echo "some text" | sudo tee /path/to/file
If you need to append to the file:
echo "some text" | sudo tee -a /path/to/file
1
How is this substantially different to answers above?
– Jonathan
Jun 24 '16 at 19:50
add a comment |
How about writing a script?
Filename: myscript
#!/bin/sh
/bin/ls -lah /root > /root/test.out
# end script
Then use sudo to run the script:
sudo ./myscript
add a comment |
I would do it this way:
sudo su -c 'ls -hal /root/ > /root/test.out'
2
That actually seems a bit cleaner, as you don't need to explicitly specify the shell.
– Steve Bennett
May 13 '13 at 2:13
1
One small drawback is that it runs one additional process (su
):$ sudo su -c 'pstree -sp $$ >/dev/fd/1'
init(1)───gnome-terminal(6880)───bash(6945)───sudo(401)───su(402)───bash(410)───pstree(411)
– pabouk
Jul 28 '13 at 11:34
add a comment |
Whenever I have to do something like this I just become root:
# sudo -s
# ls -hal /root/ > /root/test.out
# exit
It's probably not the best way, but it works.
add a comment |
Don't mean to beat a dead horse, but there are too many answers here that use tee
, which means you have to redirect stdout
to /dev/null
unless you want to see a copy on the screen. A simpler solution is to just use cat
like this:
sudo ls -hal /root/ | sudo bash -c "cat > /root/test.out"
Notice how the redirection is put inside quotes so that it is evaluated by a shell started by sudo
instead of the one running it.
This works just fine. I don't understand why it had one negative vote. Upvoted.
– Teemu Leisti
Nov 24 '16 at 8:28
3
I think it doesn't get much love because it's not much better thansudo bash -c "ls -hal /root > /root/test.out"
. Using tee avoids needing a shell, while cat does not.
– Nick Russo
Dec 9 '16 at 4:49
add a comment |
Here's an extension of the answer involving tee. To make things easier you might like to make a small script (I call it suwrite or you may call it sutee) and put it in /usr/local/bin/ with +x permission:
#! /bin/sh
sudo tee $@ > /dev/null
Now all you have to do is to pipe the output to this script followed by the desired superuser-accessible filename and it will automatically prompt you for your password if needed (since it includes sudo).
echo test | suwrite /root/test.txt
Note that since this is a simple wrapper for tee, it will also accept tee's -a (or any other) option so to append to the desired file you just pass -a:
echo test | suwrite -a /root/test.txt
add a comment |
Maybe you been given sudo access to only some programs/paths? Then there is no way to do what you want. (unless you will hack it somehow)
If it is not the case then maybe you can write bash script:
cat > myscript.sh
#!/bin/sh
ls -hal /root/ > /root/test.out
Press ctrl + d :
chmod a+x myscript.sh
sudo myscript.sh
Hope it help.
add a comment |
sudo at now
at> echo test > /tmp/test.out
at> <EOT>
job 1 at Thu Sep 21 10:49:00 2017
1
If you havesudo
anyway,at
isn't useful or necessary.sudo sh -c 'echo test >/tmp/test.out'
does the same much more efficiently and elegantly (but still suffers from the flaw that you are probably running things asroot
which don't need that privilege; you should generally avoid privileged commands when you can).
– tripleee
Jun 29 '18 at 6:11
add a comment |
protected by codeforester Aug 17 '18 at 17:11
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
15 Answers
15
active
oldest
votes
15 Answers
15
active
oldest
votes
active
oldest
votes
active
oldest
votes
Your command does not work because the redirection is performed by your shell which does not have the permission to write to /root/test.out
. The redirection of the output is not performed by sudo.
There are multiple solutions:
Run a shell with sudo and give the command to it by using the
-c
option:
sudo sh -c 'ls -hal /root/ > /root/test.out'
Create a script with your commands and run that script with sudo:
#!/bin/sh
ls -hal /root/ > /root/test.out
Run
sudo ls.sh
. See Steve Bennett's answer if you don't want to create a temporary file.
Launch a shell with
sudo -s
then run your commands:
[nobody@so]$ sudo -s
[root@so]# ls -hal /root/ > /root/test.out
[root@so]# ^D
[nobody@so]$
Use
sudo tee
(if you have to escape a lot when using the-c
option):
sudo ls -hal /root/ | sudo tee /root/test.out > /dev/null
The redirect to
/dev/null
is needed to stop tee from outputting to the screen. To append instead of overwriting the output file
(>>
), usetee -a
ortee --append
(the last one is specific to GNU coreutils).
Thanks go to Jd, Adam J. Forster and Johnathan for the second, third and fourth solutions.
1
There's a great answer that tells you how to redirect STDERR and STDOUT separately here: stackoverflow.com/questions/692000/… ... basicallyperl -e 'print "STDINn"; print STDERR "STDERRn"; ' > >( tee stdout.log ) 2> >( tee stderr.log >&2 )
– errant.info
Jun 13 '13 at 11:40
2
You'll want to do 'sudo -E ...' in order to use variables in the shelled out command (when using this in a script, for instance).
– Urhixidur
Feb 14 '14 at 21:28
1
Redirecting tee output to /dev/null is probably not necessary in a lot of cases where echoing the output to screen is harmless. For example, when dealing just with output of regular commands or contents of small text files.
– thomasrutter
Jul 7 '15 at 1:36
add a comment |
Your command does not work because the redirection is performed by your shell which does not have the permission to write to /root/test.out
. The redirection of the output is not performed by sudo.
There are multiple solutions:
Run a shell with sudo and give the command to it by using the
-c
option:
sudo sh -c 'ls -hal /root/ > /root/test.out'
Create a script with your commands and run that script with sudo:
#!/bin/sh
ls -hal /root/ > /root/test.out
Run
sudo ls.sh
. See Steve Bennett's answer if you don't want to create a temporary file.
Launch a shell with
sudo -s
then run your commands:
[nobody@so]$ sudo -s
[root@so]# ls -hal /root/ > /root/test.out
[root@so]# ^D
[nobody@so]$
Use
sudo tee
(if you have to escape a lot when using the-c
option):
sudo ls -hal /root/ | sudo tee /root/test.out > /dev/null
The redirect to
/dev/null
is needed to stop tee from outputting to the screen. To append instead of overwriting the output file
(>>
), usetee -a
ortee --append
(the last one is specific to GNU coreutils).
Thanks go to Jd, Adam J. Forster and Johnathan for the second, third and fourth solutions.
1
There's a great answer that tells you how to redirect STDERR and STDOUT separately here: stackoverflow.com/questions/692000/… ... basicallyperl -e 'print "STDINn"; print STDERR "STDERRn"; ' > >( tee stdout.log ) 2> >( tee stderr.log >&2 )
– errant.info
Jun 13 '13 at 11:40
2
You'll want to do 'sudo -E ...' in order to use variables in the shelled out command (when using this in a script, for instance).
– Urhixidur
Feb 14 '14 at 21:28
1
Redirecting tee output to /dev/null is probably not necessary in a lot of cases where echoing the output to screen is harmless. For example, when dealing just with output of regular commands or contents of small text files.
– thomasrutter
Jul 7 '15 at 1:36
add a comment |
Your command does not work because the redirection is performed by your shell which does not have the permission to write to /root/test.out
. The redirection of the output is not performed by sudo.
There are multiple solutions:
Run a shell with sudo and give the command to it by using the
-c
option:
sudo sh -c 'ls -hal /root/ > /root/test.out'
Create a script with your commands and run that script with sudo:
#!/bin/sh
ls -hal /root/ > /root/test.out
Run
sudo ls.sh
. See Steve Bennett's answer if you don't want to create a temporary file.
Launch a shell with
sudo -s
then run your commands:
[nobody@so]$ sudo -s
[root@so]# ls -hal /root/ > /root/test.out
[root@so]# ^D
[nobody@so]$
Use
sudo tee
(if you have to escape a lot when using the-c
option):
sudo ls -hal /root/ | sudo tee /root/test.out > /dev/null
The redirect to
/dev/null
is needed to stop tee from outputting to the screen. To append instead of overwriting the output file
(>>
), usetee -a
ortee --append
(the last one is specific to GNU coreutils).
Thanks go to Jd, Adam J. Forster and Johnathan for the second, third and fourth solutions.
Your command does not work because the redirection is performed by your shell which does not have the permission to write to /root/test.out
. The redirection of the output is not performed by sudo.
There are multiple solutions:
Run a shell with sudo and give the command to it by using the
-c
option:
sudo sh -c 'ls -hal /root/ > /root/test.out'
Create a script with your commands and run that script with sudo:
#!/bin/sh
ls -hal /root/ > /root/test.out
Run
sudo ls.sh
. See Steve Bennett's answer if you don't want to create a temporary file.
Launch a shell with
sudo -s
then run your commands:
[nobody@so]$ sudo -s
[root@so]# ls -hal /root/ > /root/test.out
[root@so]# ^D
[nobody@so]$
Use
sudo tee
(if you have to escape a lot when using the-c
option):
sudo ls -hal /root/ | sudo tee /root/test.out > /dev/null
The redirect to
/dev/null
is needed to stop tee from outputting to the screen. To append instead of overwriting the output file
(>>
), usetee -a
ortee --append
(the last one is specific to GNU coreutils).
Thanks go to Jd, Adam J. Forster and Johnathan for the second, third and fourth solutions.
edited May 23 '17 at 10:31
Community♦
11
11
answered Sep 17 '08 at 11:48
Cristian CiupituCristian Ciupitu
14.5k54263
14.5k54263
1
There's a great answer that tells you how to redirect STDERR and STDOUT separately here: stackoverflow.com/questions/692000/… ... basicallyperl -e 'print "STDINn"; print STDERR "STDERRn"; ' > >( tee stdout.log ) 2> >( tee stderr.log >&2 )
– errant.info
Jun 13 '13 at 11:40
2
You'll want to do 'sudo -E ...' in order to use variables in the shelled out command (when using this in a script, for instance).
– Urhixidur
Feb 14 '14 at 21:28
1
Redirecting tee output to /dev/null is probably not necessary in a lot of cases where echoing the output to screen is harmless. For example, when dealing just with output of regular commands or contents of small text files.
– thomasrutter
Jul 7 '15 at 1:36
add a comment |
1
There's a great answer that tells you how to redirect STDERR and STDOUT separately here: stackoverflow.com/questions/692000/… ... basicallyperl -e 'print "STDINn"; print STDERR "STDERRn"; ' > >( tee stdout.log ) 2> >( tee stderr.log >&2 )
– errant.info
Jun 13 '13 at 11:40
2
You'll want to do 'sudo -E ...' in order to use variables in the shelled out command (when using this in a script, for instance).
– Urhixidur
Feb 14 '14 at 21:28
1
Redirecting tee output to /dev/null is probably not necessary in a lot of cases where echoing the output to screen is harmless. For example, when dealing just with output of regular commands or contents of small text files.
– thomasrutter
Jul 7 '15 at 1:36
1
1
There's a great answer that tells you how to redirect STDERR and STDOUT separately here: stackoverflow.com/questions/692000/… ... basically
perl -e 'print "STDINn"; print STDERR "STDERRn"; ' > >( tee stdout.log ) 2> >( tee stderr.log >&2 )
– errant.info
Jun 13 '13 at 11:40
There's a great answer that tells you how to redirect STDERR and STDOUT separately here: stackoverflow.com/questions/692000/… ... basically
perl -e 'print "STDINn"; print STDERR "STDERRn"; ' > >( tee stdout.log ) 2> >( tee stderr.log >&2 )
– errant.info
Jun 13 '13 at 11:40
2
2
You'll want to do 'sudo -E ...' in order to use variables in the shelled out command (when using this in a script, for instance).
– Urhixidur
Feb 14 '14 at 21:28
You'll want to do 'sudo -E ...' in order to use variables in the shelled out command (when using this in a script, for instance).
– Urhixidur
Feb 14 '14 at 21:28
1
1
Redirecting tee output to /dev/null is probably not necessary in a lot of cases where echoing the output to screen is harmless. For example, when dealing just with output of regular commands or contents of small text files.
– thomasrutter
Jul 7 '15 at 1:36
Redirecting tee output to /dev/null is probably not necessary in a lot of cases where echoing the output to screen is harmless. For example, when dealing just with output of regular commands or contents of small text files.
– thomasrutter
Jul 7 '15 at 1:36
add a comment |
Someone here has just suggested sudoing tee:
sudo ls -hal /root/ | sudo tee /root/test.out > /dev/null
This could also be used to redirect any command, to a directory that you do not have access to. It works because the tee program is effectively an "echo to a file" program, and the redirect to /dev/null is to stop it also outputting to the screen to keep it the same as the original contrived example above.
3
In many cases, namely if the normal user has prmissions to perform the command and "only" cannot write to the desired output file, the firstsudo
(i.e., for the command itself) might be omitted
– Hagen von Eitzen
Aug 26 '16 at 8:38
add a comment |
Someone here has just suggested sudoing tee:
sudo ls -hal /root/ | sudo tee /root/test.out > /dev/null
This could also be used to redirect any command, to a directory that you do not have access to. It works because the tee program is effectively an "echo to a file" program, and the redirect to /dev/null is to stop it also outputting to the screen to keep it the same as the original contrived example above.
3
In many cases, namely if the normal user has prmissions to perform the command and "only" cannot write to the desired output file, the firstsudo
(i.e., for the command itself) might be omitted
– Hagen von Eitzen
Aug 26 '16 at 8:38
add a comment |
Someone here has just suggested sudoing tee:
sudo ls -hal /root/ | sudo tee /root/test.out > /dev/null
This could also be used to redirect any command, to a directory that you do not have access to. It works because the tee program is effectively an "echo to a file" program, and the redirect to /dev/null is to stop it also outputting to the screen to keep it the same as the original contrived example above.
Someone here has just suggested sudoing tee:
sudo ls -hal /root/ | sudo tee /root/test.out > /dev/null
This could also be used to redirect any command, to a directory that you do not have access to. It works because the tee program is effectively an "echo to a file" program, and the redirect to /dev/null is to stop it also outputting to the screen to keep it the same as the original contrived example above.
edited Nov 21 '17 at 14:23
answered Sep 17 '08 at 12:26
JonathanJonathan
15.1k105677
15.1k105677
3
In many cases, namely if the normal user has prmissions to perform the command and "only" cannot write to the desired output file, the firstsudo
(i.e., for the command itself) might be omitted
– Hagen von Eitzen
Aug 26 '16 at 8:38
add a comment |
3
In many cases, namely if the normal user has prmissions to perform the command and "only" cannot write to the desired output file, the firstsudo
(i.e., for the command itself) might be omitted
– Hagen von Eitzen
Aug 26 '16 at 8:38
3
3
In many cases, namely if the normal user has prmissions to perform the command and "only" cannot write to the desired output file, the first
sudo
(i.e., for the command itself) might be omitted– Hagen von Eitzen
Aug 26 '16 at 8:38
In many cases, namely if the normal user has prmissions to perform the command and "only" cannot write to the desired output file, the first
sudo
(i.e., for the command itself) might be omitted– Hagen von Eitzen
Aug 26 '16 at 8:38
add a comment |
A trick I figured out myself was
sudo ls -hal /root/ | sudo dd of=/root/test.out
14
sudo dd
is better than thesudo tee /root/file > /dev/null
examples above!
– kristianlm
Mar 6 '13 at 12:45
10
dd is not a weird obscure command. It is used whenever you need to copy large amounts of data with buffering between two block devices. The syntax is actually pretty simple,dd
is the command name,of=/root/test.out
is the argument which tellsdd
what the Output Files is.
– rhlee
Jul 24 '13 at 18:48
11
@steve Everything is 'obscure' until you learn what it is.of
means output file anddd
is a very popular tool used in both Linux and OSX (mostly for writing images to disks). This is a neat trick for sure.
– blockloop
Apr 14 '14 at 19:24
10
dd
is probably equally useful astee
here. In both cases you're using a common, well-known command for a purpose that, while slightly different to its original intended purpose, is still well-known and well-documented. Whiledd
is good at copying huge amounts of data, it doesn't suck with small amounts. It has the benefit here of not echoing the output to standard output as well.
– thomasrutter
Jul 7 '15 at 1:39
19
Whenever you type wordssudo dd
next to one another, you want to make very, very sure that the arguments that follow are correct (especially considering its non-standard syntax). They don't call it "disk destroyer" for nothing...
– ali_m
Jan 5 '16 at 21:44
|
show 5 more comments
A trick I figured out myself was
sudo ls -hal /root/ | sudo dd of=/root/test.out
14
sudo dd
is better than thesudo tee /root/file > /dev/null
examples above!
– kristianlm
Mar 6 '13 at 12:45
10
dd is not a weird obscure command. It is used whenever you need to copy large amounts of data with buffering between two block devices. The syntax is actually pretty simple,dd
is the command name,of=/root/test.out
is the argument which tellsdd
what the Output Files is.
– rhlee
Jul 24 '13 at 18:48
11
@steve Everything is 'obscure' until you learn what it is.of
means output file anddd
is a very popular tool used in both Linux and OSX (mostly for writing images to disks). This is a neat trick for sure.
– blockloop
Apr 14 '14 at 19:24
10
dd
is probably equally useful astee
here. In both cases you're using a common, well-known command for a purpose that, while slightly different to its original intended purpose, is still well-known and well-documented. Whiledd
is good at copying huge amounts of data, it doesn't suck with small amounts. It has the benefit here of not echoing the output to standard output as well.
– thomasrutter
Jul 7 '15 at 1:39
19
Whenever you type wordssudo dd
next to one another, you want to make very, very sure that the arguments that follow are correct (especially considering its non-standard syntax). They don't call it "disk destroyer" for nothing...
– ali_m
Jan 5 '16 at 21:44
|
show 5 more comments
A trick I figured out myself was
sudo ls -hal /root/ | sudo dd of=/root/test.out
A trick I figured out myself was
sudo ls -hal /root/ | sudo dd of=/root/test.out
answered Nov 21 '11 at 14:24
rhleerhlee
2,30122433
2,30122433
14
sudo dd
is better than thesudo tee /root/file > /dev/null
examples above!
– kristianlm
Mar 6 '13 at 12:45
10
dd is not a weird obscure command. It is used whenever you need to copy large amounts of data with buffering between two block devices. The syntax is actually pretty simple,dd
is the command name,of=/root/test.out
is the argument which tellsdd
what the Output Files is.
– rhlee
Jul 24 '13 at 18:48
11
@steve Everything is 'obscure' until you learn what it is.of
means output file anddd
is a very popular tool used in both Linux and OSX (mostly for writing images to disks). This is a neat trick for sure.
– blockloop
Apr 14 '14 at 19:24
10
dd
is probably equally useful astee
here. In both cases you're using a common, well-known command for a purpose that, while slightly different to its original intended purpose, is still well-known and well-documented. Whiledd
is good at copying huge amounts of data, it doesn't suck with small amounts. It has the benefit here of not echoing the output to standard output as well.
– thomasrutter
Jul 7 '15 at 1:39
19
Whenever you type wordssudo dd
next to one another, you want to make very, very sure that the arguments that follow are correct (especially considering its non-standard syntax). They don't call it "disk destroyer" for nothing...
– ali_m
Jan 5 '16 at 21:44
|
show 5 more comments
14
sudo dd
is better than thesudo tee /root/file > /dev/null
examples above!
– kristianlm
Mar 6 '13 at 12:45
10
dd is not a weird obscure command. It is used whenever you need to copy large amounts of data with buffering between two block devices. The syntax is actually pretty simple,dd
is the command name,of=/root/test.out
is the argument which tellsdd
what the Output Files is.
– rhlee
Jul 24 '13 at 18:48
11
@steve Everything is 'obscure' until you learn what it is.of
means output file anddd
is a very popular tool used in both Linux and OSX (mostly for writing images to disks). This is a neat trick for sure.
– blockloop
Apr 14 '14 at 19:24
10
dd
is probably equally useful astee
here. In both cases you're using a common, well-known command for a purpose that, while slightly different to its original intended purpose, is still well-known and well-documented. Whiledd
is good at copying huge amounts of data, it doesn't suck with small amounts. It has the benefit here of not echoing the output to standard output as well.
– thomasrutter
Jul 7 '15 at 1:39
19
Whenever you type wordssudo dd
next to one another, you want to make very, very sure that the arguments that follow are correct (especially considering its non-standard syntax). They don't call it "disk destroyer" for nothing...
– ali_m
Jan 5 '16 at 21:44
14
14
sudo dd
is better than the sudo tee /root/file > /dev/null
examples above!– kristianlm
Mar 6 '13 at 12:45
sudo dd
is better than the sudo tee /root/file > /dev/null
examples above!– kristianlm
Mar 6 '13 at 12:45
10
10
dd is not a weird obscure command. It is used whenever you need to copy large amounts of data with buffering between two block devices. The syntax is actually pretty simple,
dd
is the command name, of=/root/test.out
is the argument which tells dd
what the Output Files is.– rhlee
Jul 24 '13 at 18:48
dd is not a weird obscure command. It is used whenever you need to copy large amounts of data with buffering between two block devices. The syntax is actually pretty simple,
dd
is the command name, of=/root/test.out
is the argument which tells dd
what the Output Files is.– rhlee
Jul 24 '13 at 18:48
11
11
@steve Everything is 'obscure' until you learn what it is.
of
means output file and dd
is a very popular tool used in both Linux and OSX (mostly for writing images to disks). This is a neat trick for sure.– blockloop
Apr 14 '14 at 19:24
@steve Everything is 'obscure' until you learn what it is.
of
means output file and dd
is a very popular tool used in both Linux and OSX (mostly for writing images to disks). This is a neat trick for sure.– blockloop
Apr 14 '14 at 19:24
10
10
dd
is probably equally useful as tee
here. In both cases you're using a common, well-known command for a purpose that, while slightly different to its original intended purpose, is still well-known and well-documented. While dd
is good at copying huge amounts of data, it doesn't suck with small amounts. It has the benefit here of not echoing the output to standard output as well.– thomasrutter
Jul 7 '15 at 1:39
dd
is probably equally useful as tee
here. In both cases you're using a common, well-known command for a purpose that, while slightly different to its original intended purpose, is still well-known and well-documented. While dd
is good at copying huge amounts of data, it doesn't suck with small amounts. It has the benefit here of not echoing the output to standard output as well.– thomasrutter
Jul 7 '15 at 1:39
19
19
Whenever you type words
sudo dd
next to one another, you want to make very, very sure that the arguments that follow are correct (especially considering its non-standard syntax). They don't call it "disk destroyer" for nothing...– ali_m
Jan 5 '16 at 21:44
Whenever you type words
sudo dd
next to one another, you want to make very, very sure that the arguments that follow are correct (especially considering its non-standard syntax). They don't call it "disk destroyer" for nothing...– ali_m
Jan 5 '16 at 21:44
|
show 5 more comments
The problem is that the command gets run under sudo
, but the redirection gets run under your user. This is done by the shell and there is very little you can do about it.
sudo command > /some/file.log
`-----v-----'`-------v-------'
command redirection
The usual ways of bypassing this are:
Wrap the commands in a script which you call under sudo.
If the commands and/or log file changes, you can make the
script take these as arguments. For example:
sudo log_script command /log/file.txt
Call a shell and pass the command line as a parameter with
-c
This is especially useful for one off compound commands.
For example:
sudo bash -c "{ command1 arg; command2 arg; } > /log/file.txt"
add a comment |
The problem is that the command gets run under sudo
, but the redirection gets run under your user. This is done by the shell and there is very little you can do about it.
sudo command > /some/file.log
`-----v-----'`-------v-------'
command redirection
The usual ways of bypassing this are:
Wrap the commands in a script which you call under sudo.
If the commands and/or log file changes, you can make the
script take these as arguments. For example:
sudo log_script command /log/file.txt
Call a shell and pass the command line as a parameter with
-c
This is especially useful for one off compound commands.
For example:
sudo bash -c "{ command1 arg; command2 arg; } > /log/file.txt"
add a comment |
The problem is that the command gets run under sudo
, but the redirection gets run under your user. This is done by the shell and there is very little you can do about it.
sudo command > /some/file.log
`-----v-----'`-------v-------'
command redirection
The usual ways of bypassing this are:
Wrap the commands in a script which you call under sudo.
If the commands and/or log file changes, you can make the
script take these as arguments. For example:
sudo log_script command /log/file.txt
Call a shell and pass the command line as a parameter with
-c
This is especially useful for one off compound commands.
For example:
sudo bash -c "{ command1 arg; command2 arg; } > /log/file.txt"
The problem is that the command gets run under sudo
, but the redirection gets run under your user. This is done by the shell and there is very little you can do about it.
sudo command > /some/file.log
`-----v-----'`-------v-------'
command redirection
The usual ways of bypassing this are:
Wrap the commands in a script which you call under sudo.
If the commands and/or log file changes, you can make the
script take these as arguments. For example:
sudo log_script command /log/file.txt
Call a shell and pass the command line as a parameter with
-c
This is especially useful for one off compound commands.
For example:
sudo bash -c "{ command1 arg; command2 arg; } > /log/file.txt"
edited Mar 19 '18 at 20:05
wisbucky
10.7k36054
10.7k36054
answered Sep 23 '08 at 10:10
dsmdsm
8,9343369
8,9343369
add a comment |
add a comment |
Yet another variation on the theme:
sudo bash <<EOF
ls -hal /root/ > /root/test.out
EOF
Or of course:
echo 'ls -hal /root/ > /root/test.out' | sudo bash
They have the (tiny) advantage that you don't need to remember any arguments to sudo
or sh
/bash
add a comment |
Yet another variation on the theme:
sudo bash <<EOF
ls -hal /root/ > /root/test.out
EOF
Or of course:
echo 'ls -hal /root/ > /root/test.out' | sudo bash
They have the (tiny) advantage that you don't need to remember any arguments to sudo
or sh
/bash
add a comment |
Yet another variation on the theme:
sudo bash <<EOF
ls -hal /root/ > /root/test.out
EOF
Or of course:
echo 'ls -hal /root/ > /root/test.out' | sudo bash
They have the (tiny) advantage that you don't need to remember any arguments to sudo
or sh
/bash
Yet another variation on the theme:
sudo bash <<EOF
ls -hal /root/ > /root/test.out
EOF
Or of course:
echo 'ls -hal /root/ > /root/test.out' | sudo bash
They have the (tiny) advantage that you don't need to remember any arguments to sudo
or sh
/bash
edited May 13 '13 at 7:56
answered May 13 '13 at 3:53


Steve BennettSteve Bennett
50.4k21102135
50.4k21102135
add a comment |
add a comment |
Clarifying a bit on why the tee option is preferable
Assuming you have appropriate permission to execute the command that creates the output, if you pipe the output of your command to tee, you only need to elevate tee's privledges with sudo and direct tee to write (or append) to the file in question.
in the example given in the question that would mean:
ls -hal /root/ | sudo tee /root/test.out
for a couple more practical examples:
# kill off one source of annoying advertisements
echo 127.0.0.1 ad.doubleclick.net | sudo tee -a /etc/hosts
# configure eth4 to come up on boot, set IP and netmask (centos 6.4)
echo -e "ONBOOT="YES"nIPADDR=10.42.84.168nPREFIX=24" | sudo tee -a /etc/sysconfig/network-scripts/ifcfg-eth4
In each of these examples you are taking the output of a non-privileged command and writing to a file that is usually only writable by root, which is the origin of your question.
It is a good idea to do it this way because the command that generates the output is not executed with elevated privileges. It doesn't seem to matter here with echo
but when the source command is a script that you don't completely trust, it is crucial.
Note you can use the -a option to tee to append append (like >>
) to the target file rather than overwrite it (like >
).
Sorry js3, but this has already been suggested (back in 2008) and is sitting at the second highest answer: stackoverflow.com/a/82553/6910
– Jonathan
Nov 6 '13 at 10:24
2
You're right, Jonathan, I'll update my answer to expand on the reasons why this is a preferable option. Thanks for the helpful feedback.
– jg3
Nov 7 '13 at 18:23
add a comment |
Clarifying a bit on why the tee option is preferable
Assuming you have appropriate permission to execute the command that creates the output, if you pipe the output of your command to tee, you only need to elevate tee's privledges with sudo and direct tee to write (or append) to the file in question.
in the example given in the question that would mean:
ls -hal /root/ | sudo tee /root/test.out
for a couple more practical examples:
# kill off one source of annoying advertisements
echo 127.0.0.1 ad.doubleclick.net | sudo tee -a /etc/hosts
# configure eth4 to come up on boot, set IP and netmask (centos 6.4)
echo -e "ONBOOT="YES"nIPADDR=10.42.84.168nPREFIX=24" | sudo tee -a /etc/sysconfig/network-scripts/ifcfg-eth4
In each of these examples you are taking the output of a non-privileged command and writing to a file that is usually only writable by root, which is the origin of your question.
It is a good idea to do it this way because the command that generates the output is not executed with elevated privileges. It doesn't seem to matter here with echo
but when the source command is a script that you don't completely trust, it is crucial.
Note you can use the -a option to tee to append append (like >>
) to the target file rather than overwrite it (like >
).
Sorry js3, but this has already been suggested (back in 2008) and is sitting at the second highest answer: stackoverflow.com/a/82553/6910
– Jonathan
Nov 6 '13 at 10:24
2
You're right, Jonathan, I'll update my answer to expand on the reasons why this is a preferable option. Thanks for the helpful feedback.
– jg3
Nov 7 '13 at 18:23
add a comment |
Clarifying a bit on why the tee option is preferable
Assuming you have appropriate permission to execute the command that creates the output, if you pipe the output of your command to tee, you only need to elevate tee's privledges with sudo and direct tee to write (or append) to the file in question.
in the example given in the question that would mean:
ls -hal /root/ | sudo tee /root/test.out
for a couple more practical examples:
# kill off one source of annoying advertisements
echo 127.0.0.1 ad.doubleclick.net | sudo tee -a /etc/hosts
# configure eth4 to come up on boot, set IP and netmask (centos 6.4)
echo -e "ONBOOT="YES"nIPADDR=10.42.84.168nPREFIX=24" | sudo tee -a /etc/sysconfig/network-scripts/ifcfg-eth4
In each of these examples you are taking the output of a non-privileged command and writing to a file that is usually only writable by root, which is the origin of your question.
It is a good idea to do it this way because the command that generates the output is not executed with elevated privileges. It doesn't seem to matter here with echo
but when the source command is a script that you don't completely trust, it is crucial.
Note you can use the -a option to tee to append append (like >>
) to the target file rather than overwrite it (like >
).
Clarifying a bit on why the tee option is preferable
Assuming you have appropriate permission to execute the command that creates the output, if you pipe the output of your command to tee, you only need to elevate tee's privledges with sudo and direct tee to write (or append) to the file in question.
in the example given in the question that would mean:
ls -hal /root/ | sudo tee /root/test.out
for a couple more practical examples:
# kill off one source of annoying advertisements
echo 127.0.0.1 ad.doubleclick.net | sudo tee -a /etc/hosts
# configure eth4 to come up on boot, set IP and netmask (centos 6.4)
echo -e "ONBOOT="YES"nIPADDR=10.42.84.168nPREFIX=24" | sudo tee -a /etc/sysconfig/network-scripts/ifcfg-eth4
In each of these examples you are taking the output of a non-privileged command and writing to a file that is usually only writable by root, which is the origin of your question.
It is a good idea to do it this way because the command that generates the output is not executed with elevated privileges. It doesn't seem to matter here with echo
but when the source command is a script that you don't completely trust, it is crucial.
Note you can use the -a option to tee to append append (like >>
) to the target file rather than overwrite it (like >
).
edited Nov 7 '13 at 19:16
answered Nov 2 '13 at 1:51
jg3jg3
30826
30826
Sorry js3, but this has already been suggested (back in 2008) and is sitting at the second highest answer: stackoverflow.com/a/82553/6910
– Jonathan
Nov 6 '13 at 10:24
2
You're right, Jonathan, I'll update my answer to expand on the reasons why this is a preferable option. Thanks for the helpful feedback.
– jg3
Nov 7 '13 at 18:23
add a comment |
Sorry js3, but this has already been suggested (back in 2008) and is sitting at the second highest answer: stackoverflow.com/a/82553/6910
– Jonathan
Nov 6 '13 at 10:24
2
You're right, Jonathan, I'll update my answer to expand on the reasons why this is a preferable option. Thanks for the helpful feedback.
– jg3
Nov 7 '13 at 18:23
Sorry js3, but this has already been suggested (back in 2008) and is sitting at the second highest answer: stackoverflow.com/a/82553/6910
– Jonathan
Nov 6 '13 at 10:24
Sorry js3, but this has already been suggested (back in 2008) and is sitting at the second highest answer: stackoverflow.com/a/82553/6910
– Jonathan
Nov 6 '13 at 10:24
2
2
You're right, Jonathan, I'll update my answer to expand on the reasons why this is a preferable option. Thanks for the helpful feedback.
– jg3
Nov 7 '13 at 18:23
You're right, Jonathan, I'll update my answer to expand on the reasons why this is a preferable option. Thanks for the helpful feedback.
– jg3
Nov 7 '13 at 18:23
add a comment |
Make sudo run a shell, like this:
sudo sh -c "echo foo > ~root/out"
add a comment |
Make sudo run a shell, like this:
sudo sh -c "echo foo > ~root/out"
add a comment |
Make sudo run a shell, like this:
sudo sh -c "echo foo > ~root/out"
Make sudo run a shell, like this:
sudo sh -c "echo foo > ~root/out"
answered Sep 17 '08 at 11:48
PenfoldPenfold
2,2921216
2,2921216
add a comment |
add a comment |
The way I would go about this issue is:
If you need to write/replace the file:
echo "some text" | sudo tee /path/to/file
If you need to append to the file:
echo "some text" | sudo tee -a /path/to/file
1
How is this substantially different to answers above?
– Jonathan
Jun 24 '16 at 19:50
add a comment |
The way I would go about this issue is:
If you need to write/replace the file:
echo "some text" | sudo tee /path/to/file
If you need to append to the file:
echo "some text" | sudo tee -a /path/to/file
1
How is this substantially different to answers above?
– Jonathan
Jun 24 '16 at 19:50
add a comment |
The way I would go about this issue is:
If you need to write/replace the file:
echo "some text" | sudo tee /path/to/file
If you need to append to the file:
echo "some text" | sudo tee -a /path/to/file
The way I would go about this issue is:
If you need to write/replace the file:
echo "some text" | sudo tee /path/to/file
If you need to append to the file:
echo "some text" | sudo tee -a /path/to/file
answered Jun 24 '16 at 19:48
Nikola PetkanskiNikola Petkanski
3,7402737
3,7402737
1
How is this substantially different to answers above?
– Jonathan
Jun 24 '16 at 19:50
add a comment |
1
How is this substantially different to answers above?
– Jonathan
Jun 24 '16 at 19:50
1
1
How is this substantially different to answers above?
– Jonathan
Jun 24 '16 at 19:50
How is this substantially different to answers above?
– Jonathan
Jun 24 '16 at 19:50
add a comment |
How about writing a script?
Filename: myscript
#!/bin/sh
/bin/ls -lah /root > /root/test.out
# end script
Then use sudo to run the script:
sudo ./myscript
add a comment |
How about writing a script?
Filename: myscript
#!/bin/sh
/bin/ls -lah /root > /root/test.out
# end script
Then use sudo to run the script:
sudo ./myscript
add a comment |
How about writing a script?
Filename: myscript
#!/bin/sh
/bin/ls -lah /root > /root/test.out
# end script
Then use sudo to run the script:
sudo ./myscript
How about writing a script?
Filename: myscript
#!/bin/sh
/bin/ls -lah /root > /root/test.out
# end script
Then use sudo to run the script:
sudo ./myscript
edited Sep 17 '08 at 12:25
answered Sep 17 '08 at 11:48
Jd
add a comment |
add a comment |
I would do it this way:
sudo su -c 'ls -hal /root/ > /root/test.out'
2
That actually seems a bit cleaner, as you don't need to explicitly specify the shell.
– Steve Bennett
May 13 '13 at 2:13
1
One small drawback is that it runs one additional process (su
):$ sudo su -c 'pstree -sp $$ >/dev/fd/1'
init(1)───gnome-terminal(6880)───bash(6945)───sudo(401)───su(402)───bash(410)───pstree(411)
– pabouk
Jul 28 '13 at 11:34
add a comment |
I would do it this way:
sudo su -c 'ls -hal /root/ > /root/test.out'
2
That actually seems a bit cleaner, as you don't need to explicitly specify the shell.
– Steve Bennett
May 13 '13 at 2:13
1
One small drawback is that it runs one additional process (su
):$ sudo su -c 'pstree -sp $$ >/dev/fd/1'
init(1)───gnome-terminal(6880)───bash(6945)───sudo(401)───su(402)───bash(410)───pstree(411)
– pabouk
Jul 28 '13 at 11:34
add a comment |
I would do it this way:
sudo su -c 'ls -hal /root/ > /root/test.out'
I would do it this way:
sudo su -c 'ls -hal /root/ > /root/test.out'
answered Apr 21 '13 at 12:33
fardjadfardjad
14.3k53862
14.3k53862
2
That actually seems a bit cleaner, as you don't need to explicitly specify the shell.
– Steve Bennett
May 13 '13 at 2:13
1
One small drawback is that it runs one additional process (su
):$ sudo su -c 'pstree -sp $$ >/dev/fd/1'
init(1)───gnome-terminal(6880)───bash(6945)───sudo(401)───su(402)───bash(410)───pstree(411)
– pabouk
Jul 28 '13 at 11:34
add a comment |
2
That actually seems a bit cleaner, as you don't need to explicitly specify the shell.
– Steve Bennett
May 13 '13 at 2:13
1
One small drawback is that it runs one additional process (su
):$ sudo su -c 'pstree -sp $$ >/dev/fd/1'
init(1)───gnome-terminal(6880)───bash(6945)───sudo(401)───su(402)───bash(410)───pstree(411)
– pabouk
Jul 28 '13 at 11:34
2
2
That actually seems a bit cleaner, as you don't need to explicitly specify the shell.
– Steve Bennett
May 13 '13 at 2:13
That actually seems a bit cleaner, as you don't need to explicitly specify the shell.
– Steve Bennett
May 13 '13 at 2:13
1
1
One small drawback is that it runs one additional process (
su
): $ sudo su -c 'pstree -sp $$ >/dev/fd/1'
init(1)───gnome-terminal(6880)───bash(6945)───sudo(401)───su(402)───bash(410)───pstree(411)
– pabouk
Jul 28 '13 at 11:34
One small drawback is that it runs one additional process (
su
): $ sudo su -c 'pstree -sp $$ >/dev/fd/1'
init(1)───gnome-terminal(6880)───bash(6945)───sudo(401)───su(402)───bash(410)───pstree(411)
– pabouk
Jul 28 '13 at 11:34
add a comment |
Whenever I have to do something like this I just become root:
# sudo -s
# ls -hal /root/ > /root/test.out
# exit
It's probably not the best way, but it works.
add a comment |
Whenever I have to do something like this I just become root:
# sudo -s
# ls -hal /root/ > /root/test.out
# exit
It's probably not the best way, but it works.
add a comment |
Whenever I have to do something like this I just become root:
# sudo -s
# ls -hal /root/ > /root/test.out
# exit
It's probably not the best way, but it works.
Whenever I have to do something like this I just become root:
# sudo -s
# ls -hal /root/ > /root/test.out
# exit
It's probably not the best way, but it works.
answered Sep 17 '08 at 11:49
Adam J. ForsterAdam J. Forster
5,53682120
5,53682120
add a comment |
add a comment |
Don't mean to beat a dead horse, but there are too many answers here that use tee
, which means you have to redirect stdout
to /dev/null
unless you want to see a copy on the screen. A simpler solution is to just use cat
like this:
sudo ls -hal /root/ | sudo bash -c "cat > /root/test.out"
Notice how the redirection is put inside quotes so that it is evaluated by a shell started by sudo
instead of the one running it.
This works just fine. I don't understand why it had one negative vote. Upvoted.
– Teemu Leisti
Nov 24 '16 at 8:28
3
I think it doesn't get much love because it's not much better thansudo bash -c "ls -hal /root > /root/test.out"
. Using tee avoids needing a shell, while cat does not.
– Nick Russo
Dec 9 '16 at 4:49
add a comment |
Don't mean to beat a dead horse, but there are too many answers here that use tee
, which means you have to redirect stdout
to /dev/null
unless you want to see a copy on the screen. A simpler solution is to just use cat
like this:
sudo ls -hal /root/ | sudo bash -c "cat > /root/test.out"
Notice how the redirection is put inside quotes so that it is evaluated by a shell started by sudo
instead of the one running it.
This works just fine. I don't understand why it had one negative vote. Upvoted.
– Teemu Leisti
Nov 24 '16 at 8:28
3
I think it doesn't get much love because it's not much better thansudo bash -c "ls -hal /root > /root/test.out"
. Using tee avoids needing a shell, while cat does not.
– Nick Russo
Dec 9 '16 at 4:49
add a comment |
Don't mean to beat a dead horse, but there are too many answers here that use tee
, which means you have to redirect stdout
to /dev/null
unless you want to see a copy on the screen. A simpler solution is to just use cat
like this:
sudo ls -hal /root/ | sudo bash -c "cat > /root/test.out"
Notice how the redirection is put inside quotes so that it is evaluated by a shell started by sudo
instead of the one running it.
Don't mean to beat a dead horse, but there are too many answers here that use tee
, which means you have to redirect stdout
to /dev/null
unless you want to see a copy on the screen. A simpler solution is to just use cat
like this:
sudo ls -hal /root/ | sudo bash -c "cat > /root/test.out"
Notice how the redirection is put inside quotes so that it is evaluated by a shell started by sudo
instead of the one running it.
answered Jul 28 '16 at 9:27
haridsvharidsv
3,99834141
3,99834141
This works just fine. I don't understand why it had one negative vote. Upvoted.
– Teemu Leisti
Nov 24 '16 at 8:28
3
I think it doesn't get much love because it's not much better thansudo bash -c "ls -hal /root > /root/test.out"
. Using tee avoids needing a shell, while cat does not.
– Nick Russo
Dec 9 '16 at 4:49
add a comment |
This works just fine. I don't understand why it had one negative vote. Upvoted.
– Teemu Leisti
Nov 24 '16 at 8:28
3
I think it doesn't get much love because it's not much better thansudo bash -c "ls -hal /root > /root/test.out"
. Using tee avoids needing a shell, while cat does not.
– Nick Russo
Dec 9 '16 at 4:49
This works just fine. I don't understand why it had one negative vote. Upvoted.
– Teemu Leisti
Nov 24 '16 at 8:28
This works just fine. I don't understand why it had one negative vote. Upvoted.
– Teemu Leisti
Nov 24 '16 at 8:28
3
3
I think it doesn't get much love because it's not much better than
sudo bash -c "ls -hal /root > /root/test.out"
. Using tee avoids needing a shell, while cat does not.– Nick Russo
Dec 9 '16 at 4:49
I think it doesn't get much love because it's not much better than
sudo bash -c "ls -hal /root > /root/test.out"
. Using tee avoids needing a shell, while cat does not.– Nick Russo
Dec 9 '16 at 4:49
add a comment |
Here's an extension of the answer involving tee. To make things easier you might like to make a small script (I call it suwrite or you may call it sutee) and put it in /usr/local/bin/ with +x permission:
#! /bin/sh
sudo tee $@ > /dev/null
Now all you have to do is to pipe the output to this script followed by the desired superuser-accessible filename and it will automatically prompt you for your password if needed (since it includes sudo).
echo test | suwrite /root/test.txt
Note that since this is a simple wrapper for tee, it will also accept tee's -a (or any other) option so to append to the desired file you just pass -a:
echo test | suwrite -a /root/test.txt
add a comment |
Here's an extension of the answer involving tee. To make things easier you might like to make a small script (I call it suwrite or you may call it sutee) and put it in /usr/local/bin/ with +x permission:
#! /bin/sh
sudo tee $@ > /dev/null
Now all you have to do is to pipe the output to this script followed by the desired superuser-accessible filename and it will automatically prompt you for your password if needed (since it includes sudo).
echo test | suwrite /root/test.txt
Note that since this is a simple wrapper for tee, it will also accept tee's -a (or any other) option so to append to the desired file you just pass -a:
echo test | suwrite -a /root/test.txt
add a comment |
Here's an extension of the answer involving tee. To make things easier you might like to make a small script (I call it suwrite or you may call it sutee) and put it in /usr/local/bin/ with +x permission:
#! /bin/sh
sudo tee $@ > /dev/null
Now all you have to do is to pipe the output to this script followed by the desired superuser-accessible filename and it will automatically prompt you for your password if needed (since it includes sudo).
echo test | suwrite /root/test.txt
Note that since this is a simple wrapper for tee, it will also accept tee's -a (or any other) option so to append to the desired file you just pass -a:
echo test | suwrite -a /root/test.txt
Here's an extension of the answer involving tee. To make things easier you might like to make a small script (I call it suwrite or you may call it sutee) and put it in /usr/local/bin/ with +x permission:
#! /bin/sh
sudo tee $@ > /dev/null
Now all you have to do is to pipe the output to this script followed by the desired superuser-accessible filename and it will automatically prompt you for your password if needed (since it includes sudo).
echo test | suwrite /root/test.txt
Note that since this is a simple wrapper for tee, it will also accept tee's -a (or any other) option so to append to the desired file you just pass -a:
echo test | suwrite -a /root/test.txt
answered Nov 27 '13 at 4:55
jamadagnijamadagni
410314
410314
add a comment |
add a comment |
Maybe you been given sudo access to only some programs/paths? Then there is no way to do what you want. (unless you will hack it somehow)
If it is not the case then maybe you can write bash script:
cat > myscript.sh
#!/bin/sh
ls -hal /root/ > /root/test.out
Press ctrl + d :
chmod a+x myscript.sh
sudo myscript.sh
Hope it help.
add a comment |
Maybe you been given sudo access to only some programs/paths? Then there is no way to do what you want. (unless you will hack it somehow)
If it is not the case then maybe you can write bash script:
cat > myscript.sh
#!/bin/sh
ls -hal /root/ > /root/test.out
Press ctrl + d :
chmod a+x myscript.sh
sudo myscript.sh
Hope it help.
add a comment |
Maybe you been given sudo access to only some programs/paths? Then there is no way to do what you want. (unless you will hack it somehow)
If it is not the case then maybe you can write bash script:
cat > myscript.sh
#!/bin/sh
ls -hal /root/ > /root/test.out
Press ctrl + d :
chmod a+x myscript.sh
sudo myscript.sh
Hope it help.
Maybe you been given sudo access to only some programs/paths? Then there is no way to do what you want. (unless you will hack it somehow)
If it is not the case then maybe you can write bash script:
cat > myscript.sh
#!/bin/sh
ls -hal /root/ > /root/test.out
Press ctrl + d :
chmod a+x myscript.sh
sudo myscript.sh
Hope it help.
edited Mar 21 '13 at 11:39


franzlorenzon
3,95342752
3,95342752
answered Sep 17 '08 at 12:00
user15453user15453
3611414
3611414
add a comment |
add a comment |
sudo at now
at> echo test > /tmp/test.out
at> <EOT>
job 1 at Thu Sep 21 10:49:00 2017
1
If you havesudo
anyway,at
isn't useful or necessary.sudo sh -c 'echo test >/tmp/test.out'
does the same much more efficiently and elegantly (but still suffers from the flaw that you are probably running things asroot
which don't need that privilege; you should generally avoid privileged commands when you can).
– tripleee
Jun 29 '18 at 6:11
add a comment |
sudo at now
at> echo test > /tmp/test.out
at> <EOT>
job 1 at Thu Sep 21 10:49:00 2017
1
If you havesudo
anyway,at
isn't useful or necessary.sudo sh -c 'echo test >/tmp/test.out'
does the same much more efficiently and elegantly (but still suffers from the flaw that you are probably running things asroot
which don't need that privilege; you should generally avoid privileged commands when you can).
– tripleee
Jun 29 '18 at 6:11
add a comment |
sudo at now
at> echo test > /tmp/test.out
at> <EOT>
job 1 at Thu Sep 21 10:49:00 2017
sudo at now
at> echo test > /tmp/test.out
at> <EOT>
job 1 at Thu Sep 21 10:49:00 2017
edited Sep 21 '17 at 12:29
templatetypedef
263k69667893
263k69667893
answered Sep 21 '17 at 10:55
user8648126user8648126
91
91
1
If you havesudo
anyway,at
isn't useful or necessary.sudo sh -c 'echo test >/tmp/test.out'
does the same much more efficiently and elegantly (but still suffers from the flaw that you are probably running things asroot
which don't need that privilege; you should generally avoid privileged commands when you can).
– tripleee
Jun 29 '18 at 6:11
add a comment |
1
If you havesudo
anyway,at
isn't useful or necessary.sudo sh -c 'echo test >/tmp/test.out'
does the same much more efficiently and elegantly (but still suffers from the flaw that you are probably running things asroot
which don't need that privilege; you should generally avoid privileged commands when you can).
– tripleee
Jun 29 '18 at 6:11
1
1
If you have
sudo
anyway, at
isn't useful or necessary. sudo sh -c 'echo test >/tmp/test.out'
does the same much more efficiently and elegantly (but still suffers from the flaw that you are probably running things as root
which don't need that privilege; you should generally avoid privileged commands when you can).– tripleee
Jun 29 '18 at 6:11
If you have
sudo
anyway, at
isn't useful or necessary. sudo sh -c 'echo test >/tmp/test.out'
does the same much more efficiently and elegantly (but still suffers from the flaw that you are probably running things as root
which don't need that privilege; you should generally avoid privileged commands when you can).– tripleee
Jun 29 '18 at 6:11
add a comment |
protected by codeforester Aug 17 '18 at 17:11
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
8FYZqezyC,x4UotlRR
1
use chmod u+w filename
– Szabolcs Dombi
Jul 10 '16 at 15:33
@DombiSzabolcs You are suggesting that I create the file as sudo first, then give myself permission? Good idea.
– Jonathan
Jul 10 '16 at 15:36