using alternate shell for startup

[Edward Peschko]

All,

I was playing around with map and nested autocommands for splitting on buffers, and noticed that when I actually do a split via a map, ie:

map ,, :split <cfile><CR>

it actually goes through the whole setup process via starting the shell, loading the associated rc file, etc etc.

However, for me this process is exceedingly long because I have an involved rc file that takes an order of seconds to execute and the commands were hanging as a result. So when I tried to set it to:

export SHELL='/bin/tcsh -f'

to save on startup cost, I got a message from vim saying "Cannot execute shell '/bin/tcsh -f'"

I ended up setting it to /bin/bash just to avoid the hassle.

So a couple of things:

1. why does vim need to spawn a shell just to open up a new buffer? The command I used was "map ,, :split <cfile><CR>".
2. is it possible for vim to accept a SHELL with arguments, like the above, to avoid startup cost?
3. is there a variable, say VIMSHELL that could be used to specify the shell to use in the case that #2 is not possible?

Thanks much for any info,

Ed

[Gary Johnson]

On 2019-06-01, Edward Peschko wrote:
> All,
>
> I was playing around with map and nested autocommands for
> splitting on buffers, and noticed that when I actually do a split
> via a map, ie:
>
> map ,, :split <cfile><CR>
>
> it actually goes through the whole setup process via starting the
> shell, loading the associated rc file, etc etc.

I tried reproducing this and found no evidence that a shell was run.
I executed the following,

$ strace -f -t -o strace.out vim -N -u NONE -i NONE

then within that vim defined you map and executed it. The window
split, as expected. I then exited vim and opened the strace.out
file in vim. There was no line containing "bash" in that file.

The version of vim I was using was 8.1.497 because it's what I had
handy. It's possible that the behavior you're seeing was introduced
since then.

Why do you think that vim spawns a shell when executing your map?

> However, for me this process is exceedingly long because I have an
> involved rc file that takes an order of seconds to execute and the
> commands were hanging as a result. So when I tried to set it to:
>
> export SHELL='/bin/tcsh -f'
>
> to save on startup cost, I got a message from vim saying "Cannot
> execute shell '/bin/tcsh -f'"

Right, because SHELL is the name of the shell, not the command to be
executed when you want to run a shell. You can, however, set the
vim option 'shell' to the full command, including options. See

:help 'shell'

Also, with bash you can determine in your rc file whether or not you
are running an interactive shell by testing for the presence of PS1
or for the presence of i in $-. See the INVOCATION section of the
bash(1) man page. You can thereby avoid executing the
time-consuming parts of your rc file when you're only using bash to
run some command, not establish an interactive shell environment.

> I ended up setting it to /bin/bash just to avoid the hassle.
>
> So a couple of things:
>
> 1. why does vim need to spawn a shell just to open up a new
> buffer? The command I used was "map ,, :split <cfile><CR>".

I don't think it does. We need to look into this further.

> 2. is it possible for vim to accept a SHELL with arguments,
> like the above, to avoid startup cost?

Assuming that whatever you're doing actually spawns a shell, you can
change the arguments given to that shell to prevent from reading
its startup files. For bash, these arguments would be --noprofile
and --norc.

When vim runs a shell to execute external commands, it passes that
shell the options in 'shellcmdflag'. You might be able to add those
two options to the 'shellcmdflag' option to have vim using those
options only when executing an external command and not when
spawning a shell with the :sh command.

> 3. is there a variable, say VIMSHELL that could be used to
> specify the shell to use in the case that #2 is not
> possible?

As I wrote above, use the 'shell' option.

Regards,
Gary

[Edward Peschko]

On Saturday, June 1, 2019 at 1:58:16 PM UTC-7, Gary Johnson wrote:
> On 2019-06-01, Edward Peschko wrote:
> > All,
> >
> > I was playing around with map and nested autocommands for
> > splitting on buffers, and noticed that when I actually do a split
> > via a map, ie:
> >
> > map ,, :split <cfile><CR>
> >
> > it actually goes through the whole setup process via starting the
> > shell, loading the associated rc file, etc etc.
>
> I tried reproducing this and found no evidence that a shell was run.
> I executed the following,
>
> $ strace -f -t -o strace.out vim -N -u NONE -i NONE
>
> then within that vim defined you map and executed it. The window
> split, as expected. I then exited vim and opened the strace.out
> file in vim. There was no line containing "bash" in that file.
>
> The version of vim I was using was 8.1.497 because it's what I had
> handy. It's possible that the behavior you're seeing was introduced
> since then.
>
> Why do you think that vim spawns a shell when executing your map?

Gary,

I basically did the same thing ie: used strace to get the output and it shows the opens for the shell. It also shows this in an error on the console.

I think the reason a shell opened was because of the filetype I split on - namely a perl module file, which opened up ftplugin.vim, which opens the shell.

Note that this only happens to me if I have 'ftplugin on' set in my vimrc. So you are basically at the mercy of any of your plugins as to whether or not they are going to do this.

The issue with 'set shell' for me is that it has an unpleasant side effect. At least in my setup, when you do 'vi file' it interrupts the load of the file with a 'press <enter> to continue'. I'm setting it as follows:

set shell '/bin/tcsh -f'

which is the equivalent of what you did with bash. Remove the set shell, and this goes away.

Ed