1

Suppose I have mapped the following function:

noremap <C-F12> :! bash -c "\ git rev-parse --show-toplevel \ | xargs -I {} \ ctags -R --sort=yes --c++-kinds=+p --fields=+iaS --extra=+q {}" \ <CR>

No matter how I nest it, it seems as if VIM will not run the function. I suspect a possible solution in the form of setting vim's shell to "/usr/bin/env bash" instead of sh, somehow.

But maybe there is some other solution? (or just a typo...?)

The goal here is to run the command exactly as if it were BASH and not Vim.

Improve this question

2 Answers 2

Reset to default
3

In Vim line continuation is done with a backslash on the new line. Like:

noremap <C-F12> :!bash -c ' \git rev-parse --show-toplevel \\| xargs -I {} \ ctags -R --sort=yes --c++-kinds=+p --fields=+iaS --extra=+q {}' \<CR>

Another point is the usage of | in the command line, as it is a command separator for Vim (like ';' for the shell). So it has to be escaped. See the \\| above? The first \ is for line continuation, the second to escape the |.

See :help line-continuation

Anyway, I think your mapping could be more vimish:

noremap <C-F12> :call system('ctags -R --sort=yes --c++-kinds=+p --fields=+iaS --extra=+q ' \. shellescape(system('git rev-parse --show-toplevel'))) <CR>

This uses two Vim functions:

  • system() to execute a shell command and get the output
  • shellescape() to escape a file name for usage in a shell command.

See :help system() and :help shellescape().

Improve this answer
4
  • 2
    Or dump the shell commands in a script and call that Commented Jun 27, 2020 at 1:36
  • regarding the comment about newlines, are you saying that when I write this remapping command in the .vimrc file, that the escapes do not actually espace the \n in the file when the file is parsed by the lisp lexer? I say this because the literal file string would be: "foo bar\n\whatever", which actually back-slashes the w and would be un-parsable without two passes or always looking ahead to see if the next char is a slash...if that is the case, that is interesting Commented Jun 27, 2020 at 17:26
  • @Christopher "Lisp Lexer"? Commented Jun 27, 2020 at 19:48
  • Oh, no you are right, I am getting it confused with Emacs now. Either way, VimLangauge or whatever they call it has a parser, a lexer, etc. en.wikipedia.org/wiki/Lexical_analysis here, you can read all about a waste of time. Anyhow, processing the backslashes after the newline suggests they used some unorthodox approaches at the bottom level of whatever it is that creates the "vim-keymap and interface" (the only thing we users care about). And all I care about is recording new keymaps in a way that is readable by me. Commented Jun 28, 2020 at 16:11
0

Minimal Verifiable Solution

| is a vim character, and must be escaped.

noremap ~~ :! \bash -c "git rev-parse --show-toplevel \\| xargs -I {} \ctags -R --sort=yes --c++-kinds=+p --fields=+iaS --extra=+q {}"<CR>

Note: the following will work as well

noremap ~~ :! \bash -c "git rev-parse --show-toplevel \ \| xargs -I {} \ctags -R --sort=yes --c++-kinds=+p --fields=+iaS --extra=+q {}"<CR>

And this will fail:

noremap ~~ :! \bash -c "git rev-parse --show-toplevel \ \| xargs -I {} \ ctags -R --sort=yes --c++-kinds=+p --fields=+iaS --extra=+q {}"<CR>

This seems to be a bug.

Style Guide

The xargs -I {} trick is an excellent way to maintain full control of the arguement, with lateral linux-distribution compatibility. The purpose of xargs is primarily to maintain feed-forward semantics so that direction of control-flow does not hop back and forth for the downstream reader (probably yourself) unnecessarily, i.e:

grep 'foo' <(cat bar) sed 's/foo/bar/' $(generate baz)

Further, xargs -I {} is semantically equivalent to parallel --keep-order -I {}. gnu-parallel advertises compatibility with xargs; however, in my experience, this is superficial only; -I {}, however, removes the impedement.

Contextual Discussion

When writing BASH, it is preferable to use double quotes and reserve single quotes for nested languages such as awk, sed, grep, perl, etc. This reduces clutter, and maintains env variable substitution. The sub-languages often have a mechanism for nested environment variable substitution through the use of flag-arguments.

An example is awk, which uses -v varname=${BASH_ENV_VARIABLE}, or python, which uses -E to turn on environment variable substitution within the single quotes. All instructions for these sub languages, which can be used from within vim, are accessible via info or man. man is available in all distributions I am aware of, and can be used as follows:

man <command-name> # e.g. man python

Further, vi can be connected to the command line vi set -o vi, and accessed on the fly by typing <esc>-v. Context switching may be painful if you also switch to vimmish commands and system calls.

Improve this answer
5
  • Your "Minimal Verifiable Solution" does not work for me. I get errors like E492: Not an editor command: bash -c \\ . I tested Vim 8.2.869 and NVIm v0.5.0-577-g48ac77a14 on Linux. Commented Jun 27, 2020 at 19:48
  • The double backslash in the above comment is a typo. Should be single. Commented Jun 27, 2020 at 21:39
  • @Ralf should work now. Commented Jun 28, 2020 at 13:59
  • @Ralf it turns out that you can put the first slash in the \\| escape sequence at the end of the prior line. That should have implied that it could be used at the end of the prior line for all lines, but it did not. That seems like a bug. In my code, I have the remapping on one line; the original formatting was only for stack overflow. So, tbh, it was content that I really didn't care about, but, as always, spent the most time on in stack exchange. Commented Jun 28, 2020 at 14:00
  • 1
    Nice find. This trailing backslash looks really strange. Commented Jun 29, 2020 at 4:46

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.