Lubuntu Xenial. I seem to have messed up my system perl. cpan returns:

bash: /usr/local/bin/cpan: no such file or directory

(I built a newer perl version from source in that directory, but removed it again).

apt-get install perl --reinstall

seemed to do the right thing but didn't solve the problem. I don't dare to purge perl first and reinstall it, as apt might depend on it.

What can I do?

  • "I built a newer perl version from source in that directory": what directory? Surely you didn't build in /usr/local/bin, right? Also Is it perl that's screwed up or cpan? What happens if you run perl -v or something? What does type -a cpan return? Does sudo dpkg-reconfigure perl help? – terdon Nov 23 '17 at 11:58
  • Welcome to AskUbuntu. Are you sure you don't have something left over from your perl-new-version-play? I have cpan located in /usr/bin/cpan, and nothing related to perl in /usr/local/bin/ (the only stuff in /usr/local/bin/ is stuff I put there) – guiverc Nov 23 '17 at 12:00

TL;DR: Running hash -r or just starting a new shell usually fixes this problem.

If the file is actually gone, then the shell probably just still has it hashed.

First I suggest you verify that /usr/local/bin/cpan really is gone:

ls -l /usr/local/bin/cpan

If there is something there, then you didn't fully uninstall. If there is nothing there, then you will get this message:

ls: cannot access '/usr/local/bin/cpan': No such file or directory

Assuming you got that message, but bash is trying to run /usr/local/bin/cpan when you type in cpan and press Enter, the problem is most likely that bash still has that path hashed. Rather than looking up where external commands are every time, shells typically hash their locations. So you can fix the problem by telling bash to "rehash," by running:

hash -r

Or just start a new shell.

If that doesn't work, check if it's an alias or shell function.

If the file is neither still present nor still hashed, then most likely cpan is an alias or shell function that acts as a wrapper for /usr/local/bin/cpan. To ascertain this, run:

type -a cpan

If it's an alias or shell function, that will show the definition. Then you can unset it with unalias cpan if it's an alias, or unset -f cpan if it's a shell function.

You will ultimately want to remove the definition from whatever startup script contains it. Usually it will be in the .bashrc file in your home directory. Aliases are sometimes defined in .bash_aliases. (Occasionally people define aliases and shell functions in .profile, .bash_profile, or .bash_login, even though this is not a very good practice.)

If that doesn't work, consider how you're running cpan or what shell you're in.

If the file is gone, not still hashed, not an alias or shell function, and type -a doesn't reveal the problem, then most likely you are either (a) not running cpan directly through that command, or (b) using a shell other than bash. In the former case there is no way to answer without further details.

The latter case seems unlikely since your shell calls itself bash, though every once in a while someone ill-advisedly makes a symlink called bash to a shell that isn't (which isn't advisable). The truth is, I'm mainly mentioning this for the benefit of other readers. Based on that message, you're almost certainly using bash.

However, in case you're not or might not be, run echo "$BASH_VERSION" to see if you're running bash--this should be unset in other shells--and echo "$SHELL" to see what your default shell is. Rehashing works differently--or is at least achieved differently--in other shells.

Some other Bourne-style shells, like zsh, have a rehash command that you would run instead of hash -r. That is also how you would cause rehashing to occur in csh and tcsh.

  • Still a problem remaining. While running cpan I get these errors:# Failed test 'failed x86_64-linux-gnu-gcc -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/lib/x86_64-linux-gnu/perl/5.22/CORE -o ccode10 ccode10.c -Wl,-E -fstack-protector-strong -L/usr/local/lib -L/usr/lib/x86_64-linux-gnu/perl/5.22/CORE -lperl -ldl -lm -lpthread -lc -lcrypt 2>/dev/null' # # at t/TestBC.pm line 934. # /usr/bin/ld: cannot find -lperl collect2: error: ld returned 1 exit status # 256 – Kris Van Bruwaene Nov 23 '17 at 13:34
  • This one I solved with [apt-get install libperl-dev --reinstall] – Kris Van Bruwaene Nov 23 '17 at 13:44
  • @KrisVanBruwaene It sounds like your solution may be different enough to be a separate answer. I can't really tell for sure--in particular, error messages are hard to understand when they are scrunched into comments with spacing and line breaks not shown. But I encourage you to considering posting your own answer. The system will even allow you to immediately mark your own answer as the accepted answer, because more than two days have passed since you originally posted the question. – Eliah Kagan Apr 1 '18 at 1:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.