There are two changes in this patch:
1. Loading the history, the code used
while (!infile.eof()) {
getline(infile, ...);
...
}
That's simply wrong, because it will read one superfluous empty line at the
end. You need to check if reading succeeded instead of checking if the stream
already encountered EOF.
2. Writing back the history, the code tried to skip elements until it found
the current one, then write the rest and then finally the current command.
This avoids writing the beginning of the file, but firstly it doesn't work,
and secondly it is IMHO a completely unnecessary optimization because a) it
isn't called often enough and b) the file is <1kB here after years of use. I'm
using the most simple implementation and just write the whole history every
time, skipping all duplicates and finally append the current command.
There was one thing I'm not sure how the code was supposed to work and which
wasn't documented either. The question is how editing of previously entered
commands is reflected in the history. There are two approaches:
1. If I enter "xter" (if I pressed enter too early), going back in history and
then appending the "m", it replaces the "xter" with "xterm" in history.
2. If I enter "xter", going back in history and appending the "m" yields two
entries "xter" and "xterm".
I chose approach 1 in the patch. However, that means that if a user wants to
have two entries like "xterm sh" and "xterm bash", they can't achieve that by
just editing the history, they must enter them completely separately instead.
If you don't like that, just skip the code leading to the second "continue" in
the look that writes the history. ;)
Cheers!
Uli