What are the contents of /bin/bash, and what do I do if I accidentally overwrote them












25















I accidentally overwrote the /bin/bash file with a dumb script that I intented to put inside the /bin folder.



How do I get the contents of that file back? Is there a way I can find the contents on the web, and just copy them back in? What are my options here, considering that terminal gives an error talking about "Too many Symbolic Links?"



I'm still a newcomer to this kind of thing, and I appreciate all the help I can get.



Edit: I forgot to mention I'm on Kali 2.2 Rolling, which is pretty much debian with some added features.



Edit 2: I also restarted the machine, as I didn't realize my mistake until a few days ago. That makes this quite a bit harder.










share|improve this question




















  • 9





    Deleted bash? Just use zsh :-) </troll>

    – Kevin
    Oct 17 '17 at 18:40






  • 1





    serverfault.com/questions/451528/… and several others

    – skandigraun
    Oct 17 '17 at 19:38













  • physical or VM?

    – Ben Aveling
    Oct 18 '17 at 2:51






  • 9





    For next time: do not put stuff in system directories. If you want custom scripts and stuff, either make yourself a $HOME/.bin and add it to your PATH or use /usr/local/bin if you need it to be system-wide. Or, even better yet, build a package.

    – spectras
    Oct 18 '17 at 17:56


















25















I accidentally overwrote the /bin/bash file with a dumb script that I intented to put inside the /bin folder.



How do I get the contents of that file back? Is there a way I can find the contents on the web, and just copy them back in? What are my options here, considering that terminal gives an error talking about "Too many Symbolic Links?"



I'm still a newcomer to this kind of thing, and I appreciate all the help I can get.



Edit: I forgot to mention I'm on Kali 2.2 Rolling, which is pretty much debian with some added features.



Edit 2: I also restarted the machine, as I didn't realize my mistake until a few days ago. That makes this quite a bit harder.










share|improve this question




















  • 9





    Deleted bash? Just use zsh :-) </troll>

    – Kevin
    Oct 17 '17 at 18:40






  • 1





    serverfault.com/questions/451528/… and several others

    – skandigraun
    Oct 17 '17 at 19:38













  • physical or VM?

    – Ben Aveling
    Oct 18 '17 at 2:51






  • 9





    For next time: do not put stuff in system directories. If you want custom scripts and stuff, either make yourself a $HOME/.bin and add it to your PATH or use /usr/local/bin if you need it to be system-wide. Or, even better yet, build a package.

    – spectras
    Oct 18 '17 at 17:56
















25












25








25


8






I accidentally overwrote the /bin/bash file with a dumb script that I intented to put inside the /bin folder.



How do I get the contents of that file back? Is there a way I can find the contents on the web, and just copy them back in? What are my options here, considering that terminal gives an error talking about "Too many Symbolic Links?"



I'm still a newcomer to this kind of thing, and I appreciate all the help I can get.



Edit: I forgot to mention I'm on Kali 2.2 Rolling, which is pretty much debian with some added features.



Edit 2: I also restarted the machine, as I didn't realize my mistake until a few days ago. That makes this quite a bit harder.










share|improve this question
















I accidentally overwrote the /bin/bash file with a dumb script that I intented to put inside the /bin folder.



How do I get the contents of that file back? Is there a way I can find the contents on the web, and just copy them back in? What are my options here, considering that terminal gives an error talking about "Too many Symbolic Links?"



I'm still a newcomer to this kind of thing, and I appreciate all the help I can get.



Edit: I forgot to mention I'm on Kali 2.2 Rolling, which is pretty much debian with some added features.



Edit 2: I also restarted the machine, as I didn't realize my mistake until a few days ago. That makes this quite a bit harder.







linux bash kali-linux data-recovery






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 1 hour ago









Rui F Ribeiro

39.6k1479132




39.6k1479132










asked Oct 17 '17 at 4:38









GarrukApexGarrukApex

3081410




