vim-gutentags
vim-gutentags copied to clipboard
ludovicchabant
ctags job failed, returned: 1
I'm getting the above message on BufWrite. A tag file is getting generated. I've tried running with let g:gutentags_trace = 1 but thats not giving me any useful error message as to why ctags might be failing.
What steps can I take to debug this?
Interesting find, but I don't have a list_command specified in my vimrc. Only config I have is the following (using Vundle):
Plugin 'ludovicchabant/vim-gutentags'
set statusline+=%{gutentags#statusline()}
let g:gutentags_ctags_exclude = ["*.min.js", "*.min.css", "build", "vendor", ".git", "node_modules", "*.vim/bundle/*"]
@aquatix, Do you have ctags-exuberant installed on your system? I had same thing without it. And also, it would be nice to see trace when gutentags causes error.
So, is this issue still exist? If so. please show the trace. You can enable it by:
let g:gutentags_trace = 1
Same problem here. I'm using the plugin in its default configuration. Trace output right after saving a file (in a latex project) is:
gutentags: Running: ['~/.vim/bundle/vim-gutentags/plat/unix/update_tags.sh', '-e', 'ctags', '-t', 'tags', '-p', '.', '-s', 'doc/', '-o', '~/.vim/bundle/vim-gutentags/res/ctags_recursive.options', '-l', 'tags.log']
Note that I altered the path names slightly in the output.
I've executed the script with the parameters given by the trace and it stops with an error message:
ctags: "tags.temp" doesn't look like a tag file; I refuse to overwrite it.
And indeed, looking in the tag file, the first three lines are clobbered with some artifacts from the files in the project:
frametitle{Some title some_tex_file.tex /^ }$/;" u
frame{
!_TAG_FILE_FORMAT 2 /extended format; --format=1 will not append ;" to lines/
!_TAG_FILE_SORTED 1 /0=unsorted, 1=sorted, 2=foldcase/
!_TAG_PROGRAM_AUTHOR Darren Hiebert /[email protected]/
!_TAG_PROGRAM_NAME Exuberant Ctags //
!_TAG_PROGRAM_URL http://ctags.sourceforge.net /official site/
!_TAG_PROGRAM_VERSION 5.9~svn20110310 //
After that the file looks rather normal. I'll have a deeper look on how this happens this evening.
So I checked a bit more in detail. At least in my case, the problem seems to be caused by exuberant-ctags, not by gutentags. If I run a ctags -R . in the directory in question manually, without vim or gutentags running.
I can reproduce this issue on this single source directory, but not on others, furthermore it seems only to be an issue on my Ubuntu machine at work, but not on my Fedora machine at home. I'll check that in detail and report upstream if necessary.
@jhogendorn, @aquatix could you check, if in your case the error is also caused by a similar corrupted tag file?
It looks like a corrupted file here too indeed, there's 52 lines of cruft before the line with !_TAG_FILE_FORMAT
In my case, it was cause by some TeX file(s) that were followed from a symlink to another directory outside the 'project root'. After removing that link, ctags creates a valid file again.
Wow that's pretty random :) Thanks for investigating. I guess we should find a way to better report that the tags file is corrupted (by maybe bubbling up the ""tags.temp" doesn't look like a tag file; I refuse to overwrite it." message to Vim).
Just in case anyone cares, this sort of issue with ctags was reported 6 years ago and is still open
https://sourceforge.net/p/ctags/bugs/332/
there is a similar ticket for some javascript. Seems there is no active development on ctags for some time now.
@ludovicchabant The message would be good to have (or in general a more verbose error message, if the job fails), at least as option.
@ludovicchabant yeah, having the ctags messages bubble up, would help, as it's way more clear for the user that it's something that's bugging ctags, not vim-gutentags.
@d3rhans OK, that's slightly bad indeed. I hope someone feels irked enough to take up active development again (no, I won't take another pet project ;)).
Thanks all for investigating, would not have found the solution so easily without the various pointers.
I have the same problem.
.vimrc
114 let g:gutentags_project_root = ['.git', '.svn', '.root', '.hg', '.project']
115 let g:gutentags_ctags_tagfile = '.tags'
116 let s:vim_tags = expand('~/.cache/tags')
117 let g:gutentags_cache_dir = s:vim_tags
118 let g:gutentags_ctags_extra_args = ['--fields=+niazS', '--extra=+q', '--c++-kinds=+px', '--c-kinds=+px']
119 let g:gutentags_trace = 1
120 let g:gutentags_file_list_command = {
121 \ 'markers': {
122 \ '.git': 'git ls-files',
123 \ '.hg': 'hg files',
124 \ }
125 \ }
:messages outputs
gutentags: [job output]: ['Locking tags file...', 'Running file list command, patching for absolute paths', 'eval git ls-files', 'Running ctags on whole project', 'cta
gs -f "/root/.cache/tags/root-dmm-normalized-leibnize-.tags.temp" --fields=+niazS --extra=+q --c++-kinds=+px --c-kinds=+px --exclude=@ -L /root/.cache/tags/root-dmm-n
ormalized-leibnize-.tags.files', '']
gutentags: [job output]: ['ctags: Warning: --extra option is obsolete; use --extras instead', 'ctags: cannot open "" : No such file or directory', '']
gutentags: [job output]: ['']
gutentags: [job output]: ['']
gutentags: Finished ctags job.
gutentags: gutentags: ctags job failed, returned: 1
BTW, I'm using universe-ctags instead of exuberant-ctags.
Just found that the command being run is something like:
update_tags.sh -e ctags -t tags -p . -x @ -l tags.log
Locking tags file...
Running ctags on whole project
ctags -f "tags.temp" --exclude=@ .
ctags: cannot open "" : No such file or directory
The problem there is -x @. Running without it it runs ok:
update_tags.sh -e ctags -t tags -p . -l tags.log
Locking tags file...
Running ctags on whole project
ctags -f "tags.temp" .
Replacing tags file
mv -f "tags.temp" "tags"
Unlocking tags file...
Done.
Seems it runs ctags like:
ctags -f "tags.temp" --exclude=@
But on the ctags man page, it specifies that
If pattern begins with the character '@', then the rest of the string is interpreted as a file name from which to read exclusion patterns, one per line.
There is no rest of the string after the @ char, so I think it should be avoided?
Yep, sorry, I introduced that bug with a change yesterday -- you most likely get this bug if your wildignore is empty. I just pushed 713044e280792d29403fbcab3e477d790ef32eb8 to fix this!
@ludovicchabant Unfortunately I still have this bug with the latest version of the plugin
Here are what my log output:
gutentags: gutentags: ctags job failed, returned: 1 gutentags: Tracing is enabled. "mm/migrate.c" 1863L, 48196C written gutentags: Wildignore options file is up to date. gutentags: Running: ['/home/yuanren/.vim/bundle/vim-gutentags/plat/unix/update_tags.sh', '-e', 'ctags', '-t', '/home/yuanren/.cache/tags/home-yuanren-runninglinuxkernel_4.0- .tags', '-p', '/home/yuanren/runninglinuxkernel_4.0', '-L', 'find arch/arm/ mm/ kernel/ include/ init/ lib/', '-O', '--fields=+niazS --extra=+q --c++-kinds=+pxI --c-kinds=+p x', '-l', '/home/yuanren/.cache/tags/home-yuanren-runninglinuxkernel_4.0-.tags.log'] gutentags: In: /home/yuanren/runninglinuxkernel_4.0 gutentags: [job output]: 'Locking tags file...' gutentags: [job output]: 'Running file list command, patching for absolute paths' gutentags: [job output]: 'eval find arch/arm/ mm/ kernel/ include/ init/ lib/' gutentags: [job output]: 'Running ctags on whole project' gutentags: [job output]: 'ctags -f "/home/yuanren/.cache/tags/home-yuanren-runninglinuxkernel_4.0-.tags.temp" --fields=+niazS --extra=+q --c++-kinds=+pxI --c-kinds=+px -L / home/yuanren/.cache/tags/home-yuanren-runninglinuxkernel_4.0-.tags.files' gutentags: [job output]: 'ctags: unrecognized option ''--fields=+niazS''' gutentags: [job output]: '^ITry ''ctags --help'' for a complete list of options.' gutentags: Finished ctags job. gutentags: gutentags: ctags job failed, returned: 1
Notice how it says ctags: unrecognized option ''--fields=+niazS"'. Do you have a .ctagsrc or .gutctags or other place where you specified this option? Most likely you're using a version of ctags that doesn't support these field types?
Hi there, was it already patched? I'm getting
gutentags: Wildignore options file is up to date.
gutentags: Running: ['/Users/wviana/.vim/plugged/vim-gutentags/plat/unix/update_tags.sh', '-e', 'ctags', '-t', 'tags', '-p', '.', '-o', '/Users/wviana/.vim/plugged/vim-gutentags/res/ctags_recursive.options', '-x', '@/var/folders/6q/kby204
dx70z6k_k6_66m_tqm0000gn/T/vND6xnx/11', '-l', 'tags.log']
gutentags: ctags job failed, returned: 1
When it get fix will it be on master.
Got this in MacOS too. I think it's because the system ctags was in my path before exuberant ctags from homebrew. chmod -x /usr/bin/ctags made the error go away.
I had no ctags installed at all on one of my machines on MacOS. And I got the same error. brew install ctags solved the issue.
I've tried to remove execution as @sagotsky said. But probably the macos system protection don't allow to change it.
So as I nottice that my problems was about vim not calling a compatible ctags (exuberant or universal), I'v tried to re-install and relink with brew, almost the same as @snipem suggested, but with no sucess to me.
So my sollution what to add this line on my vimrc
let g:gutentags_ctags_executable = '/usr/local/Cellar/universal-ctags/HEAD-9630c39/bin/ctags'
this variable is on gutentags documentation. So I just placed the fullpath to ctags that I want it to run.
Hope to help others.
PS: If I've written something wrong please tell me, so I may learn and correct, as english is not my first language.
@snipem : in theory, Gutentags checks for the case where ctags is not installed at all. See this line, which is followed by a user-friendly message about the problem. Did you not get that error then?
@wviana to make it slightly prettier, and handle the case where you'll run brew upgrade, you could make it point to /usr/local/bin/ctags instead (by default, brew makes that a symlink to the last installed version)
I'm gettting
gutentags: Wildignore options file is up to date.
gutentags: Running: ['/Users/linyue/.config/nvim/plugged/vim-gutentags/plat/unix/update_tags.sh', '-e', '/usr/local/opt/universal-ctags/bin/ctags', '-t', '/Users/linyue/.cache/tags/Users-linyue-WorkStation-golang_dev-src-git.inke.c
n-BackendPlatform-golang-.tags', '-p', '/Users/linyue/WorkStation/golang_dev/src/git.inke.cn/BackendPlatform/golang', '-s', '/Users/linyue/WorkStation/golang_dev/src/git.inke.cn/BackendPlatform/golang/kafka/consumer.go', '-o', '/Us
ers/linyue/.config/nvim/plugged/vim-gutentags/res/ctags_recursive.options', '-O', '--fields=+niazS --extra=+q --c++-kinds=+px --c-kinds=+px --output-format=e-ctags', '-x', '@/Users/linyue/.cache/tags/_wildignore.options', '-l', '/U
sers/linyue/.cache/tags/Users-linyue-WorkStation-golang_dev-src-git.inke.cn-BackendPlatform-golang-.tags.log']
gutentags: In: /Users/linyue/WorkStation/golang_dev/src/git.inke.cn/BackendPlatform/golang
gutentags: Tag file '/Users/linyue/.cache/tags/Users-linyue-WorkStation-golang_dev-src-git.inke.cn-BackendPlatform-golang-.tags' is already being updated. Queuing it up...
gutentags: Running: ['gtags', '--incremental', '/Users/linyue/.cache/tags/Users-linyue-WorkStation-golang_dev-src-git.inke.cn-BackendPlatform-golang']
gutentags: In: /Users/linyue/WorkStation/golang_dev/src/git.inke.cn/BackendPlatform/golang
gutentags:
gutentags: [job output]: ['Locking tags file...', 'Removing references to: /Users/linyue/WorkStation/golang_dev/src/git.inke.cn/BackendPlatform/golang/kafka/consumer.go', 'grep --text -Ev ''^[^^I]+^I/Users/linyue/WorkStation/golang
_dev/src/git.inke.cn/BackendPlatform/golang/kafka/consumer.go^I'' ''/Users/linyue/.cache/tags/Users-linyue-WorkStation-golang_dev-src-git.inke.cn-BackendPlatform-golang-.tags'' > ''/Users/linyue/.cache/tags/Users-linyue-WorkStation
-golang_dev-src-git.inke.cn-BackendPlatform-golang-.tags.temp''', 'Running ctags on "/Users/linyue/WorkStation/golang_dev/src/git.inke.cn/BackendPlatform/golang/kafka/consumer.go"', '/usr/local/opt/universal-ctags/bin/ctags -f "/Us
ers/linyue/.cache/tags/Users-linyue-WorkStation-golang_dev-src-git.inke.cn-BackendPlatform-golang-.tags.temp" --options=/Users/linyue/.config/nvim/plugged/vim-gutentags/res/ctags_recursive.options --fields=+niazS --extra=+q --c++-
kinds=+px --c-kinds=+px --output-format=e-ctags --exclude=@/Users/linyue/.cache/tags/_wildignore.options --append "/Users/linyue/WorkStation/golang_dev/src/git.inke.cn/BackendPlatform/golang/kafka/consumer.go"', 'Replacing tags fil
e', 'mv -f "/Users/linyue/.cache/tags/Users-linyue-WorkStation-golang_dev-src-git.inke.cn-BackendPlatform-golang-.tags.temp" "/Users/linyue/.cache/tags/Users-linyue-WorkStation-golang_dev-src-git.inke.cn-BackendPlatform-golang-.tag
s"', 'Unlocking tags file...', 'Done.', '']
gutentags: [job output]: ['gtags: /Users/linyue/.cache/tags/Users-linyue-WorkStation-golang_dev-src-git.inke.cn-BackendPlatform-golang/GTAGS seems corrupted.', '']
gutentags: [job output]: ['']
gutentags: [job output]: ['']
gutentags: [job output]: ['ctags: Warning: --extra option is obsolete; use --extras instead', '']
gutentags: [job output]: ['']
gutentags: [job output]: ['']
gutentags: Finished gtags_cscope job.
gutentags: gtags-cscope job failed, returned: 1
@ludovicchabant What should I do.
I'm getting this error when ctags outputs some warning about files or directories it is not able to open or parse. Everything else seems to work though. Could it be that ctags just returns non-zero if there is some warning, even though everything is fairly ok?
Tag generation is also failing for me. The error message boils down to:
['ctags: cannot open "/var/folders/w8/qs0nxql90hd6rq04z3dpswhr0000gn/T/nvimlG6s0j/1" : No such file or directory', '']
The weird part is that this folder - whatever it is and wherever a reference to it is coming from - seems to be passed in as something to exclude. I.e. ctags is told to exclude this folder, but then it generates an error saying it can't open it, which doesn't seem to make a lot of sense.
Full message:
gutentags: Wildignore options file is up to date.
gutentags: Running: ['/Users/adrianduyzer/.vim/bundle/vim-gutentags/plat/unix/update_tags.sh', '-e', 'ctags', '-t', 'tags', '-p', '.', '-s', 'app/assets/javas
cripts/tenon/features/category_nav.js', '-o', '/Users/adrianduyzer/.vim/bundle/vim-gutentags/res/ctags_recursive.options', '-x', '@/var/folders/w8/qs0nxql90hd
6rq04z3dpswhr0000gn/T/nvimlG6s0j/1', '-l', 'tags.log']
gutentags: In: /Users/adrianduyzer/Mesa/www/drugs
gutentags: [job stdout]: ['Locking tags file...', 'Removing references to: app/assets/javascripts/tenon/features/category_nav.js', 'grep --text -Ev ''^[^^I]+^
Iapp/assets/javascripts/tenon/features/category_nav.js^I'' ''tags'' > ''tags.temp''', 'Running ctags on "app/assets/javascripts/tenon/features/category_nav.js
"', 'ctags -f "tags.temp" --options=/Users/adrianduyzer/.vim/bundle/vim-gutentags/res/ctags_recursive.options --exclude=@/var/folders/w8/qs0nxql90hd6rq04z3dp
swhr0000gn/T/nvimlG6s0j/1 --append "app/assets/javascripts/tenon/features/category_nav.js"', '']
gutentags: [job stderr]: ['ctags: cannot open "/var/folders/w8/qs0nxql90hd6rq04z3dpswhr0000gn/T/nvimlG6s0j/1" : No such file or directory', '']
gutentags: [job stderr]: ['']
gutentags: [job stdout]: ['']
gutentags: Finished ctags job.
gutentags: ctags job failed, returned: 1
After a reboot, all seems well again...still a rather strange issue.
I reinstalled brew reinstall ctags and restarted my machine. Still got the error.
I ended up uninstalling ctags and installed brew install universal-ctags. The error is now gone for me.
I do not need to set the gutentags_ctags_executable variable anymore.
I'm using https://github.com/universal-ctags/homebrew-universal-ctags and ran into this issue. At some point the brew symlinks went missing, or were never installed.
This fixed it for me
brew unlink universal-ctags && brew link universal-ctags
