2015-05-30 6:08 GMT+03:00 Andy Russell <arussell...@gmail.com>:
> While writing my own plugins, I wish to support users who have fish or
> cmd.exe set as their shell. However, this often leads to a tedious pattern of:
>
> if fnamemodify(&shell, ':t') ==# 'fish'
> " Fish syntax
> let cmd = ...
> else if has('win32) || has('win64')
> " cmd.exe syntax
> let cmd = ...
> else
> " POSIX syntax
> let cmd = ...
> endif
>
> let output = system(cmd)
>
> I propose that the system() and systemlist() functions be extended to
> abstract these concerns away from plugin implementors. Before setting out on
> the implementation, I'd like to gather some feedback concerning the changes
> that I think would accomplish this in a backwards-compatible way.
>
> First, I'd like to allow the first argument to system() and systemlist() to
> be a List in addition to a String. If the argument is a List, then the user's
> shell's equivalent of '&&' will be inserted between each command. That is,
>
> `system(['command', 'echo success'])` would be semantically equivalent to
> `system('command && echo success')` if the user's shell is bash, or
> `system('command; and echo success')` if the user's shell is fish.
system(['command', 'echo success']) is already reserved for something
like system('"command" "echo success"') and that makes more sense
because you can have `&&` completely in Vim:
call system('command')
if !v:shell_error
call system('echo success')
endif
, but you can’t launch command directly without invoking the shell
(this is why I said “something like”: with system(['command', 'echo
success']) no shell is invoked). By “reserved” I mean “NeoVim already
modified system() to work like this”.
>
> Handling redirection syntax is slightly trickier, because I want to support
> redirecting stdout and stderr independently of each other to a file, as well
> as keeping the stdin functionality. One solution is to allow the second
> argument to the functions to be a Dictionary with the following format:
>
> {
> 'stdin': (lines to be used for stdin of the first command, defaults to
> nothing),
> 'stdout': (a file that stdout should be redirected to, defaults to being
> printed)
> 'stderr': (a file that stderr should be redirected to, defaults to being
> printed)
> }
>
> Therefore, system('command', { 'stdin': 'input', 'stdout': '/dev/null',
> 'stderr': '/dev/null' }) would be equivalent to system('command &>
> /dev/null').
This makes sense, but again you are suggesting to use shell. This is
worthless: I think that functionality like this must be implemented on
another level: in place of translating 'stdout': '/dev/null' to
`&>/dev/null` it makes more sense to connect stdout to /dev/null after
fork, telling launched shell absolutely nothing about what you do.
This will make code shell-independent.
And another idea: 'stdin', 'stdout' and 'stderr' must all accept one
of three variants:
1. File name. It is better to open file and connect it to stdin then
to use readfile() and supply the result.
2. Stdout/stderr only: `return`. Value that indicates that
corresponding output should be returned by system(), default.
3. Stdout/stderr only: `return2`. Value that indicates that system()
must return a list and corresponding output must be second in the
list.
4. Stdin only: raw string.
Something like this:
1. stdout/stderr: '/path/to/file.name'. All: {'file': '/path/to/file.name'}.
2. stdout/stderr: {'return': 0} or nothing
3. stdout/stderr: {'return': 1}.
4. stdin: 'some string', ['some string', 'line 2'] or {'string':
['some string', 'line 2']}.
Vim has very convoluted way of processing system() calls: in place of
using pipes to get the output and supply stdin it uses temporary files
and redirection.
>
> I think that these options would be a huge boon to plugin authors and be
> great for people who use non-POSIX compliant shells. Are these changes
> acceptable? I'd love to hear some feedback.
I think that you do not need Vim knowing shell syntax. But Vim
integration with external programs is missing some critical pieces
which are
1. Separate stdout and stderr processing ('return': 1).
2. Ability to work without shell.
3. Ability to redirect from/to other file streams.
>
> --
> --
> 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 vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
