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?


12 Answers 12


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.

  • 60
    Obviously, one would not want to run this if there is any danger of someone else seeing the password in the shell history. Nov 9, 2009 at 3:16
  • 30
    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. May 14, 2013 at 17:38
  • 1
    You might want to use that if you have the password in a $VARIABLE (that you could have provision with sops for instance)
    – Natim
    Sep 6, 2017 at 9:25
  • 1
    Why I'm getting "Sorry, try again" then "sudo: no password was provided" whit the above method? My password contains $, but putting \ in front of the $ doesn't work.
    – NeilWang
    Mar 26, 2022 at 23:19
  • 1
    @NeilWang Try this: echo "password" | sudo -S bash -c "the-command-goes-over-here" May 5 at 18:57

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.

  • 2
    Just as a small note on making things not available in the history, run your command with a single space at the front of it. For some reason this causes history to ignore it. Aug 2, 2017 at 8:20
  • 2
    If you put your password into a command-line parameter, then it will be visible to all in the output of ps. Better to put it in a file and use indirection (sudo -S -v <FILE), or use here strings if bash is your shell (sudo -S -v <<<'<your_password>')
    – bobbogo
    Apr 14, 2020 at 17:42

You can do this too:

sudo -S <<< "password" command
  • 2
    only this one works for me in mac os.
    – Sabrina
    Sep 19, 2019 at 19:30
  • only this works in WinSCP shell. Thanks!
    – ASten
    Jun 18, 2021 at 14:10

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
  • 1
    I figured out no need to declare aliases. Add my_user ALL=(ALL) NOPASSWD: /usr/bin/your_command is OK. Remember to add it to the end to overwrite other configs.
    – Junle Li
    Jan 20, 2020 at 12:38

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.

  • 8
    an alternate (and probably preferred) version of this: sudo sh -c "./configure && make && make install && halt" Nov 9, 2009 at 3:51
  • 2
    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, 2013 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, 2013 at 19:48
  • Still great for all kinds of general use, such as copying mysql databases Feb 22 at 11:43

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.


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
  • 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, 2014 at 15:25
  • @Darren DeHaven : Could you please explain how this become answer for the question asked here? Dec 8, 2014 at 15:50

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 ;-)

  • 2
    echo <password> will still show up in the process list and if someone gets lucky with ps aux at the exact right moment, they can see the password in clear text. Better to save the password to a file and use < to redirect from the file into sudo.
    – bobpaul
    Apr 18, 2018 at 17:26

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.


In many situation you wouldn't want to pipe the password, but to keep sudo credentials refreshed:

refreshPermissions () {
    local pid="${1}"

    while kill -0 "${pid}" 2> /dev/null; do
        sudo -v
        sleep 10

refreshPermissions "$$" &

Then if a command needs root permissions within your program just do:

sudo [command]

And no password will be requested.


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

The problem is resolved. For example, to the user root:

echo -e 'password\npassword\n' | sudo passwd root
  • What does -e flag do, @jerson Martinez?
    – user674669
    Apr 25, 2019 at 18:00
  • 1
    The -e flag for echo allows it to interpret certain sequences as having special meanings. Apr 26, 2019 at 15:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .