I would print Aborted! in yellow because it's not necessarily an error. And the summary line should use the regular color coding (green if no spec failed).

To fix the exit status, I think #5413 should do the trick.

Actually the finish handler does not run on this code:

require "spec"

at_exit { exit }

puts "start"
it "never ends" do
  loop { sleep 1 }
end

I believe #5413 fixes this.

@straight-shoota I can accept that Abort! prints with yellow (but I don't think yellow is better than red, so I'll keep it for now.) However I disagree about the latter part. A success of specs means that all specs are succeeded.

Success means that all the specs that were run passed. You can limit the specs to run so spec or spec group using the command line arguments. According to your logic, these shouldn't ever be green either because not all specs are run.
I understand limiting the execution of specs beforehand and aborting the spec run manually with Ctrl+C to be very similar. I usually hit Ctrl+C when I know all the specs I'm really interested have already run and I don't want to wait for the the test to execute. Then I'd want to see a proper results summary which don't just scream red error everytime - because there's no error, aborting a spec using Ctrl+C is intentional behaviour by the user.

Either way, it would be great if the summary also showed the number of specs that were not run due to aborting the run.

@straight-shoota I wrote all expected specs at first but it was bother to explain what is expected spec, so I reworded this to all specs. However it is small thing.

At least one spec is not succeeded on pressed Ctrl-C in many cases.

require "spec"

it "heavy_process" do
  puts "begin"
  heavy_process!
  puts "end"
end

On the above example, you press Ctrl-C between printing "begin" and "end", then the spec of heavy_process is interrupted by Ctrl-C. I think such cases are often appeared in the real world because a span between two specs is short, but a time running a spec is long.

I assume a spec is interrupted on Ctrl-C always. Of course it is not true, and it is better if the "spec" library handles this correctly. But it needs more changes and the benefit of this improvement is little. I'd like to keep the change of this PR small and simple.

Either way, it would be great if the summary also showed the number of specs that were not run due to aborting the run.

It sounds good! But unfortunately, it is impossible for the current implementation because it cannot get the number of all specs before finished.

I don't get it why aborting the run while a spec is being executed should pose a problem. Just treat that spec as aborted like all the following ones. Doesn't matter if it has already begun.

Yeah, I see, that list is gonna require more effort and that's really too much for this PR.

This covers the original issue and good to merge as it's 👍