I need, when generating Java keystores (which I do frequently), to generate them under the Java 8 version of Keytool. If I use the keytool in the default Java version, they are incompatible with the Java on the target systems we manage.

I've figured out a way to do this, with a wrapper shell script (currently called "keytool8"). And that shell script echoes a message indicating that it's using the Java 8 keytool, before handing off to that keytool.

And I have the shell script in a directory that's in my path.

But if I rename it to "keytool," and type "keytool" from a command line, I still get the default keytool.

Is there a way for my shell script to preempt the default keytool?


I added "/Users/jameslampert/Applications" (the directory where I put my script) to my /etc/paths, so that it now looks like:


and now "echo $PATH" produces


If I do "which keytool," I get:


Somehow, the default keytool is preempting me, even though /usr/bin is theoretically after /Users/jameslampert/Applications in the path.

2 Answers 2



Put the shell script in a directory that appears in your path before the keytool binary you are trying to preempt.

  • That was my intention. But the result didn't have that effect. I'm adding some more information to the original question. Sep 11, 2023 at 15:12
  • Hmm. Now it's behaving very differently from what it was doing yesterday: now it is preempting (but not quite right yet). Sep 11, 2023 at 15:26
  • 1
    It might help to force the shell to rebuilt the command cache after changing the path.
    – nohillside
    Sep 11, 2023 at 17:39

Thanks, Mr. Wilson. It wasn't preempting yesterday, but it is today (but so aggressively that it was going into a recursive tightloop). Once I fixed that, it seems to be working quite well (knock on wood).

Here is how my script ended up looking:

export JAVA_HOME='/Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home'
echo -e "\033[0;31m*** USING JAVA 8 KEYTOOL ***\033[0m"
/Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/bin/keytool $@


  1. A few months ago, I learned the hard way what can happen with a "generic shebang," so I've been making a point of using an explicit one ever since.
  2. Temporarily change the JAVA_HOME for the duration of the script.
  3. Put up a message, in red, to indicate that the Java 8 keytool is in use
  4. Explicitly invoke the Java 8 keytool, using the fully qualified path to avoid the recursive tightloop.

And just in case I ever actually need an easy way to use the default keytool, I've added a complementary wrapper, "keytool-default":

echo -e "\033[0;31m*** USING DEFAULT KEYTOOL ***\033[0m"
/usr/bin/keytool $@

I'm giving Mr. Wilson the "Accepted" checkmark, because he pointed me in the right direction, and led me to question yesterday's findings (which were in a fresh terminal window, but not a reboot).

  • I tested keystores created using both scripts, on a Midrange box running V6R1, which is barely compatible with Java 8 keystores and definitely incompatible with Java 17 keystores; the two keystores I created behaved as predicted. Sep 11, 2023 at 17:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .