On Fri, Jul 20, 2007 at 10:16:40AM -0500, will trillich wrote:
> # apt-get install lsof
> Reading package lists... Done
> Building dependency tree... Done
> The following NEW packages will be installed
> lsof
> 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0B/205kB of archives.
> After unpacking 369kB of additional disk space will be used.
> Selecting previously deselected package lsof.
> (Reading database ... 49097 files and directories currently installed.)
> Unpacking lsof (from .../lsof_4.77.dfsg.1-3_i386.deb) ...
> Setting up lsof (4.77.dfsg.1-3) ...
>
> # lsof -i
> bash: /usr/sbin/lsof: No such file or directory
sbin !?
> say what?
>
> # ls -l `which lsof`
> -rwxr-xr-x 1 root root 106324 2006-05-15 18:09 /usr/bin/lsof*
Bash internally maintains a hash table to keep track of where
executables were found - it avoids the (possibly lengthy) search of PATH
when executing common commands. (Look for "hash" in the bash man page
for full info)
Sounds like you executed "lsof" *before* running apt-get - and bash
found lsof under /usr/sbin. Next time you try to execute lsof, bash
remembers its location and is understandably surprised...
Although your problem is resolved now, next time something like this
happens, try clearing out bash's internal hash table:
$ hash -r
before trying the command again.
Hope this helps
--
Karl E. Jorgensen
karl@jorgensen.org.uk http://www.jorgensen.org.uk/
karl@jorgensen.com http://karl.jorgensen.com
==== Today's fortune:
When you're in command, command.
-- Admiral Nimitz
Attachment:
signature.asc
Description: Digital signature