Linux Tips • Page 70 of 111 • Getting you up to speed!

Install The Full Version of Vim In Ubuntu

Today, we’re going to show you how to install the full version of Vim in Ubuntu. Along the way, you may learn a few other things, but the process is simple enough. Even a new user can follow this article – I’d assume. I mean, I could follow it. I think…

Though, I’m not sure that a new user would opt for learning Vim. Either way, some of us will learn something from this article, even if it’s just me learning something from writing it. After all, if I read the headline aloud to you, our conversation might realistically start with this:

“But, KGIII, Ubuntu already comes with Vim installed!” You might say. “You don’t need to install it. D’uh!”

To which I’d respond, “You’d think so, and it appears to, but it actually only comes with a limited version of Vim. Watch, I’ll show you! Then we’ll install the full version of Vim.”

See? It's a small version of Vim. — Check the highlighted line. See? It’s just the small version of Vim. It’s not the full version.

NOTE: We won’t be worrying about a GUI version of Vim. Maybe we can cover that in another article, but you can probably figure that one out on your own.

Now, Vim stands for Vi Improved, with Vi being a really, really old text editor (circa 1976) and Vim is an improvement on it. You’ll see it written as ViM or VIM from time to time, but if you go by the description in the man page, it’s simply “Vim”. Because of that, I’ve decided to spell it that way.

Actually, now that you know the initially installed Vim is just the small version (hint: tiny version), you can probably figure out the rest on your own. I have faith in you, my dear readers. Yes, yes I do… Still, I’ll tell you how, otherwise it’d be a pretty silly article!

Install The Full Version of Vim:

You’re going to want an open terminal for this one. If you don’t know how to open the terminal, you can do so with your keyboard – just press CTRL + ALT + T and your default terminal should open.

With your terminal open, run the following command:

sudo apt remove vim-tiny

1	sudo apt remove vim-tiny

Next, we want to install a full version of Vim. To do that:

sudo apt install vim

1	sudo apt install vim

There are also some GUI versions of Vim that may be in your default repositories. You can opt to install those, but we’ll not be covering those in this article. This article is just about how to install the full version of Vim.

Hmm… Well, that’s really all there is to it. I suppose you could string the commands together, all nice and fancy like…

sudo apt remove vim-tiny -y && sudo apt install vim -y

1	sudo apt remove vim-tiny -y && sudo apt install vim -y

Yeah… So, really, that’s all there is to this. However, the important thing is that most folks don’t realize that it’s not the full version of Vim that has been installed by default. It’s just the tiny version, which is lacking in features. If you want, you can verify the currently installed version of Vim with this command:

vim --version

1	vim --version

Assuming you’ve installed the full version of Vim, the output will look similar to:

The output shows that this is the full version of Vim. — Again, check the highlighted line to see the difference. As you see, it’s the full version. Sweet!

Closure:

Well, there you have it. You now know that Ubuntu’s initially installed version of Vim is just the tiny version of Vim. You also now know how to install the full version of Vim in Ubuntu. If you’re a fan of Vim, or would like to start learning Vim, this is probably a good thing to know.

Thanks for reading! If you want to help, or if the site has helped you, you can donate, register to help, write an article, or buy inexpensive hosting to start your own site. If you scroll down, you can sign up for the newsletter, vote for the article, and comment.

How To: Completely Remove Software In Ubuntu

Today’s article is going to show you how to completely remove software in Ubuntu. This will also work for other distros that use apt as their package manager. It’s a pretty handy tool to have in your toollbox, because we’ll not only be removing software, we’ll also be removing any config files associated with said software. It’s not all that difficult, and anyone should be able to understand this article.

When you ‘remove’ software, be it with the GUI or with the terminal, you’re actually only removing the software itself. You’re often leaving behind the config files (if there are any) and the ‘remove’ may leave dependencies still installed. The reasoning for leaving config files behind is presumably so that you can reinstall the software and have the same configurations you had earlier in time.

As you can guess, that’s not always a good thing… It may well be those configuration files that caused some sort of error in the first place. It may well be those config files that prompted you to remove the software in the first place. Erasing and starting anew might be your only realistic path forward, especially if reverting to backups did not work.

So… That’s why we have this article. This article is going to teach you how to completely remove software in Ubuntu. If you want, you can still try removing software and reinstalling (as a troubleshooting step), and this then becomes one of your later troubleshooting strategies. Read on, and you’ll see…

Completely Remove Software In Ubuntu:

This article requires an open terminal, like many other articles on this site. If you don’t know how to open the terminal, you can do so with your keyboard – just press CTRL + ALT + T and your default terminal should open.

When you remove software with the terminal, you probably do it like so:

sudo apt remove <application>

1	sudo apt remove <application>

That’s great. It removes the application and may even remove some of the dependencies it pulled in when you installed it. This is not necessarily a bad thing – but we want to completely remove software in Ubuntu, and this is how you do it.

As I said in the preamble, using the above command will likely leave your configuration files behind (if there are any) and some dependencies. With the ‘purge’ command, you’ll get rid of those configuration files. To do this, you’ll want to:

sudo apt purge <application>

1	sudo apt purge <application>

While that’s great and all, when you installed your application you may well have installed some other applications (dependencies), that is some applications that the software depended on. Those too may have config files related with them and to really ensure you’ve completely removed the software, you’ll want to do an autoremove.

If you’re unfamiliar with the autoremove function of apt, the man page has it summed up nicely:

autoremove is used to remove packages that were automatically installed to satisfy dependencies for other packages and are now no longer needed as dependencies changed or the package(s) needing them were removed in the meantime.

You don’t specify an application with the ‘autoremove’ command, you just run:

sudo apt autoremove

1	sudo apt autoremove

That should do it, actually. The last command should remove any dependencies that were installed and not removed automatically when you purged the software with the commands above.

Closure:

And there you have it! It’s another article! I still haven’t missed a day, and I’m well beyond my initial obligations. This time, the article tells you how to completely remove software in Ubuntu – and it’ll work in any distro that uses apt. It’s a pretty simple thing, but it’s worth knowing. Eventually, it’s bound to come in handy.

How To: Add A PPA To Ubuntu

In this article, we’re going to discuss how to add a PPA to Ubuntu. A PPA is a Personal Package Archive, but we’ve come to use them much differently than they were ever intended. So, you might as well learn how to do this. You might as well learn how to add a PPA to Ubuntu.

Yes, we use PPAs in ways never intended. They are meant to be your own personal archive of packages. not a way of disseminating software to the masses. We’ve turned PPAs into a tool to widely distribute software more easily. If you want a piece of software that’s not in the official repositories, you do a quick search, add a PPA, update, and install your software! It’s how we’ve always done things! (Hint: No, it’s not how we’ve always done things.)

This is one of the main reasons Snap apps were created and why they are being pushed. During this time, people could also have used AppImages and Flatpaks, and some of us did.

Me? I’m among the worst of offenders. As it is, I still only use Snaps that came installed by default. I still reach for a PPA (when available) and install things in the ‘traditional’ manner. Well, it’s hardly traditional and it’s generally a bad idea.

In fact. let me sum up why it’s a bad idea with just one sentence…

When you add a PPA, you’re giving the PPA maintainer root-level access to your computer.

All they gotta do is push an update and you’ll have installed it with your next upgrade. No, don’t pretend you’re going to read the source and verify the integrity. You’re going to do it, just like you wanted to …

Add A PPA To Ubuntu:

Alright, let’s paint a simple picture:

There’s some software you want, but you can’t find it in your repositories and the GitHub page doesn’t release packaged binaries. You don’t want to have to deal with building it every time there’s a new version, so you take to the ‘nets in search of a fix.

