Windows gVim 8.1 :redir issue with a external command and :silent

[craigmac]

Hopefully I've included enough information here to reproduce for others and/or help me diagnose what is going on. If not let me know what you need and I'll add it/adjust my issue.

Issue: running an external command on gVim 8.1.1 on Windows 7 and capturing the results using combination of redir and silent only works as desired when using gvim.exe -u NONE--gvim.exe -u DEFAULTS does not work correctly.

Setup:

• Windows 7 64-bit, latest updates
• Python 3.6.8 (32-bit, important! 64-bit python36.dll will not work with gVim 32-bit version with +python3/dyn) from python.org installed to C:\Python36-32
• gVim 8.1 (2018 May 18) 32-bit GUI with patches: 1, Huge Version +python/dyn +python3/dyn.

Steps to reproduce:
Open two gvims, gVim 1 using '-u NONE', the second using '-u DEFAULTS'. See the screenshot that shows what :scriptnames produces for each startup sourcing (note titlebar string show which gvim is which, I just used :set titlestring after opening each gvim).

In -u None:

1. :silent !python -m pydoc print
2. No echo'd message or anything in messages area, just as expected

In -u DEFAULTS:

1. :silent !python -m pydoc print
2. What looks like a cmd.exe window quickly launches and is closed, returning to gVim, but no messages are shown in :messages or command-line. Re-running it over and over you can make out that it is indeed running the command and printing out the correct documentation for python -m pydoc print. I've tried different commands, e.g., :silent! !ls -la, and the same thing happens.

Desired result:
In -u DEFAULTS, :silent/:silent! should not open a cmd window.

Redirection issue

Step 1.
In -u None run:
:new
:redir @d
:silent! !python -m pydoc print
:redir END
and then in insert mode:
d
To paste the result from the d register. Should look like (trimmed some whitespace here):

:!python -m pydoc print

Help on built-in function print in module builtins:
print(...)
    print(value, ..., sep=' ', end='\n', file=sys.stdout, flush=False) 
    Prints the values to a stream, or to sys.stdout by default.
    Optional keyword arguments:
    file:  a file-like object (stream); defaults to the current sys.stdout.
    sep:   string inserted between values, default a space.
    end:   string appended after the last value, default a newline.
    flush: whether to forcibly flush the stream.

This is exactly what I expected and WANT to happen. Now try Step 2, where gVim sources some other files.

Step 2.
In -u DEFAULTS gVim run the same commands found in step 1. When you paste the register you'll get something like:

:!python -m pydoc print

And no other text--so it seems we are not capturing the output from the command and/or not honouring the :silent when gVim is started with -u DEFAULTS. However after some searching I cannot figure out which .vim file is changing the way the external call to !python is handled.

Here is an image of both gvim -u NONE and gvim -u DEFAULTS opened side-by-side with :scriptnames run to show what was sourced before running the redir command.

[chrisbra]

Please check the output of the various shell settings.

 verbose set shell? shellcmdflag? shellpipe? shellquote? shellredir? shellslash? shelltemp?

I suppose shelltemp makes a difference, because that is set in non-compatible mode (e.g. using -u DEFAULTS).

[craigmac]

Same results minus one option for both -u NONE and -u DEFAULTS, which are:

shell=C:\Windows\system32\cmd.exe
shellcmdflag=/c
shellpipe=>%s 2>&1
shellquote=
shellredir=>%s 2>&1
noshellslash

As you mention, in -u DEFAULTS gvim we have: shelltemp and in -u NONE: noshelltemp.

In -u DEFAULTS gvim, doing :set noshelltemp solves the problem, thank you! I ended up working around it by using system() which ended up working nicely, but this behaviour to me is strange for default behaviour (on Windows, at least).

I guess after reading through :h shelltemp there are some valid reasons for it, at least at one point in the past, I just don't know enough about it to understand whether still setting shelltemp via defaults.vim is a good thing for Windows platforms (it wasn't for me in this specific case).