Note: This answer covers the case where the breakage was brought about solely by changes to
~/.bash_aliases, whether by successfully making
python an alias of a different Python interpreter or by accidentally introducing a syntax error or other malfunctioning commands. But the close similarity between this question and another recently asked question, together with the information that other changes were made in the case described here, suggests that this problem is likely to occur (and in this case probably did occur) as a result of the global Python interpreter actually being changed, rather than as the result of any change to
Readers who have used an
alias-based technique to make
python run a different Python interpreter, especially if the system
python is Python 2 and the other interpreter is Python 3, and who haven't made any other major changes, should be able to solve the problem just by following the steps in this answer. Readers who have changed what
/usr/bin/python points to (whether with
ln or with
update-alternatives) or uninstalled Python-related packages are far more likely to be helped by programmer's own answer to this question.
Based on what you said, I'm going to assume that the only modification you made before the problem started was editing
~./bashrc. If that is the case, then you did not change your Ubuntu system's default Python version.
Instead, you edited
~/.bashrc and added an alias to make
python3.7 in interactive Bash shells, or attempted to do so. Perhaps that alias broke something later in
~/.bashrc, or perhaps you made some mistake while editing
~/.bashrc and the problem has nothing directly to do with that alias. Either way, now whenever you start an interactive Bash shell, it quits almost immediately.
The solution is to back up the broken
~/.bashrc for later reference, then copy
/etc/skel/.bashrc to your home directory, overwriting it and restoring default behavior. There a various schemes for getting a working shell while in your situation, but you shouldn't need any of them, since you don't need a shell to copy a file you can read into a directory where you can write. You can perform the copy using your graphical file browser.
You run a graphical terminal application, which you launch by pressing Ctrl+Alt+T, so unless your terminal automatically starts SSH sessions to a separate Ubuntu system where the problem occurred, I presume you also have the ability to run a graphical file browser on the system that has the problem. I'm not sure what you mean by "I can only talk to ubuntu using my terminal". At first I thought maybe this was a WSL system and the terminal was a Windows application, in which case a different workaround would be needed. But if that were so, you probably wouldn't start it by pressing Ctrl+Alt+T.
Nonetheless. if you cannot run a graphical file browser on this system, then it should still be possible to solve this fairly easily. If that is the case, then I recommend that you add details to your question about why that is.
To clarify why I recommend backing up the broken
.bashrc that's currently there before overwriting it: This is so you can figure you precisely what went wrong, and to ensure you can get back any other customizations you've made.
In your question, you showed a screenshot of Prvt_Yadav's answer to How to make python3.7 default and said you ran
nano ~/.bashrc to make the modification shown at the top of the answer. That change consists of adding the line:
That defines a shell alias. Shells aliases don't affect the behavior of the system as a whole, nor do they affect what happens when you try to run scripts. They don't affect the behavior of graphical programs (except in the sense that they affect shells, and shells affect terminals, and some terminals are graphical). Furthermore, the file you edited--
.bashrc in your home directory--is specific to your user account, so it does not affect other users. All that alias definition does is make it so commands you run in your shell that start with
python3 behave is if they started with
When you run a graphical terminal program, the terminal runs a shell. Unless you've configured the graphical terminal program to behave otherwise, this shell is the shell you've configured Ubuntu to give you for non-graphical logins. Unless you've changed that shell, it's
When an interactive
bash shell (and some noninteractive bash shells) starts, it sources some startup files, which is to say that it reads them and tries to run all the commands in them. Which files these are depend on how you ran the shell, but typically--and, in the case of a shell run from a graphical terminal opened from a desktop session, essentially always--they include the
.bashrc file in your home directory.
.bashrc is sourced, rather than run as a script in a separate shell process, it's able to set up the environment for the shell that starts it, which is its purpose. But this also means that commands run in it, like
exit, affect that shell. There are various ways a mistake in
.bashrc can cause your shell to immediately quit (and not all are as obvious as the presence of
When the shell your graphical terminal ran quits, your terminal window/tab
closes (unless you've configured your terminal to behave otherwise). In most cases this has the effect of quitting the terminal application entirely.
How to Fix It
All that is necessary to solve the problem is to restore an unbroken copy of
.bashrc. Actually, it should be sufficient simply to rename (or delete)
~/.bashrc, but without that file, your shell might not behave as much as you expect. Since it's not significantly harder to copy the unbroken file from
/etc/skel/.bashrc to your home directory, I recommend you do that. This is the file that is copied to a user's home directory when the user account is newly created.
Assuming your graphical file browser (usually this is Nautilus) works, you can use that to copy the file. This does not require any elevated privileges.
- Open your home directory in a graphical file browser window.
- Show hidden files. Ctrl+H will do this in basically all graphical file browsers. (Unless they're already shown, in which case Ctrl+H re-hides them.)
.bashrc. I suggest changing the name to
- Open another graphical file browser window or tab and go to
.bashrc from there to your home directory.
- Try opening your terminal application. The problem should be fixed.
Then you can figure out what went wrong. For example, you can use the
diff command to compare the two files. You can also open the renamed old file in a text editor.
I'm assuming you have a graphical file browser because you have a graphical terminal. Anytime you install a version of Ubuntu that comes with a graphical interface, it has a graphical file browser. In "vanilla" Ubuntu systems this is Nautilus, but it's Thunar in Xubuntu, Dolpin in Kubuntu, PCManFM in Lubuntu, and so forth.
Similarly, you should have a graphical text editor. In "vanilla" Ubuntu systems this is Gedit, but it's Mousepad in Xubuntu, Kate in Kubuntu, Leafpad in Lubuntu, and so forth. You could actually edit up
~/.bashrc in your graphical text editor and attempt to fix the problem that way, without ever first restoring it from
/etc/skel/. I don't recommend that, though. Instead, I recommend regaining your ability to use interactive shells before proceeding with anything else.
Assuming you didn't follow any of the other instructions in that answer, and just edited
~/.bashrc, and didn't make any other modification to change your default Python version, what you did was actually one of the safest possible things you could do in order to change the behavior of the
This is because, if done correctly, it only affects which interpreter is run when you run
python3 interactively (and when
python3 is run from a file like
.bashrc in an interactive shell, below where the alias was defined).
Therefore, if you do decide to proceed with changing the behavior of Python-related commands, I recommend being extra careful with anything that involves running
update-alternatives. Basically, you should not use
update-alternatives techniques in Ubuntu for changing the system Python interpreter. Likewise, you should not manually modify files in
/usr/bin to change the default version of Python. (These are the sorts of things that some commenters thought you'd done, perhaps because, unfortunately, people very commonly do them, resulting in broken Ubuntu systems.)