Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

On busy days, I'd like to run

$ ./configure && make && sudo make install && halt

on the night and go to bed, hoping the application would automatically be installed. But what I see the next day is the screen where sudo asks me for the password. So how could I run sudo with password in one command line, or is there any other method to do this?

share|improve this question
You need halt to run as root. –  Keith Thompson Aug 8 '12 at 6:54
Doesn't sudo have a 15-minute timeout? Couldn't you run, say, sudo ls or something similar, enter your password, and then run the above command, having sudo privileges still active? (I can't test this at the moment, otherwise I'd post this as an answer.) –  Matt Aug 8 '12 at 8:28
The timeout on sudo is configurable. Security-conscious people (aka paranoid, like me) set it to zero... :-) –  dda Feb 13 '13 at 4:54

9 Answers 9

up vote 58 down vote accepted

Yes, use the -S switch which reads the password from STDIN:

$echo <password> | sudo -S <command>

So for your case it would look like this:

$./configure && make && echo <password> | sudo -S make install && halt

of course, replace <password> with your password.

share|improve this answer
Obviously, one would not want to run this if there is any danger of someone else seeing the password in the shell history. –  Brett Daniel Nov 9 '09 at 3:16
looking for quick ways to run privileged commands on a remote host and this works thanks. –  nelaar Sep 15 '11 at 11:08
If you decided to use the 'echo <password> | sudo -S' option, to avoid exposing the password on the command history, start the command with a SPACE character. Of course, the best option is to pipe the password from a secure file. –  user224306 May 14 '13 at 17:38

You could also configure sudo with visudo to allow you user to use make as sudo without password.

User_Alias USERS = your_user
Cmnd_Alias CMDS = /usr/bin/make
share|improve this answer

You could replace your command line with this:

$sudo su

$./configure && make && make install && halt

You will be prompted for your password immediately, then the rest of the commands will run as superuser.

share|improve this answer
an alternate (and probably preferred) version of this: sudo sh -c "./configure && make && make install && halt" –  quack quixote Nov 9 '09 at 3:51
But then wouldn't all the generated compile files have the superuser permissions? This would prevent you from running ./configure && make as a regular user later. –  user45909 Aug 4 '13 at 23:35
Yes, user45909, you're quite right. I have personally never rerun ./configure && make except after downloading an update of the main package anyway, but I'm probabably not typical. –  CarlF Aug 6 '13 at 19:48

Several of the other solutions have the disadvantage that they unnecessarily run ./configure and make as root.

This is a bit convoluted, but it should work:

sudo sh -c "su $USER -c ./configure && su $USER -c make && make install && halt"

Note the use of double quotes to allow $USER to be expanded by the (non-root) shell.

I might also add a sleep 60 before the halt command. I've sometimes done things like this, expecting the command to run for a long time, but something goes wrong and it terminates immediately; the sleep lets me kill the command before the system shuts down. Or you can use shutdown with a time argument.

share|improve this answer

Setting up sudo like that is dangerous if someone happened to see the fact that sudo requires no password on your account. Unless you know what you are doing, don't do that. I've had it happen at my local A+ Training program with my experimental computer one too many times... -_-

What John T. said sounds good though, except there still is the risk of finding the password in shell history. What CarlF said sounds better, but if one command fails, the computer will still be running with superuser privileges.

share|improve this answer

If you want to take more care, you could make a script, change the permissions of the file so only root can read and edit and then just run it.

1) Create a file:

gedit ~/.easy.install  

2) Paste this and save:

./configure && make && echo <password> | sudo -S make install && halt  

3) Make it executable:

sudo chmod +x ~/.easy.install  

4) Change the permissions of the file so only root can read and edit it:

sudo chmod 700 ~/.easy.install  

5) Run:


Enjoy ;-)

share|improve this answer

Set HISTIGNORE to "sudo -S"

$ export HISTIGNORE='*sudo -S*'

Then pass your password safely to sudo:

$ echo "your_password" | sudo -S -k <command>

"HISTIGNORE" means to not save this command into the history. That is the history in memory or "~/.bash_history" file.

For example, the below will safely pipe your password to the sudo command, without retaining a history of your password.

“-S”, means to use stdin for the password,

“-k” means to ignore cached credentials to force sudo to always ask. This is for consistent behavior.

$ export HISTIGNORE='*sudo -S*'
$ echo "<your_password>" | sudo -S -k whoami
$ echo "<your_password>" | sudo -S -k cat /etc/shadow
$ echo "<your_password>" | sudo -S -k bash /tmp/myscript.sh

The downside to the above method is that if you want to see the commands you ran in the history later on they won't be there. Another method is to update the sudo authentication credential cache (default is enabled with 5 minutes timeout), then run the sudo separately. But the downside of this is that you'll need to be aware of the 5 minute cache.

For example:

$ export HISTIGNORE='*sudo -S*'
$ echo "<your_password>" | sudo -S -v
$ sudo whoami
$ echo "<your_password>" | sudo -S -v
$ sudo cat /etc/shadow
$ echo "<your_password>" | sudo -S -v
$ sudo /tmp/myscript.sh

Note I ran a sudo before each command to ensure that the sudo cache is updated, as the default is 5 mintues. Yes, whoami shouldn't take 5 minutes, but I figure might as well have it run before each command for consistency. You could also put "export HISTIGNORE='sudo -S'" in your ~/.bashrc file, then load it with ". ~/.bashrc" or logoff then login. However, I'm thinking using this for scripting purposes, so I'll keep it at the top of all my scripts for best security practices. Setting "echo "" | sudo -S -v" to a variable instead might also be a good idea, then just run the variable before each command that needs root privileges, see Janar's comment. "John T"'s comment should also include the "-k" parameter, as if you run "sudo -S" without "-k" and sudo authentication cache already has your credentials (and is still valid, default sudo authentication cache is 5 minutes) then bash will run your password as a command instead, which is bad.

share|improve this answer

Personally I do quite the same as John T answered on Nov 9 '09 at 2:47, I've also improved mine according to guidance of his answer, thanks.

Difference is that I tend make use of variables, something like:

AutoSuDo=$" $echo pass | sudo -S";
# Change AutoSuDo to something else.
# Note that string starts with space,
# useful only if used as first command in line

In that way I can easily use mine variable instead of sudo,

$AutoSuDo apt-get update;

That comes quite handy with some longer scripts. I mainly make use of these for personal computers of others, that I have to maintain.

I also recommend to pay attention on:

  • desgua answer on Apr 19 '11 at 23:56
  • user224306 comment on May 14 '13 at 17:38 for John T answer on Nov 9 '09 at 2:47
share|improve this answer

Note, I've found that method doesn't work on an older version of sudo, specifically "Sudo version 1.6.7p5":

$ echo "<your_password>" | sudo -S -k whoami

Where as this method does work on older and new versions sudo:

$ echo "<your_password>" | sudo -S -v
$ sudo whoami
share|improve this answer
This is not an answer to the original question. To critique or request clarification from an author, leave a comment below their post - you can always comment on your own posts, and once you have sufficient reputation you will be able to comment on any post. –  DavidPostill Dec 8 at 15:25
@Darren DeHaven : Could you please explain how this become answer for the question asked here? –  Renju Chandran chingath Dec 8 at 15:50

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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