Your first stop is at Launchpad.net to search for the application. You got lucky and found a PPA. In fact, you found a few of them. In this case, you want to look for the one who has most consistently published upgrades. First, you have to enable Ubuntu’s ‘universe’ PPA, which may already be enabled. If it isn’t, the command to run is:

sudo apt-add-repository universe

1	sudo apt-add-repository universe

When you find the proper repository’s name, you can add it with this command:

sudo add-apt-repository ppa:user/archive

1	sudo add-apt-repository ppa:user/archive

An example of that could be sudo add-apt-repository ppa:mozillateam/ppa. You could use that to use the more traditional Firefox.

No matter… Once you’ve done all this, you might still need to update your own local software database with this command:

sudo apt update

1	sudo apt update

There you have it. You can now add a PPA to Ubuntu. You can now use the software included in the newly added PPA. Modern/current Ubuntu flavors will run the apt update automatically, but older versions will still need to trigger the update manually.

BONUS: You can more easily remove the PPA through the GUI, but you can also do so in the terminal, it’s just the –remove flag, like this;

sudo add-apt-repository --remove ppa:user/archive

1	sudo add-apt-repository --remove ppa:user/archive

See? You can now do both. You can add a PPA to Ubuntu or you can remove a PPA from Ubuntu.

Closure:

Ah well… You can now add a PPA to Ubuntu. Removing a PPA is also now something you can do, assuming you didn’t already do so. On top of that, adding PPAs willy-nilly as you’re essentially giving that PPA’s owner a key to your entire computer.

Check Your SSH Server Configuration

Today, I’m going to show you how to check your SSH server configuration. It’s a simple process, but not one many people seem to know about. It’s also a pretty handy tool if you’re having SSH issues. Once again, this one isn’t all that complicated, I think… Read on!

So, why would you want to check your SSH server configuration?

Your SSH server might not be working. You may have made some changes and want to test it before moving it to production. An upgrade to the SSH application may have made some of the options different or even removed the options entirely.

There are all sorts of reasons why you’d want to check your SSH server configuration. Those are just a few of them. Not only will the article show you how to check your SSH configuration files – it’ll show you how to test alternative configurations. So, you can test your changes before making them – potentially saving you a physical trip to the server.

Check Your SSH Server Configuration:

By the way, I would test/learn this on a local system. You’re potentially going to break things. In fact, let’s start by breaking them! Well, let’s create a backup first, and then we’ll break stuff.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

1	sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Okay. Now let’s break something! Run this command:

sudo nano /etc/ssh/sshd_config

1	sudo nano /etc/ssh/sshd_config

Find a line that has a command and doesn’t start with a #. You can also remove the # from an option and it’ll be work. Find a one line option that has a “no” option field and change it to “oh_no” *sans quotes, though that probably won’t matter) and then save the file.

(Also, to save the file in nano, press CTRL + X, then Y, and then ENTER and that should do it.)

Now, let’s check that SSH server configuration with the following command:

sudo sshd -t

1	sudo sshd -t

If things go according to plan, it will tell you that you have an error. On top of that, it will tell you on which line you have the error. If it doesn’t throw an error, it means your configuration is fine – or that you may need to restart your SSH service for it to see the new configuration.

If you do somehow need to restart SSH server (you shouldn’t have to), restart it with the following command:

sudo systemctl restart ssh

1	sudo systemctl restart ssh

Run the command again and that should definitely show the error, which you can easily fix by simply undoing what you did in the steps above and saving it. You almost certainly shouldn’t need to restart SSH to show the error, though you may want to restart it after you’re done playing around in the config file. Of course, if you did have to restart the SSH server, you’ll need to do so again after fixing the error you intentionally introduced.

BONUS: If you want, you can list the path and check a configuration file that’s not actually in use. So, you can check the configuration file before putting it into production. That’s just:

sudo sshd -t /path/to/new_config

1	sudo sshd -t /path/to/new_config

Again, under normal circumstances, it won’t show any output if it finds no errors. It only outputs information if there’s actually an error. So, a null response is considered normal and good.

Closure:

