eval in config.fish inside a second instance stops the shell

[zanchey]

Running 2.7.1-1449-gdeb6d477

If you have the following in your config.fish:

if status is-interactive
   eval (touch /dev/null)
end

Then when starting a new instance of fish inside an existing instance, the behaviour is as follows:

> echo $SHLVL
1
> fish
Job 1, 'fish' has stopped
> echo $SHLVL
1
> jobs
Job	Group	State	Command
1	26930	stopped	fish
> fg
Send job 1, 'fish' to foreground
zanchey@oxygen ~> echo $SHLVL
2
zanchey@oxygen ~> exit
> echo $SHLVL
1

This bites me because I have eval (python3 -m virtualfish) in my config.fish.

[faho]

This bites me because I have eval (python3 -m virtualfish) in my config.fish.

That should just be python3 -m virtualfish | source. Does that work?

If it does the problem here is evals weird job control stuff.

[faho]

Yup:

status job-control full
echo echo wurst | source # stops
status job-control interactive
echo echo wurst | source # does not

This is probably caused by fa66ac8 and friends.

[faho]

Definitely fa66ac8. This works:

status job-control full
command echo echo wurst | source

while builtin echo command echo | source still STOPs.

I think this is an issue with our keepalive process.

[mqudsi]

I toyed with using owl to create a parser for fish expressions that would enable creating a logical process dependency chain to enable both simultaneous evaluation of non-dependent subshells, parallel commands, functions, or builtins and allow us to get rid of the keepalive process by instead creating a wait chain where each function only waits on the process(es) needed for its input streams to become ready but ran into two issues that prevented me from progressing down that track.

[ridiculousfish]

I finally figured out how to do concurrency properly here - with a Python-style GIL (fishgil, haha). So I believe the concurrency issues will be mostly solved in 3.1.

I'll take a look at this fa66ac8-caused regression.