IS NOT FOUND

DESCRIPTION
===========
If script mysqld_multi and utility my_print_defaults are in
the same folder (not included in $PATH) and the former is
made to run, it complaints that the mysqld binary is absent
eventhough the binary exists.

ANALYSIS
========
We've a subroutine my_which() mimicking the behaviour of
POSIX "which" command. Its current behaviour is to check
for a given argument as follows:
- Step 1: Assume the argument to be a command having full
fledged absolute path. If it exists "as-is", return the
argument (which will be pathname), else proceed to Step 2.
- Step 2: Assume the argument to be a plain command with no
aboslute path. Try locating it in all of the paths
(mentioned in $PATH) one by one. If found return the
pathname. If found nowhere, return NULL.

Currently when my_which(my_print_defaults) is called, it
returns from Step 1 (since utlity exists in current
folder) and doesn't proceed to Step 2. This is wrong since
the returned value is same as the argument i.e.
'my_print_default' which defies the purpose of this
subroutine whose job is to return a pathname either in Step
1 or Step 2.

Later when the utility is executed in subroutine
defaults_for_group(), it evaluates to NULL and returns the
same. This is because the plain command 'my_print_defaults
{options} ...' would execute properly only if
my_print_defaults exists in one of the paths (in $PATH). In
such a case, in the course of the flow it looks onto the
variable $mysqld_found which comes out to be NULL and
hence ethe error.

In this case, call to my_which should fail resulting in
script being aborted and thus avoiding this mess.

FIX
===
This utility my_print_defaults should be tested only in
Step 2 since it does not have an absolute path. Thus added
a condition in Step 1 so that is gets executed iff not
called for my_print_defaults thus bypassing it to proceed
to Step 2 where the check is made for various paths (in
$PATH)