0

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?

MORE INFORMATION, 9/11/2023

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

/Users/jameslampert/Applications
/usr/local/bin
/System/Cryptexes/App/usr/bin
/usr/bin
/bin
/usr/sbin
/sbin

and now "echo $PATH" produces

/opt/homebrew/bin:/opt/homebrew/sbin:/Users/jameslampert/.nvm/versions/node/v16.0.0/bin:/Users/jameslampert/Applications:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin

If I do "which keytool," I get:

/usr/bin/keytool

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

2 Answers 2

3

Certainly.

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

3
  • That was my intention. But the result didn't have that effect. I'm adding some more information to the original question. Commented 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). Commented Sep 11, 2023 at 15:26
  • 1
    It might help to force the shell to rebuilt the command cache after changing the path.
    – nohillside
    Commented Sep 11, 2023 at 17:39
-1

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:

#!/bin/bash
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 $@

Line-by-line:

  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":

#!/bin/bash
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).

1
  • 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. Commented 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 .