3

I was trying to make python version 3 as a default version of Ubuntu,

I used nano ~/.bashrc and added the first line of this answer.

enter image description here Then It just messed up my terminal. Now when I am clicking on my Terminal or trying to access by ctrl+alt+t, the terminal does open/run. I can only talk to ubuntu using my terminal how could I fix this?

Please advise!

Pls, note that the terminal icon is present, but the terminal does not open when clicked on. How do I get the terminal to open and work?

Update: I deleted that line from .bashrc. However, I still have a problem opening my terminal. I also see this sign on my ubuntu as well.

enter image description here

saying: a problem occurred when checking for the updates ubuntu 18.04

6
  • 2
    Making another python default breaks your system. Revert this back.
    – Pilot6
    Jun 4, 2020 at 23:07
  • How can I revert it?
    – nikki
    Jun 4, 2020 at 23:17
  • 2
    Look at what you did and revert it back.
    – Pilot6
    Jun 4, 2020 at 23:18
  • I edited my post and put the answer that I followed, I do not really know how to revert it. I do not have any terminal to communicate with Ubuntu.
    – nikki
    Jun 4, 2020 at 23:30
  • Boot from a LiveUSB, mount your HDD, then you can edit the file.
    – user535733
    Jun 5, 2020 at 0:55

2 Answers 2

4
sudo apt-get --reinstall install python3-minimal 

I too tried many things, but this simple thing solved my issue.

1
  • 3
    I'm glad the problem is solved! I had expected I'd notice edits to the question, and I didn't see your edit until afterwards. Sorry about any confusion. I think my answer would've helped you, if I'd posted it in time. My hope, now, is tha tit may help others with a similar situation, or otherwise offer insight. (But note that it's only about the terminal problem, and not the problem checking for updates.) I suspect that, even after re-editing .bashrc, something in it was still different. diffing it with /etc/skel/.bashrc may help to figure out what, if you feel like investigating. Jun 5, 2020 at 3:50
4

Note: This answer covers the case where the breakage was brought about solely by changes to ~/.bashrc or ~/.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 ~/.bashrc.

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 run 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.

Details follow.

What Happened

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:

alias python3=python3.7

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 python3.7 instead.

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 /bin/bash.

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.

Because .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 exit).

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.

  1. Open your home directory in a graphical file browser window.
  2. 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.)
  3. Rename .bashrc. I suggest changing the name to .bashrc.old.
  4. Open another graphical file browser window or tab and go to /etc/skel.
  5. Drag .bashrc from there to your home directory.
  6. 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.

A Warning

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 python3 command.

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

1
  • thank you for the explanation.
    – nikki
    Jun 5, 2020 at 5:00

You must log in to answer this question.

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