See? Nice and easy. Now you can check your SSH server configuration for errors – even doing so before putting the config into production. It’s a pretty handy tool to have. Also, you’ll need SSH installed and running on the machine you’ll be testing with. I figure that’s obvious, but I better mention it somewhere or someone will point it out or ask about it. Then again, people seldom read this far down in an article.

How To: Check A Disk For Errors

In today’s article, we’re going to learn how to check a disk for errors. We’ll be using a multi-pronged process to thoroughly check a disk for errors in the Linux terminal. By itself, none of these are particularly complicated. As such, I expect this to be a relatively easy article to follow.

If you’ve been seeing errors when transferring data to a disk, it’s probably a good sign that it’s time to check that disk for errors. You may also want to check a disk for errors if you’ve not used it before – like if it is used or if you have just purchased it.

To perform these tests, the disk must not be mounted! If need be, you’ll have to do these tests from a live environment. That’s easy enough. Remember how you installed Linux? Well, that same installation media is (usually) the same media you’ll need to enter a live environment. You will, of course, need to boot to the media when you start your system – be it USB, or CD, or DVD. It’s much the same as though you were going to install Linux – except you don’t opt to do the installation – you just work in the live environment.

Anyhow, we’ll be using a few tools for this. All of these tools will almost certainly be available by default. If they’re not, ummm… Well, if they’re not, pick a different distro’s live environment to use, or install them yourself! These tools are all on the installation media for distros in the Ubuntu family, for example. So, yeah, find a distro where they are available – which should be pretty much all of them.

Check A Disk For Errors:

So, you’re booted to a live instance of your favorite distro (or the disk you’re going to check is unmounted) and you’re ready to start testing. Well, you need an open terminal. If you don’t know how to open the terminal, you can do so with your keyboard – just press CTRL + ALT + T and your default terminal should open.

Once you have your terminal open, use lsblk to identify the disk you wish to check for errors. For the purposes of this exercise, we’re going to assume the disk you’re checking for errors is known as ‘sda’. Be sure to change that to suit your particular needs.

First, let’s check for S.M.A.R.T. errors (which we’ve previously covered in-depth). You can do so with this command:

sudo smartctl -H /dev/sda

1	sudo smartctl -H /dev/sda

Next, let’s check for bad blocks. Bad blocks are physical points on your device that no longer work properly. Some bad blocks isn’t, necessarily, indicative of immediate disk failure. Some bad blocks may be normal. Still, let’s check it.

If you’re really into this, you’ll want to check it for bad blocks – and then check it again soon after. That will let you know if the number of bad blocks is increasing. If the number is rapidly increasing, disk failure will likely soon follow. Otherwise, you’re probably okay for the time being.

sudo badblocks -v /dev/sda

1	sudo badblocks -v /dev/sda

Finally, let’s check for file-system consistency. This is typically done with the ‘fsck’ command, a command you should have some understanding of. There are many ways to run the command, but you can just use the following command to see what’s going on:

sudo fsck /dev/sda

1	sudo fsck /dev/sda

Now, you’ve run three tests. Between them all, you should have a pretty good understanding of your disk’s health and you’ll know how to check a disk for errors. Again, you’ll want to check a disk for errors when the situation dictates – especially if you’re getting disk errors while in the operating system.

When you get disk errors, it’s time to consider retiring the drive. Depending on the severity of the errors, you might wish to stop using the drive immediately, creating an image of the drive, and retiring the drive from your system. Disk failures happen and recovering data from a failed drive can be a major hassle. So, use these warnings as a reason to consider replacing your drives if drive failure is in the cards.

Closure:

And there you have it! You now know how to check a disk for errors! It’s a handy skill to have. After all, disks fail. Knowing when they are going to fail is a good thing. Being prepared for disk failure is a bonus and a good idea! It’s also worth checking new disks. I’ve tested new disks and had unsatisfactory results that meant I returned the disk to the retailer, so it’s a concern and worth taking the time to test.