3081410








  • 9





    Deleted bash? Just use zsh :-) </troll>

    – Kevin
    Oct 17 '17 at 18:40






  • 1





    serverfault.com/questions/451528/… and several others

    – skandigraun
    Oct 17 '17 at 19:38













  • physical or VM?

    – Ben Aveling
    Oct 18 '17 at 2:51






  • 9





    For next time: do not put stuff in system directories. If you want custom scripts and stuff, either make yourself a $HOME/.bin and add it to your PATH or use /usr/local/bin if you need it to be system-wide. Or, even better yet, build a package.

    – spectras
    Oct 18 '17 at 17:56
















  • 9





    Deleted bash? Just use zsh :-) </troll>

    – Kevin
    Oct 17 '17 at 18:40






  • 1





    serverfault.com/questions/451528/… and several others

    – skandigraun
    Oct 17 '17 at 19:38













  • physical or VM?

    – Ben Aveling
    Oct 18 '17 at 2:51






  • 9





    For next time: do not put stuff in system directories. If you want custom scripts and stuff, either make yourself a $HOME/.bin and add it to your PATH or use /usr/local/bin if you need it to be system-wide. Or, even better yet, build a package.

    – spectras
    Oct 18 '17 at 17:56










9




9





Deleted bash? Just use zsh :-) </troll>

– Kevin
Oct 17 '17 at 18:40





Deleted bash? Just use zsh :-) </troll>

– Kevin
Oct 17 '17 at 18:40




1




1





serverfault.com/questions/451528/… and several others

– skandigraun
Oct 17 '17 at 19:38







serverfault.com/questions/451528/… and several others

– skandigraun
Oct 17 '17 at 19:38















physical or VM?

– Ben Aveling
Oct 18 '17 at 2:51





physical or VM?

– Ben Aveling
Oct 18 '17 at 2:51




9




9





For next time: do not put stuff in system directories. If you want custom scripts and stuff, either make yourself a $HOME/.bin and add it to your PATH or use /usr/local/bin if you need it to be system-wide. Or, even better yet, build a package.

– spectras
Oct 18 '17 at 17:56







For next time: do not put stuff in system directories. If you want custom scripts and stuff, either make yourself a $HOME/.bin and add it to your PATH or use /usr/local/bin if you need it to be system-wide. Or, even better yet, build a package.

– spectras
Oct 18 '17 at 17:56












3 Answers
3






active

oldest

votes


















31














bash is a shell, probably your system shell, so now weird things happen, while parts of the shell are still in memory. Once you log out or reboot, you,ll be in deeper trouble.



So the first thing should be to change your shell to something safe. See what shells you have installed



cat /etc/shells


Then change your shell to one of the other shells listed there, for example



chsh -s /bin/dash


Update, because you already rebooted:



You are lucky that nowadays the boot process doesn't rely on bash, so your system boots, you just can't get a command line. But you can start an editor to edit /etc/passwd and change the shell in the root line from /bin/bash to /bin/dash. Log out and log in again. Just don't make any other change in that file, or you may mess up your system completely.



Then try to reinstall bash with



apt-get --reinstall install bash


If everything succeeded you can chsh back to bash.



Finally: I think, kali is a highly specialized distribution, probably not suited for people who accidently overwrite their shell. As this sentence was called rude and harsh, I should add that I wrote it out of my own experience. When I was younger, I did ruin my system because nobody told me to avoid messing around as root.






share|improve this answer





















  • 3





    @dr01: Given how bash escaping works, it can be a matter of a misplaced quote. Think command > /bin/bash ... versus command > (/bin/bash ...).

    – MSalters
    Oct 17 '17 at 13:15






  • 7





    That last sentence was harsh...:)

    – James K Polk
    Oct 17 '17 at 16:07






  • 6





    @MSalters A misplaced quote run as root. That's two mistakes. The second one, of course, being trying out your complicated pipelines as root, not as a non-privileged user.

    – derobert
    Oct 17 '17 at 16:30






  • 12





    @JamesKPolk no, it isn't harsh at all. It's the simple truth. Kali is a professional tool designed to be used by experts. They even state as much on their webpage. If you aren't an expert, you really have no business running Kali.

    – terdon
    Oct 18 '17 at 10:58








  • 2





    The last sentence is not harsh. It's the plain truth.

    – Andrea Lazzarotto
    Oct 21 '17 at 13:39



















64














Don't shut down your machine.



