Use of the 'hash' command

Question

I'm working on a small app based on ffmpeg, and I read a tutorial made for ubuntu where they advise to use the command hash on the produced executable.

I'm curious about that command, did you ever use it? For which purpose?

When I run it in my source folder, I get this (once compiled)

$ hash
hits    command
   1    /usr/bin/strip
   1    /usr/local/bin/ffmpeg
   1    /usr/bin/svn
   4    /usr/local/bin/brew
   2    /usr/bin/git
   1    /bin/rm
   1    /bin/cat
   1    /usr/bin/ld
   1    /bin/sh
   4    /usr/bin/man
   5    /usr/bin/make
   4    /usr/bin/otool
  15    /bin/ls
   6    /usr/bin/open
   2    /usr/bin/clear

Looks like a summary of my bash_history…

When I run it on an executable file, I do not have lots of lines displayed, and nothing seems to changes in that application ?

$ md5 ffserver
MD5 (ffserver) = 2beac612e5efd6ee4a827ae0893ee338
$ hash ffserver
$ md5 ffserver
MD5 (ffserver) = 2beac612e5efd6ee4a827ae0893ee338

When I look for the man, it just says it's a builtin function. Really useful :)

It does work (let say exist) on Linux and on MacOSX.

Solution 1

hash isn't actually your history; it is a bash(1) shell built-in that maintains a hash table of recently executed programs:

Bash uses a hash table to remember the full pathnames of executable files (see hash under SHELL BUILTIN COMMANDS below). A full search of the directories in PATH is performed only if the command is not found in the hash table.

(From bash(1).)

The guide your found may have suggested running it just to see which ffmpeg command was going to be executed by the next step; perhaps there is an ffmpeg program supplied by the distribution packaging, and they wanted to make sure the new one would be executed instead of the distro-supplied one if you just typed ffmpeg at the shell.

It seems a stretch, because it would also require having the directory containing the new ffmpeg in the PATH before the distro-provided version, and there's no guarantee of that.

Solution 2

If you use commands that might not be installed on the system, check for their availability and tell the user what's missing. From Scripting with style

Example:

NEEDED_COMMANDS="sed awk lsof who"

missing_counter=0
for needed_command in $NEEDED_COMMANDS; do
  if ! hash "$needed_command" >/dev/null 2>&1; then
    printf "Command not found in PATH: %s\n" "$needed_command" >&2
    ((missing_counter++))
  fi
done

if ((missing_counter > 0)); then
  printf "Minimum %d commands are missing in PATH, aborting" "$missing_counter" >&2
  exit 1
fi

Comments

[Rob]

Cool, thanks... I still don't get why i should use this after a compilation, because i usually do not compile in $PATH.

[sarnold]

@Rob, agreed, it seems strange to me. I think I've needed hash once in the fifteen or sixteen years I've been using Unix or Linux systems, and that might have just been due to my inexperience at the time.

[0 _]

See also unix.stackexchange.com/questions/86012/…

[llogan]

I am the main author of the mentioned tutorial and added the hash command (although it should be hash -d ffmpeg, not the hash -r shotgun approach). It was years ago, but if I recall correctly there was an uncommon corner-case encountered by some users where the distro ffmpeg was being executed instead of the newly compiled ffmpeg despite both being in the PATH. I don't remember the exact details and forgot how to reproduce the behavior (I recall it was easily reproducible), but issuing hash prevented/resolved it. I'll have to take a look at it again.

[sarnold]

@llogan, I still prefer hash -r, since (a) it's less typing (b) re-learning the paths to the other commands isn't actually all that expensive.