On Mon, Jul 11, 2016 at 12:40 AM, Manuel Ortega <[email protected]> wrote:
> On Sun, Jul 10, 2016 at 1:23 PM, Bram Moolenaar <[email protected]> > wrote: > >> >> Manuel Ortega wrote: >> >> > On Saturday, June 14, 2014 at 11:51:59 AM UTC-4, Justin M. Keyes wrote: >> > > With shelltemp=0, Vim automatically falls back to using temp files if >> > > pipes don't work. So why isn't shelltemp=0 the default? >> > > >> > > If I understand correctly, 'shelltemp' affects: >> > > >> > > :! >> > > :w !foo >> > > :r !foo >> > > >> > > But it does _not_ affect system(). Is that because it just hasn't been >> > > implemented for system(), or is it a design decision? system() often >> > > has temp file permissions issues on Windows[1][2][3][4], so using >> > > pipes could make system() more reliable. >> > > >> > > Another question. :help 'shelltemp' says: >> > > >> > > The advantage of using a temp file is that the file type and >> encoding >> > > can be detected. >> > > The FilterReadPre, FilterReadPost and FilterWritePre, >> > > FilterWritePost autocommands event are not triggered when >> > > 'shelltemp' is off. >> > > >> > > Is there a technical reason this can't be done? >> > > >> > > Thanks! >> > > >> > > [1] >> https://groups.google.com/forum/#!msg/vim_use/JSXaM9YjWKo/HtHn36WFb_kJ >> > > [2] >> https://groups.google.com/forum/#!msg/vim_use/adD_-9yBCEU/Y0ul-OwXGpYJ >> > > [3] https://github.com/mattn/gist-vim/issues/48#issuecomment-12916349 >> > > [4] >> https://groups.google.com/forum/#!msg/vim_use/oU7y-hmQoNc/2qQnkPl6aKkJ >> > > >> > > Justin M. Keyes >> > >> > I would very much like to know the answer to the OP's question, since >> > I would like the ability to force system() to obey &noshelltemp. >> >> It's implementation. system() uses get_cmd_output(), which always uses >> temp files. Making it use pipes is going to be some work. And it won't >> be 100% the same, thus it should be enabled explicitly. >> >> There are some subtle differences, but they may cause a hang, thus >> changing defaults isn't a good idea. > > > I think it should be part of the documentation of system() that it will > not obey &noshelltemp. Looking in ':h system()' I see the phrase "Pipes > are not used", but it has the appearance of applying only to the special > case mentioned in the immediately preceding text, namely the case where > {input} is both given and is a list. It would be clearer if there were an > empty line between "list items converted to NULs)." and "Pipes are not > used". > > It should also be part of the docs for &shelltemp that turning it off will > not affect system(). > Here is a patch, made with `git diff`: diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt index d8fe9c0..1003c7a 100644 --- a/runtime/doc/eval.txt +++ b/runtime/doc/eval.txt @@ -7202,7 +7202,9 @@ system({expr} [, {input}]) *system()* *E677* in a way |writefile()| does with {binary} set to "b" (i.e. with a newline between each list item with newlines inside list items converted to NULs). - Pipes are not used. + + Pipes are not used; thus setting 'shelltemp' to zero has no + effect. When prepended by |:silent| the shell will not be set to cooked mode. This is meant to be used for commands that do diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt index f535fcf..89354f7 100644 --- a/runtime/doc/options.txt +++ b/runtime/doc/options.txt @@ -6455,6 +6455,8 @@ A jump table for the options with a short description can be found at |Q_op|. The |FilterReadPre|, |FilterReadPost| and |FilterWritePre|, |FilterWritePost| autocommands event are not triggered when 'shelltemp' is off. + Note that this option has no effect on |system()| since that function + uses temp files no matter what. *'shelltype'* *'st'* 'shelltype' 'st' number (default 0) -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
