Question

I have the following code in my ~/.bashrc:

date=$(which date)
date() {
  if [[ $1 == -R || $1 == --rfc-822 ]]; then
    # Output RFC-822 compliant date string.
    # e.g. Wed, 16 Dec 2009 15:18:11 +0100
    $date | sed "s/[^ ][^ ]*$/$($date +%z)/"
  else
    $date "$@"
  fi
}

This works fine, as far as I can tell. Is there a reason to avoid having a variable and a function with the same name?

Answer 1

It’s alright apart from being confusing. Besides, they are not the same:

$ date=/bin/ls
$ type date 
date is hashed (/bin/date)
$ type $date 
/bin/ls is /bin/ls
$ moo=foo
$ type $moo 
-bash: type: foo: not found
$ function date() { true; }
$ type date 
date is a function
date () 
{ 
true*emphasized text*
}

$ which true 
/bin/true
$ type true
true is a shell builtin

Whenever you type a command, bash looks in three different places to find that command. The priority is as follows:

1. shell builtins (help)
2. • shell aliases (help alias)
   • shell functions (help function)
3. hashed binaries files from $PATH (‘leftmost’ folders scanned first)

Variables are prefixed with a dollar sign, which makes them different from all of the above. To compare to your example: $date and date are not the same thing. So It’s not really possible to have the same name for a variable and a function because they have different “namespaces”.

You may find this somewhat confusing, but many scripts define “method variables” at the top of the file. e.g.

SED=/bin/sed
AWK=/usr/bin/awk
GREP/usr/local/gnu/bin/grep

The common thing to do is type the variable names in capitals. This is useful for two purposes (apart from being less confusing):

1. There is no $PATH
2. Checking that all “dependencies” are runnable

You can’t really check like this:

if [ "`which binary`" ]; then echo it\'s ok to continue.. ;fi

Because which will give you an error if binary has not yet been hashed (found in a path folder).