Consider this shell command:

$ MANPAGER='vim -Nu NONE -R -' man git-credential-cache

It makes man(1) display the man page of git-credential-cache(1) in Vim.

However, the name of the man page – as displayed on the first line of the buffer – is GIT-CREDENTIAL-CAC(1). Notice how HE is missing at the end of the name:

name of git-credential-cache man page is missing its last two characters

I would expect this name instead:


I ran strace(1) to see which system calls were used by man(1):

$ MANPAGER='vim -Nu NONE -R -' strace -o log man git-credential-cache

Toward the end of the log file, I can see a read(2) and write(2) system call, using the buffer name GIT-CREDENTIAL-CAC(1):

read(7, "GIT-CREDENTIAL-CAC(1)           "..., 4096) = 2720
write(8, "GIT-CREDENTIAL-CAC(1)           "..., 2720) = 2720

So it seems that it's man(1) and not vim(1) which is truncating the name of the man page.

Here is the full contents of the log file, another log file containing the output of the same strace(1) command but with the additional -f argument to also trace the child processes, and the tree of processes leading to the man(1) process:

$ pstree -lsp $(pidof man)

Is there a way to prevent man(1) from truncating GIT-CREDENTIAL-CACHE(1) into GIT-CREDENTIAL-CAC(1)?

The reason why I ask this question is because the truncation causes an error message to be displayed when using the Neovim man plugin:

            ┌ Taken from `:h man.vim` in Neovim
$ MANPAGER='nvim +Man!' man git-credential-cache
man.vim: command error (7) man -w git-credential-cac: No manual entry for git-credential-cac

error in Neovim due to the truncation of the man page name


$  lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.6 LTS
Release:        16.04
Codename:       xenial

$ man --version
man 2.7.5

$ vim --version | head -n2
VIM - Vi IMproved 8.1 (2018 May 18, compiled Sep  3 2019 11:05:36)
Included patches: 1-1967

$ nvim --version | head -n1
NVIM v0.4.0-1856-g82d52b229

1 Answer 1


It's not man who's truncating it either:

$ zcat /usr/share/man/man1/git-credential-cache.1.gz | head -n 10
'\" t
.\"     Title: git-credential-cache
.\"    Author: [FIXME: author] [see http://docbook.sf.net/el/author]
.\" Generator: DocBook XSL Stylesheets v1.79.1 <http://docbook.sf.net/>
.\"      Date: 09/28/2018
.\"    Manual: Git Manual
.\"    Source: Git 2.11.0
.\"  Language: English
.TH "GIT\-CREDENTIAL\-CAC" "1" "09/28/2018" "Git 2\&.11\&.0" "Git Manual"

So you'll have to fiddle with whatever git is using to generate its manpages and rebuild them (last time I had checked they were using asciidoc -- the sloowest thing in the universe ;-)).

  • Thank you very much for the answer. I'm still confused by something though. I don't know exactly how man(1) passes the man page to nvim(1), but the latter reads a buffer whose name is initially man://git-credential-cac(1). I guess this name is set by man(1) itself, because there is no code in the Nvim plugin which alters it prior to the autocmd listening to BufReadCmd (github.com/neovim/neovim/blob/…).
    – user938271
    Commented Sep 13, 2019 at 12:41
  • Does it mean that man(1) uses the truncated command name written in the header inside the man page to set the name of the buffer/file that it passes to nvim(1), and ignores the full command name that I typed after $ man?
    – user938271
    Commented Sep 13, 2019 at 12:41
  • 1
    1. no, the buffer name is set by vim, in the man#open_page function called just before your link 2. man passes the data to vim through a pipe, it doesn't use any kind of named buffers, you can try with MANPAGER=cat. The strace output from your Q shows data actually read or written, not "buffer names". Simple example printf "some text" | strace -e trace=read cat >/dev/null.
    – user313992
    Commented Sep 13, 2019 at 13:11
  • Oh, you're right. So the issue is that Nvim relies on the header to guess the name of the man page: github.com/neovim/neovim/blob/…
    – user938271
    Commented Sep 13, 2019 at 14:21
  • 1
    At least on linux, it could better use the MAN_PN environment variable.
    – user313992
    Commented Sep 13, 2019 at 14:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .