%rerun prevents lines containing "rerun" from being rerun

[illright]

Yeah, that's a lot of "rerun" in the title :p

Steps to reproduce

• Execute a = 0
• Execute a += 1
• Execute %rerun -g a
• Execute %rerun -g rerun

Expected result

Both calls to %rerun work, variable a holds the value of 3.

Actual result

The last rerun is prevented because the command contains the 'rerun' substring. The following unhelpful error message is printed:

No lines in history match specification

System info

Manjaro Linux, Python 3.9.4, IPython 7.22.0 (reproduces on IPython 8.0.0.dev)

[MrMino]

I'm not sure whether we'd actually like the %rerun lines to be %rerunable (:laughing: could this be any more meta...).

re.search(a, b)
%rerun -g re
a = "something different"
b += "xxx"
%rerun -l 1
%rerun -g re   # would run the line above instead of the re.search.

[illright]

Well, I personally think it's up to the user to work around this. The whole "rerun by pattern match" mechanism looks awfully untrustworthy to me and I would personally much rather rerun by cell index and only use the pattern feature with very explicit and unique patterns.

Having said that, I think that introducing a restriction on "rerun" makes the fragile thing confusing as well (seeing as this behaviour is not documented). Moreover, the way it's done right now is very sloppy and lines containing innocent things like barerun or rerun_count would also be prevented from being rerun.

[MrMino]

Still, that would be a breaking change. Not sure if it is a good idea to implement it within the scope of your #12950 tests.

Remember that if you %rerun a %rerun (*sigh*), it currently core dumps the whole interpreter.

In [1]: a = 1      
                   
In [2]: %rerun -l 1
=== Executing: === 
a = 1              
=== Output: ===    
                   
In [3]: %rerun -l 1

...

  File "<decorator-gen-62>", line 2 in rerun 
  ...                                        
[1]    519861 abort (core dumped)  ipython