Issuing command within vim triggers suspend of vim

[alecjacobson]

I'm trying to use fpp from within vim. For example, in vim I pipe the output of ls into fpp

:!ls | fpp

This works as usual bringing up the familiar fpp interface. Suppose I choose a file f and then enter command mode with c and enter echo. This successfully echos the selected filename but has an untended side effect of suspending my vim session. I'm back to my bash terminal and see

[1]+  Stopped      vim

[pcottle]

Just a random question first -- what functionality of fpp are you looking for over something like NERDTree? the multiple selection and command mode perhaps?

Anyways, I'm actually quite surprised this works as much as you described :P So the command gets correctly echo-ed out, but the vim session never resumes?

I'm worried it's this line:
$SHELL -i ~/.fpp/.fpp.sh < /dev/tty

can you possibly try without the < /dev/tty hook? should be able to edit the fpp bash script easily:

[pcottle:~:]$ type -a fpp
fpp is /usr/local/bin/fpp

[alecjacobson]

Exactly, I like the multiple selection + command mode. (I hadn't heard of NERDTree before).

Removing < /dev/tty from that line did not fix the problem, but removing the -i did fix it (though I'm not sure what that could now have broken).

[pcottle]

but removing the -i did fix it (though I'm not sure what that could now have broken).

gah, yeah then we might have to close this out unless we can detect if we are inside the vim shell or not.

basically the -i option forces it to be interactive, so things like opening up vim / emacs / git add -p / whatever will actually work. Seems like vim's execution mode gets tripped up by running an interactive script.

Seems like theres a similar issue over here too:
zaiste/vimified#89

[pcottle]

(for context, we need the -i to both expand bashrc aliases iirc and make the tty stuff work. so reverting it would be a fairly big regression.

im open to ideas on running conditionally with the -i option if we can somehow tell we are inside a vim subshell)