julia.exe isinteractive() always true in startup.jl. 1.8.0-rc1 - Windows 10 - prebuild portable (bug)

[ylvain]

The binary julia.exe as found in the prebuilt portable release 1.8.0-rc1 ignore the command line option -i

In startup.jl and the REPL isinteractive() is always true, whether or not -i is passed.

[Seelengrab]

[sukera@tempman julia]$ julia -q -e 'println(isinteractive())'
false

[sukera@tempman julia]$ julia -q -e 'println(isinteractive())' -i
true
julia>  # REPL starts

-i influences what happens when you either run julia like julia file.jl on some file, or you pass it some code to execute directly. Just launching julia will always start the REPL by default.

[ylvain]

Yeah I know that :) there is a problem, but I misdiagnosed it, sorry! The breaking change is:

• On all versions that I've used prior to 1.8.0-rc1, startup.jl is executed in the same context as the expression passed by argument -e, that is before the REPL starts and isinteractive() becomes true whether or not the -i option was passed.
• On 1.8.0.-rc1, startup.jl is executed in the REPL context. So isinteractive() now returns true whether or not -i is passed.

I've edited the title the reflect the root cause. Here is a a repro, both shell session on the same host.

Exemple with 1.7.3, portable pre-built distribution, windows 10, git-for-windows bash shell

$ pwd
/c/julia/bin/julia-1.7.3/bin

$ cat ~/.julia/config/startup.jl
println("startup.jl: ", VERSION,' ',isinteractive())

$ ./julia.exe -q
startup.jl: 1.7.3 false
julia>

$ ./julia.exe -q -i
startup.jl: 1.7.3 true
julia>

$ ./julia.exe --startup-file=no -q -e "println(VERSION,' ',isinteractive()); exit()"
1.7.3 false

$ ./julia.exe --startup-file=no -q -i -e "println(VERSION,' ',isinteractive()); exit()"
1.7.3 true

Exemple with 1.8.0-rc1, portable pre-built distribution, windows 10, git-for-windows bash shell

$ pwd
/c/julia/bin/julia-1.8.0-rc1/bin

$ cat ~/.julia/config/startup.jl
println("startup.jl: ", VERSION,' ',isinteractive())

$  ./julia.exe -q
startup.jl: 1.8.0-rc1 true
julia>

$  ./julia.exe -q -i
startup.jl: 1.8.0-rc1 true
julia>

$ ./julia.exe --startup-file=no -q -e "println(VERSION,' ',isinteractive()); exit()"
1.8.0-rc1 false

$ ./julia.exe --startup-file=no -q -i -e "println(VERSION,' ',isinteractive()); exit()"
1.8.0-rc1 true

[Seelengrab]

Ah, I see what you mean. I think that's more consistent, to be honest. With julia -q and no passed file you will by default always end up in the REPL, so it makes sense that startup.jl should also see that isinteractive() is true. It's not that startup.jl moves from "non-REPL context" to "REPL context" with -i, but that startup.jl should have the exact same environment as later code execution does. Semantically, I think it should be no different than having julia -L startup.jl, just without having it specified explicitly.

[ylvain]

TL;DR
I respectfully disagree. 😄 I vote for

• restoring the behavior of all versions before 1.8
• and changing/clarifying the doc of isinteractive() to "return true if julia is running an interactive session or if -i was passed to julia".

(edited for clarification, also, I consider using -e / -E as equivalent to passing a programfile argument.)

---

Hum... it remains a breaking change and should imho be documented as such... but I also see what you mean 😄 I had to think quite a bit about it, much more than I wanted to 😆... This is the kind of "silly" question that's more subtle that it seems...

The specs of -i is clear, per the command line doc, and there is no change between version here.

The issue depends on how you interpret the absence of -i. If -e / -E is present, the specs is also clear, and again there's no change in this case. The important point here is that the presence of -e / -E is (afaik) the only case in which you can tell that you will not end up in the REPL (in general, the code of -e could start a REPL or some user-level equivalent interactive feature before exiting). Loading file either as startup or by -L will end up in the REPL if the code did not exit before.

The relevant case is when there is no -i and no -e.

1. Before 1.8, the absence of -i was interpreted as "no interactive use required" so isinteractive() is false
2. From 1.8, the absence of both -i and -e is interpreted as "interactive use will happen" so isinteractive() is true

So

1. either you define isinteractive() as testing whether the REPL will/is used,
2. or you define it as whether -i was given to the process

