Re: Obscure zsh history overflow with segfault

[Bart Schaefer <schaefer@brasslantern.com>]

On Jan 21,  4:39am, Daniel Shahaf wrote:
}
} Apparently, 'r 100 foo' should re-execute the portion of your history
} from event #100 to event 'foo'.
} 
} Sounds like a bad idea...

Interesting.  Here we are:

1516                /*
1517                 * Nasty behaviour results if we use the current history
1518                 * line here.  Treat it as if it doesn't exist, unless
1519                 * that gives us an empty range.
1520                 */
1521                if (last >= curhist) {
1522                    last = curhist - 1;
1523                    if (first > last) {
1524                        unqueue_signals();
1525                        zwarnnam("fc",
1526                          "current history line would recurse endlessly, aborted");
1527                        fclose(out);
1528                        unlink(fil);
1529                        return 1;
1530                    }
1531                }

In the situation in this bug, first > last is true but last >= curhist
is false.  I believe that means that even though this is an infinite
loop, we don't detect that it will be.

However, it's worse than that:  If HIST_NO_STORE is not set, then even
when last < curhist and first <= last, its possible for the history to
contain an "r" command, which will be executed, retrieving a history
that contains an "r" command, which ...

One possible approach is for bin_fc to refuse to recursively run the
"r" command (same for "fc -e -").  However, it's then still possible
for the user to shoot himself with "fc -e cat ..." (or any other no-op
editor command); so short of disallowing any sort of recursive entry
into "fc" when -l is not given, this probably has to be treated as a
user error.