Do you still have a running shell? Is it bash? If so, you're fine. (But don't do this again.)



Run:



sudo cp /proc/$$/exe /bin/bash


Voila, all is well.





Since someone in the comments doubts that this works:



[vagrant@localhost ~]$ cat /etc/shells 
/bin/sh
/bin/bash
/sbin/nologin
/bin/dash
/bin/tcsh
/bin/csh
[vagrant@localhost ~]$ grep root /etc/passwd
root:x:0:0:root:/root:/bin/bash
operator:x:11:0:operator:/root:/sbin/nologin
[vagrant@localhost ~]$ echo $0
-bash
[vagrant@localhost ~]$ sudo rm /bin/bash
[vagrant@localhost ~]$ bash
-bash: /bin/bash: No such file or directory
[vagrant@localhost ~]$ sudo su -
su: /bin/bash: No such file or directory
[vagrant@localhost ~]$ sudo cp /proc/$$/exe /bin/bash
[vagrant@localhost ~]$ bash
[vagrant@localhost ~]$ exit
[vagrant@localhost ~]$ sudo su -
[root@localhost ~]# logout
[vagrant@localhost ~]$





share|improve this answer





















  • 17





    In any case, after this, it is recommended to reinstall bash from your distribution, e.g. for correct permissions (some rootkit hunter could be surprised of changes there), also to restore hard link or symlink (e.g. to /bin/sh or rbash)

    – Giacomo Catenazzi
    Oct 17 '17 at 13:13






  • 4





    @GiacomoCatenazzi, actually, this method preserves permissions—that's default when root runs cp. Hard links are a good point, though.

    – Wildcard
    Oct 17 '17 at 18:02






  • 1





    The machine was restarted. I can't open a normal shell, but I can edit the contents through the GUI. As said before, I get an error stating "Failed to execute child process /bin/bash. (Too many levels of symbolic links)."

    – GarrukApex
    Oct 18 '17 at 0:56



















4














If you can login, but you can’t open a terminal or otherwise access a shell,
but you can access files through the GUI, go to /bin,
look for files whose names end with sh (but not .sh)
and run one (by double-clicking or right-clicking). 
In particular, look for the following:




  • sh

  • dash

  • ash

  • ksh

  • zsh


If you can get a shell running, then try Philippos’s answer.



Another approach is to boot into single-user mode
following these instructions
but specify init=/bin/sh (or one of the other shells)
instead of init=/bin/bash.






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%2f398543%2fwhat-are-the-contents-of-bin-bash-and-what-do-i-do-if-i-accidentally-overwrote%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    31














    bash is a shell, probably your system shell, so now weird things happen, while parts of the shell are still in memory. Once you log out or reboot, you,ll be in deeper trouble.



    So the first thing should be to change your shell to something safe. See what shells you have installed



    cat /etc/shells


    Then change your shell to one of the other shells listed there, for example



    chsh -s /bin/dash


    Update, because you already rebooted:



    You are lucky that nowadays the boot process doesn't rely on bash, so your system boots, you just can't get a command line. But you can start an editor to edit /etc/passwd and change the shell in the root line from /bin/bash to /bin/dash. Log out and log in again. Just don't make any other change in that file, or you may mess up your system completely.



    Then try to reinstall bash with



    apt-get --reinstall install bash


    If everything succeeded you can chsh back to bash.



    Finally: I think, kali is a highly specialized distribution, probably not suited for people who accidently overwrite their shell. As this sentence was called rude and harsh, I should add that I wrote it out of my own experience. When I was younger, I did ruin my system because nobody told me to avoid messing around as root.






    share|improve this answer





















    • 3





      @dr01: Given how bash escaping works, it can be a matter of a misplaced quote. Think command > /bin/bash ... versus command > (/bin/bash ...).

      – MSalters
      Oct 17 '17 at 13:15






    • 7





      That last sentence was harsh...:)

      – James K Polk
      Oct 17 '17 at 16:07






    • 6





      @MSalters A misplaced quote run as root. That's two mistakes. The second one, of course, being trying out your complicated pipelines as root, not as a non-privileged user.

      – derobert
      Oct 17 '17 at 16:30






    • 12





      @JamesKPolk no, it isn't harsh at all. It's the simple truth. Kali is a professional tool designed to be used by experts. They even state as much on their webpage. If you aren't an expert, you really have no business running Kali.

      – terdon
      Oct 18 '17 at 10:58








    • 2





      The last sentence is not harsh. It's the plain truth.

      – Andrea Lazzarotto
      Oct 21 '17 at 13:39
















    31














    bash is a shell, probably your system shell, so now weird things happen, while parts of the shell are still in memory. Once you log out or reboot, you,ll be in deeper trouble.



    So the first thing should be to change your shell to something safe. See what shells you have installed



    cat /etc/shells


    Then change your shell to one of the other shells listed there, for example



    chsh -s /bin/dash


    Update, because you already rebooted:



    You are lucky that nowadays the boot process doesn't rely on bash, so your system boots, you just can't get a command line. But you can start an editor to edit /etc/passwd and change the shell in the root line from /bin/bash to /bin/dash. Log out and log in again. Just don't make any other change in that file, or you may mess up your system completely.



    Then try to reinstall bash with



    apt-get --reinstall install bash


    If everything succeeded you can chsh back to bash.



    Finally: I think, kali is a highly specialized distribution, probably not suited for people who accidently overwrite their shell. As this sentence was called rude and harsh, I should add that I wrote it out of my own experience. When I was younger, I did ruin my system because nobody told me to avoid messing around as root.






    share|improve this answer





















    • 3





      @dr01: Given how bash escaping works, it can be a matter of a misplaced quote. Think command > /bin/bash ... versus command > (/bin/bash ...).

      – MSalters
      Oct 17 '17 at 13:15






    • 7





      That last sentence was harsh...:)

      – James K Polk
      Oct 17 '17 at 16:07






    • 6





      @MSalters A misplaced quote run as root. That's two mistakes. The second one, of course, being trying out your complicated pipelines as root, not as a non-privileged user.

      – derobert
      Oct 17 '17 at 16:30






    • 12





      @JamesKPolk no, it isn't harsh at all. It's the simple truth. Kali is a professional tool designed to be used by experts. They even state as much on their webpage. If you aren't an expert, you really have no business running Kali.

      – terdon
      Oct 18 '17 at 10:58








    • 2





      The last sentence is not harsh. It's the plain truth.

      – Andrea Lazzarotto
      Oct 21 '17 at 13:39














    31












    31








    31







    bash is a shell, probably your system shell, so now weird things happen, while parts of the shell are still in memory. Once you log out or reboot, you,ll be in deeper trouble.



    So the first thing should be to change your shell to something safe. See what shells you have installed



    cat /etc/shells


    Then change your shell to one of the other shells listed there, for example



    chsh -s /bin/dash


    Update, because you already rebooted:



    You are lucky that nowadays the boot process doesn't rely on bash, so your system boots, you just can't get a command line. But you can start an editor to edit /etc/passwd and change the shell in the root line from /bin/bash to /bin/dash. Log out and log in again. Just don't make any other change in that file, or you may mess up your system completely.



    Then try to reinstall bash with



    apt-get --reinstall install bash


    If everything succeeded you can chsh back to bash.



    Finally: I think, kali is a highly specialized distribution, probably not suited for people who accidently overwrite their shell. As this sentence was called rude and harsh, I should add that I wrote it out of my own experience. When I was younger, I did ruin my system because nobody told me to avoid messing around as root.






    share|improve this answer















    bash is a shell, probably your system shell, so now weird things happen, while parts of the shell are still in memory. Once you log out or reboot, you,ll be in deeper trouble.



    So the first thing should be to change your shell to something safe. See what shells you have installed



    cat /etc/shells


    Then change your shell to one of the other shells listed there, for example



    chsh -s /bin/dash


    Update, because you already rebooted:



    You are lucky that nowadays the boot process doesn't rely on bash, so your system boots, you just can't get a command line. But you can start an editor to edit /etc/passwd and change the shell in the root line from /bin/bash to /bin/dash. Log out and log in again. Just don't make any other change in that file, or you may mess up your system completely.



    Then try to reinstall bash with



    apt-get --reinstall install bash


    If everything succeeded you can chsh back to bash.



    Finally: I think, kali is a highly specialized distribution, probably not suited for people who accidently overwrite their shell. As this sentence was called rude and harsh, I should add that I wrote it out of my own experience. When I was younger, I did ruin my system because nobody told me to avoid messing around as root.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Oct 18 '17 at 6:03

























    answered Oct 17 '17 at 6:10









    PhilipposPhilippos

    6,02711547




    6,02711547








    • 3





      @dr01: Given how bash escaping works, it can be a matter of a misplaced quote. Think command > /bin/bash ... versus command > (/bin/bash ...).

      – MSalters
      Oct 17 '17 at 13:15






    • 7





      That last sentence was harsh...:)

      – James K Polk
      Oct 17 '17 at 16:07






    • 6





      @MSalters A misplaced quote run as root. That's two mistakes. The second one, of course, being trying out your complicated pipelines as root, not as a non-privileged user.

      – derobert
      Oct 17 '17 at 16:30






    • 12





      @JamesKPolk no, it isn't harsh at all. It's the simple truth. Kali is a professional tool designed to be used by experts. They even state as much on their webpage. If you aren't an expert, you really have no business running Kali.

      – terdon
      Oct 18 '17 at 10:58








    • 2





      The last sentence is not harsh. It's the plain truth.

      – Andrea Lazzarotto
      Oct 21 '17 at 13:39














    • 3





      @dr01: Given how bash escaping works, it can be a matter of a misplaced quote. Think command > /bin/bash ... versus command > (/bin/bash ...).

      – MSalters
      Oct 17 '17 at 13:15






    • 7





      That last sentence was harsh...:)

      – James K Polk
      Oct 17 '17 at 16:07






    • 6





      @MSalters A misplaced quote run as root. That's two mistakes. The second one, of course, being trying out your complicated pipelines as root, not as a non-privileged user.

      – derobert
      Oct 17 '17 at 16:30






    • 12





      @JamesKPolk no, it isn't harsh at all. It's the simple truth. Kali is a professional tool designed to be used by experts. They even state as much on their webpage. If you aren't an expert, you really have no business running Kali.

      – terdon
      Oct 18 '17 at 10:58








    • 2





      The last sentence is not harsh. It's the plain truth.

      – Andrea Lazzarotto
      Oct 21 '17 at 13:39








    3




    3





    @dr01: Given how bash escaping works, it can be a matter of a misplaced quote. Think command > /bin/bash ... versus command > (/bin/bash ...).

    – MSalters
    Oct 17 '17 at 13:15





    @dr01: Given how bash escaping works, it can be a matter of a misplaced quote. Think command > /bin/bash ... versus command > (/bin/bash ...).

    – MSalters
    Oct 17 '17 at 13:15




    7




    7





    That last sentence was harsh...:)

    – James K Polk
    Oct 17 '17 at 16:07





    That last sentence was harsh...:)

    – James K Polk
    Oct 17 '17 at 16:07




    6




    6





    @MSalters A misplaced quote run as root. That's two mistakes. The second one, of course, being trying out your complicated pipelines as root, not as a non-privileged user.

    – derobert
    Oct 17 '17 at 16:30





    @MSalters A misplaced quote run as root. That's two mistakes. The second one, of course, being trying out your complicated pipelines as root, not as a non-privileged user.

    – derobert
    Oct 17 '17 at 16:30




    12




    12





    @JamesKPolk no, it isn't harsh at all. It's the simple truth. Kali is a professional tool designed to be used by experts. They even state as much on their webpage. If you aren't an expert, you really have no business running Kali.

    – terdon
    Oct 18 '17 at 10:58







    @JamesKPolk no, it isn't harsh at all. It's the simple truth. Kali is a professional tool designed to be used by experts. They even state as much on their webpage. If you aren't an expert, you really have no business running Kali.

    – terdon
    Oct 18 '17 at 10:58






    2




    2





    The last sentence is not harsh. It's the plain truth.

    – Andrea Lazzarotto
    Oct 21 '17 at 13:39





    The last sentence is not harsh. It's the plain truth.

    – Andrea Lazzarotto
    Oct 21 '17 at 13:39













    64














    Don't shut down your machine.



    Do you still have a running shell? Is it bash? If so, you're fine. (But don't do this again.)



    Run:



    sudo cp /proc/$$/exe /bin/bash


    Voila, all is well.





    Since someone in the comments doubts that this works:



    [vagrant@localhost ~]$ cat /etc/shells 
    /bin/sh
    /bin/bash
    /sbin/nologin
    /bin/dash
    /bin/tcsh
    /bin/csh
    [vagrant@localhost ~]$ grep root /etc/passwd
    root:x:0:0:root:/root:/bin/bash
    operator:x:11:0:operator:/root:/sbin/nologin
    [vagrant@localhost ~]$ echo $0
    -bash
    [vagrant@localhost ~]$ sudo rm /bin/bash
    [vagrant@localhost ~]$ bash
    -bash: /bin/bash: No such file or directory
    [vagrant@localhost ~]$ sudo su -
    su: /bin/bash: No such file or directory
    [vagrant@localhost ~]$ sudo cp /proc/$$/exe /bin/bash
    [vagrant@localhost ~]$ bash
    [vagrant@localhost ~]$ exit
    [vagrant@localhost ~]$ sudo su -
    [root@localhost ~]# logout
    [vagrant@localhost ~]$





    share|improve this answer





















    • 17





      In any case, after this, it is recommended to reinstall bash from your distribution, e.g. for correct permissions (some rootkit hunter could be surprised of changes there), also to restore hard link or symlink (e.g. to /bin/sh or rbash)

      – Giacomo Catenazzi
      Oct 17 '17 at 13:13






    • 4





      @GiacomoCatenazzi, actually, this method preserves permissions—that's default when root runs cp. Hard links are a good point, though.

      – Wildcard
      Oct 17 '17 at 18:02






    • 1





      The machine was restarted. I can't open a normal shell, but I can edit the contents through the GUI. As said before, I get an error stating "Failed to execute child process /bin/bash. (Too many levels of symbolic links)."

      – GarrukApex
      Oct 18 '17 at 0:56
















    64














    Don't shut down your machine.



    Do you still have a running shell? Is it bash? If so, you're fine. (But don't do this again.)



    Run:



    sudo cp /proc/$$/exe /bin/bash


    Voila, all is well.





    Since someone in the comments doubts that this works:



    [vagrant@localhost ~]$ cat /etc/shells 
    /bin/sh
    /bin/bash
    /sbin/nologin
    /bin/dash
    /bin/tcsh
    /bin/csh
    [vagrant@localhost ~]$ grep root /etc/passwd
    root:x:0:0:root:/root:/bin/bash
    operator:x:11:0:operator:/root:/sbin/nologin
    [vagrant@localhost ~]$ echo $0
    -bash
    [vagrant@localhost ~]$ sudo rm /bin/bash
    [vagrant@localhost ~]$ bash
    -bash: /bin/bash: No such file or directory
    [vagrant@localhost ~]$ sudo su -
    su: /bin/bash: No such file or directory
    [vagrant@localhost ~]$ sudo cp /proc/$$/exe /bin/bash
    [vagrant@localhost ~]$ bash
    [vagrant@localhost ~]$ exit
    [vagrant@localhost ~]$ sudo su -
    [root@localhost ~]# logout
    [vagrant@localhost ~]$





    share|improve this answer





















    • 17





      In any case, after this, it is recommended to reinstall bash from your distribution, e.g. for correct permissions (some rootkit hunter could be surprised of changes there), also to restore hard link or symlink (e.g. to /bin/sh or rbash)

      – Giacomo Catenazzi
      Oct 17 '17 at 13:13






    • 4





      @GiacomoCatenazzi, actually, this method preserves permissions—that's default when root runs cp. Hard links are a good point, though.

      – Wildcard
      Oct 17 '17 at 18:02






    • 1





      The machine was restarted. I can't open a normal shell, but I can edit the contents through the GUI. As said before, I get an error stating "Failed to execute child process /bin/bash. (Too many levels of symbolic links)."

      – GarrukApex
      Oct 18 '17 at 0:56














    64












    64








    64







    Don't shut down your machine.



    Do you still have a running shell? Is it bash? If so, you're fine. (But don't do this again.)



    Run:



    sudo cp /proc/$$/exe /bin/bash


    Voila, all is well.





    Since someone in the comments doubts that this works:



    [vagrant@localhost ~]$ cat /etc/shells 
    /bin/sh
    /bin/bash
    /sbin/nologin
    /bin/dash
    /bin/tcsh
    /bin/csh
    [vagrant@localhost ~]$ grep root /etc/passwd
    root:x:0:0:root:/root:/bin/bash
    operator:x:11:0:operator:/root:/sbin/nologin
    [vagrant@localhost ~]$ echo $0
    -bash
    [vagrant@localhost ~]$ sudo rm /bin/bash
    [vagrant@localhost ~]$ bash
    -bash: /bin/bash: No such file or directory
    [vagrant@localhost ~]$ sudo su -
    su: /bin/bash: No such file or directory
    [vagrant@localhost ~]$ sudo cp /proc/$$/exe /bin/bash
    [vagrant@localhost ~]$ bash
    [vagrant@localhost ~]$ exit
    [vagrant@localhost ~]$ sudo su -
    [root@localhost ~]# logout
    [vagrant@localhost ~]$





    share|improve this answer















    Don't shut down your machine.



    Do you still have a running shell? Is it bash? If so, you're fine. (But don't do this again.)



    Run:



    sudo cp /proc/$$/exe /bin/bash


    Voila, all is well.





    Since someone in the comments doubts that this works:



    [vagrant@localhost ~]$ cat /etc/shells 
    /bin/sh
    /bin/bash
    /sbin/nologin
    /bin/dash
    /bin/tcsh
    /bin/csh
    [vagrant@localhost ~]$ grep root /etc/passwd
    root:x:0:0:root:/root:/bin/bash
    operator:x:11:0:operator:/root:/sbin/nologin
    [vagrant@localhost ~]$ echo $0
    -bash
    [vagrant@localhost ~]$ sudo rm /bin/bash
    [vagrant@localhost ~]$ bash
    -bash: /bin/bash: No such file or directory
    [vagrant@localhost ~]$ sudo su -
    su: /bin/bash: No such file or directory
    [vagrant@localhost ~]$ sudo cp /proc/$$/exe /bin/bash
    [vagrant@localhost ~]$ bash
    [vagrant@localhost ~]$ exit
    [vagrant@localhost ~]$ sudo su -
    [root@localhost ~]# logout
    [vagrant@localhost ~]$






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Dec 13 '17 at 6:48

























    answered Oct 17 '17 at 6:32









    WildcardWildcard

    22.8k963166




    22.8k963166








    • 17





      In any case, after this, it is recommended to reinstall bash from your distribution, e.g. for correct permissions (some rootkit hunter could be surprised of changes there), also to restore hard link or symlink (e.g. to /bin/sh or rbash)

      – Giacomo Catenazzi
      Oct 17 '17 at 13:13






    • 4





      @GiacomoCatenazzi, actually, this method preserves permissions—that's default when root runs cp. Hard links are a good point, though.

      – Wildcard
      Oct 17 '17 at 18:02






    • 1





      The machine was restarted. I can't open a normal shell, but I can edit the contents through the GUI. As said before, I get an error stating "Failed to execute child process /bin/bash. (Too many levels of symbolic links)."

      – GarrukApex
      Oct 18 '17 at 0:56














    • 17





      In any case, after this, it is recommended to reinstall bash from your distribution, e.g. for correct permissions (some rootkit hunter could be surprised of changes there), also to restore hard link or symlink (e.g. to /bin/sh or rbash)

      – Giacomo Catenazzi
      Oct 17 '17 at 13:13






    • 4





      @GiacomoCatenazzi, actually, this method preserves permissions—that's default when root runs cp. Hard links are a good point, though.

      – Wildcard
      Oct 17 '17 at 18:02






    • 1





      The machine was restarted. I can't open a normal shell, but I can edit the contents through the GUI. As said before, I get an error stating "Failed to execute child process /bin/bash. (Too many levels of symbolic links)."

      – GarrukApex
      Oct 18 '17 at 0:56








    17




    17





    In any case, after this, it is recommended to reinstall bash from your distribution, e.g. for correct permissions (some rootkit hunter could be surprised of changes there), also to restore hard link or symlink (e.g. to /bin/sh or rbash)

    – Giacomo Catenazzi
    Oct 17 '17 at 13:13





    In any case, after this, it is recommended to reinstall bash from your distribution, e.g. for correct permissions (some rootkit hunter could be surprised of changes there), also to restore hard link or symlink (e.g. to /bin/sh or rbash)

    – Giacomo Catenazzi
    Oct 17 '17 at 13:13




    4




    4





    @GiacomoCatenazzi, actually, this method preserves permissions—that's default when root runs cp. Hard links are a good point, though.

    – Wildcard
    Oct 17 '17 at 18:02





    @GiacomoCatenazzi, actually, this method preserves permissions—that's default when root runs cp. Hard links are a good point, though.

    – Wildcard
    Oct 17 '17 at 18:02




    1




    1





    The machine was restarted. I can't open a normal shell, but I can edit the contents through the GUI. As said before, I get an error stating "Failed to execute child process /bin/bash. (Too many levels of symbolic links)."

    – GarrukApex
    Oct 18 '17 at 0:56





    The machine was restarted. I can't open a normal shell, but I can edit the contents through the GUI. As said before, I get an error stating "Failed to execute child process /bin/bash. (Too many levels of symbolic links)."

    – GarrukApex
    Oct 18 '17 at 0:56











    4














    If you can login, but you can’t open a terminal or otherwise access a shell,
    but you can access files through the GUI, go to /bin,
    look for files whose names end with sh (but not .sh)
    and run one (by double-clicking or right-clicking). 
    In particular, look for the following:




    • sh

    • dash

    • ash

    • ksh

    • zsh


    If you can get a shell running, then try Philippos’s answer.



    Another approach is to boot into single-user mode
    following these instructions
    but specify init=/bin/sh (or one of the other shells)
    instead of init=/bin/bash.






    share|improve this answer




























      4














      If you can login, but you can’t open a terminal or otherwise access a shell,
      but you can access files through the GUI, go to /bin,
      look for files whose names end with sh (but not .sh)
      and run one (by double-clicking or right-clicking). 
      In particular, look for the following:




      • sh

      • dash

      • ash

      • ksh

      • zsh


      If you can get a shell running, then try Philippos’s answer.



      Another approach is to boot into single-user mode
      following these instructions
      but specify init=/bin/sh (or one of the other shells)
      instead of init=/bin/bash.






      share|improve this answer


























        4












        4








        4







        If you can login, but you can’t open a terminal or otherwise access a shell,
        but you can access files through the GUI, go to /bin,
        look for files whose names end with sh (but not .sh)
        and run one (by double-clicking or right-clicking). 
        In particular, look for the following:




        • sh

        • dash

        • ash

        • ksh

        • zsh


        If you can get a shell running, then try Philippos’s answer.



        Another approach is to boot into single-user mode
        following these instructions
        but specify init=/bin/sh (or one of the other shells)
        instead of init=/bin/bash.






        share|improve this answer













        If you can login, but you can’t open a terminal or otherwise access a shell,
        but you can access files through the GUI, go to /bin,
        look for files whose names end with sh (but not .sh)
        and run one (by double-clicking or right-clicking). 
        In particular, look for the following:




        • sh

        • dash

        • ash

        • ksh

        • zsh


        If you can get a shell running, then try Philippos’s answer.



        Another approach is to boot into single-user mode
        following these instructions
        but specify init=/bin/sh (or one of the other shells)
        instead of init=/bin/bash.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Oct 18 '17 at 2:42









        ScottScott

        6,87152750




        6,87152750






























            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%2f398543%2fwhat-are-the-contents-of-bin-bash-and-what-do-i-do-if-i-accidentally-overwrote%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

            Loup dans la culture

            How to solve the problem of ntp “Unable to contact time server” from KDE?

            ASUS Zenbook UX433/UX333 — Configure Touchpad-embedded numpad on Linux