Much like unix shells, clhsdb supports recalling commands from the history, and much like unix shells, relies on the '!' character to indicate a history reference. However, it has three bugs that need to be addressed.

The first issue is that !<cmd> matches every <cmd> in the history, not just the most recent occurrence. This makes the history support useless once the command is in the history more than once. Shell history matching only uses the most recent match. clhsdb should do the same.

hsdb> verbose true
hsdb> !ver
verbose true
hsdb> !ver
verbose trueverbose true
Usage: verbose true | false

The second issue is that a '!' anywhere in the command will trigger history matching, but provides no way to disable it with quoting. This becomes problematic when you want to pass an argument that has an '!', which is the case with the new findysm support I'm adding with JDK-8261098. On windows I had to add a '!' to the symbol, and it took me a long time to figure out why the '!' and everything after it seemed to be getting stripped.

hsdb> echo true
hsdb> echo true
+ echo true
hsdb> echo !true
+ echo <-- it tried to match on "true", but didn't find any matches
echo is true
hsdb> echo !echo
+ echo echo echo trueecho true <-- tried to match on "echo" and found some matches
Usage: echo [ true | false ]

It looks like this is supported behavior by unix shells also. The work around in unix shells is to quote the '!' with a '\'. However, clhsdb does not support this. It will need to if we want to allow clhsdb command arguments to contain a '!'.

The 3rd issue is when there is more than one '!' given in the command. Upon processing the second '!' you get an exception:

hsdb> echo one two three
Usage: echo [ true | false ]
hsdb> echo !$ !$
Exception in thread "main" java.lang.StringIndexOutOfBoundsException: begin 7, end 1, length 10

This is due to the following code:

                    if (m.start() > start) {
                        result.append(ln.substring(start, m.start() - start));
                    }

This code is suppose to capture any text that did not match the "historyPattern". So in the above example on the first pass it would capture "echo " and on the second pass just the " ". The problem is that it is subtracting "start" from the 2nd argument, which is suppose to be the end of the range to copy, not the length. This works fine on the first pass since "start" is 0, but on the second pass is causes "end" to be 1 instead of 8.