Accidentally pasting a "julia>" command leaves julia in a broken state

[KristofferC]

I realize this is not strictly a bug due to being able to define new comparison operators with infix notation but it is a bit unfortunate:

julia> julia> A = 2 # Accidentally included the `julia>` from pasting code, REPL is now hosed
WARNING: module Main should explicitly import > from Base
WARNING: Method definition >(Any, Any) in module Base at operators.jl:40 overwritten in module Main at REPL[1]:1.
> (generic function with 2 methods)

julia> "foo" > 3 # Wut?
2

# Let's try to exit this demon REPL
julia> {Ctrl + D} WARNING: Caught an exception in the keymap:
ERROR: TypeError: non-boolean (Int64) used in boolean context
# Nope!

julia> >1,2
ERROR: syntax: ">" is not a unary operatorSYSTEM: show(lasterr) caused an error

Feel free to close if this is considered a non issue.

[tkelman]

ref #15483 - I wouldn't miss it if we disallowed lvalue infix assignment.

[StefanKarpinski]

Yikes, that's unfortunate. I've considered in the past automatically detecting leading julia> and then stripping the indent from the following lines so so that you can just paste REPL transcripts back into the REPL and have them work. Not sure that's a good idea though and of course it doesn't help other REPL modes unless we handle them too (and switch to the named REPL mode automatically?).

[mschauer]

julia could well be a reserved word (then pasting julia> can be a "unhandled reserved word" error for now)

[GunnarFarneback]

For what it's worth Julia 0.4 behaves differently.

julia> julia> A = 2
ERROR: syntax: invalid assignment location

In case someone missed it, a workaround for the broken Ctrl+D is to run exit().

[JeffBezanson]

That was because of the different parsing of comparison operators.