The current doc of isinteractive() is unclear (imho) because the "interactive session" could be handled (or aborted) by any code. Beside, as indicated above, definition 1) cannot be reliably implemented. You have no way to know if you will end up in the REPL...

So, yeah, it can be argued that the behavior of 1.8 is more coherent. But I think the behavior of <1.8 is more useful: it provides a way to pass an argument to all codes that

• indicates whether an interactive use is intended (in julia you cannot hope for more than intention)
• is given in as switch, instead of an args (as per julia [switches] -- [programfile] [args...]), easier for script/alias.

my small use case

I use startup.jl to setup my environment both for quick command line testing and for interactive session. So I load Revise/OhMyREPL etc. from startup.jl but only if isinteractive() is true. Currently my scripts (non -i) on 1.8.0-rc1 do load all the "interactive use related" code and thus start much more slowly.

E.g. I use aliases like alias jl='current-julia -q -i -t auto' and jr='current-julia -q -t auto'. I'll then use jr either to run a file or to get a fast clean/minimal REPL, whereas jl is for the 'slow' session.

[KristofferC]

Anyone know what caused the change?

[Seelengrab]

The important point here is that the presence of -e / -E is (afaik) the only case in which you can tell that you will not end up in the REPL (in general, the code of -e could start a REPL or some user-level equivalent interactive feature before exiting). Loading file either as startup or by -L will end up in the REPL if the code did not exit before.

As I've shown above, at least julia myfile.jl does not end up in the REPL, nor should it without an explicit -i flag. It also doesn't have isinteractive() == true.

There are, in general, a few distinct behaviors:

• Run/Load some code before "main execution" starts (the -L flag)
• Execute a given piece of code with arguments (passing a programfile ala julia myfile.jl or the -e/-E flags with given argument. These two are really semantically the same case, except that there's no disk IO for opening a file and reading the program string in)
• Run a REPL

The only case where -i should make a difference is the second case - the first one is akin to not having a "main execution" and so a REPL is launched, as that's the default behavior.

[sukera@tempman test]$ ls
test1.jl  test2.jl  test3.jl
[sukera@tempman test]$ cat test1.jl 
println(isinteractive())
[sukera@tempman test]$ cat test2.jl 
println("hello")
[sukera@tempman test]$ cat test3.jl 
println(isinteractive())
[sukera@tempman test]$ julia -L test1.jl -q
true
julia> 
[sukera@tempman test]$ julia -L test1.jl test2.jl 
false
hello
[sukera@tempman test]$ julia -q -L test1.jl -i test2.jl
true
hello
julia> 
[sukera@tempman test]$ julia test1.jl
false
[sukera@tempman test]$ julia -qi test1.jl
true
julia> 

So

• either you define isinteractive() as testing whether the REPL will/is used,
• or you define it as whether -i was given to the process

Or neither, as is the case for e.g. Jupyter notebooks, which are interactive but are neither a REPL nor requiring -i.

The docs for isinteractive() do not state anything about it being a REPL or not, it's just that the default behavior for julia myfile.jl does not launch a REPL, which is why you need -i there to say "hey, I explicitly want an interactive session (by default a REPL), after myfile.jl is done executing". Mind you, right now this will of course always spawn a REPL and never a notebook, but I do see there's design space to be explored here..

Anyone know what caused the change?

I haven't checked in depth, but I think this was an intentional change as a bugfix, directly intended to expose isinteractive() in startup.jl here: #42507

So right now I'd suggest loading your interactive packages conditionally based on whether or not isinteractive() is true or not. An alternative would be to define your jr as jr='current-julia --startup-file=no -q -t auto'. If there's only interactive stuff in your startup-file, this should do what you want, no?

[petvana]

Yes, it was intentional in #42507. Possible usage in startup.jl (that was not previously possible) is

if isinteractive()
    using OhMyREPL
    using Revise
    # ...
end

[ylvain]

@Seelengrab yes I agree with your reply, that was what I tried to say in my previous post, I've not be clear enough.
@petvana yes also, it's what I do/did. As it happens, I was relying on a UB when -i is not passed. Not a big issue really :)

So I'll close this. My original point was that it's technically a breaking change (user land code takes a difference conditional branch in the new version, and the previous behavior was not defined as UB). So maybe it should be added in NEWS.

but I do see there's design space to be explored here..

That was my second point. In the current situation isinteractive() is still a bit undefined, since is depends on what one define as an interactive session and how the process knows/guesses if it will end up in such a session after execution of all loaded code.