sudo apt-get install --reinstall wget will replace any deleted files.
When the bash shell's default command-not-found handler in Ubuntu--which is what displayed the message you saw when you tried to run wget--tells you that a program isn't installed, but the package that it says provides it is installed, this usually means that the file was deleted. In that case, you can reinstall the package, and the file will be replaced.
Just running the command that it tells you to run won't do that, because if reinstallation of already-installed packages were perfomed by default when you use apt install or apt-get install, then users would constantly be reintalling things they didn't mean to reinstall.
To reinstall a package, pass the --reinstall flag as well. In your case, for the wget package:
sudo apt-get --install reinstall wget
The apt command also accepts this syntax, i.e., you can replace apt-get with apt in that command, in Ubuntu 14.04 LTS and later, though that command still works fine. (It's fine to use apt-get, even on systems that have the apt command, too.)
The alternative of removing and then reinstalling wget in two separate steps is inadvisable, because if you remove wget with the remove or purge action, then any packages that depend on it will also be removed. Those packages are not automatically reinstalled when you subsequently install wget (though if you explicitly install them, then the wget package gets installed if it wasn't already, assuming the package manager knows it was missing).
For information about how to investigate such problems, and other possible causes, see below. What follows is secondary and not needed in most cases.
If you want to check first...
As described above, a missing file is the most common cause of the problem, but there are other causes that reinstalling the package can also solve--see below--so I suggest simply proceeding to do so. However, if you feel like checking if the file has been deleted, then you can run:
ls -l /usr/bin/wget
In general, if you don't know what file should be providing the command, you can run dpkg -S wget to see a list of files provided directly by any package that have wget in their names, or (as waltinator suggested) dkpg -L wget to list all files that the wget package directly provides. However, I suggest instead using https://packages.ubuntu.com/ to look it up, since the interface is easy to use and it will give you the right answer even if your system's package manager turns out to be broken or misconfigured.
See also How do I find the package that provides a file?
This is not likely to be caused by a PATH problem.
There are other possible causes, but in my experience they are much less common. In particular, if your PATH is set incorrectly, that will usually not cause the command-not-found handler to suggest installing a package:
ek@Kip:~$ nonexistent-command
nonexistent-command: command not found
ek@Kip:~$ curl
The program 'curl' is currently not installed. You can install it by typing:
sudo apt-get install curl
ek@Kip:~$ wget
wget: missing URL
Usage: wget [OPTION]... [URL]...
Try `wget --help' for more options.
ek@Kip:~$ PATH=
ek@Kip:~$ nonexistent-command
bash: nonexistent-command: No such file or directory
ek@Kip:~$ curl
bash: curl: No such file or directory
ek@Kip:~$ wget
bash: wget: No such file or directory
Another possible cause is a deleted symlink used by the alternatives system.
A more plausible cause for this kind of problem--besides the file being deleted as described above--would be if the alternatives system maintained the command as a symbolic link to an executable, and the symbolic link itself had been deleted, while the actual executable remained.
In that situation, you wouldn't have to reinstall the package--but reinstalling still typically would fix it, because it would usually set up the newly installed command as the default by remaking the symbolic link and having it point to the executable that was installed.
Furthermore, wget in Ubuntu is not managed by the alternatives system because there is only one implementation of wget in Ubuntu's repositories. So this is not the cause of the situation described specifically in the question here, though it is occasionally the cause of problems that manifest similarly.
dpkg --get-selections | grep "wget"– heemayl Feb 06 '15 at 01:53