3

私は C 開発環境で実行vimしています。freebsd 6.3 サーバーの GNU ウィンドウ内でcscope開始し、.cscope db 接続を確立します。この段階では、すべてが問題なく機能します。vimscreencs add ...

screen セッションを切り離して再度接続すると、cscope を使用しようとすると、cscope がコア ダンプを発生させます。私の cscope はデバッグ シンボルでコンパイルされていないため、これがコア ダンプから得たすべてです。

(gdb)
#0  0x480f45dc in ungetch () from /lib/libncurses.so.6
(gdb)

私の知る限り、画面に再接続するときにvimでcscope接続を再確立する必要はありません。それは screen を使用する目的を無効にします。何が起こっているのか、回避策があるのか​​ 誰でも知っていますか? すべてが失敗した場合は、時間を見つけて cscope をシンボルでコンパイルし、何が起こっているのかを把握します。

それが役立つ場合、私のCSCOPE DBは次のとおりです。

cscope -bkq -P`pwd` -i cscope.files
4

2 に答える 2

3

これは、cscope 15.7a で修正された問題であることが判明しました。他の誰かが同じ問題を抱えている場合に備えて、ここに回答を投稿してください（ここに投稿することを決定する前に、数年間気になりました）。

于 2012-01-06T00:54:42.680 に答える
2

vim(ラインモード)を呼び出しようとしているにもかかわらず、curses でクラッシュしていることを考えると、それがあなたの問題に関連しているcscope -lと推測するのは合理的だと思います。TERM=screenラッパーを作成してみてください（たとえば、パス$HOME/binの前にあると仮定して）それを変更します：/usr/local/bin

#!/bin/sh

if ! test -t 0
then
    TERM=vt100
fi

exec /usr/local/bin/cscope "$@"

「ttyから実行していない場合は、偽のTERM」と書かれています。tty テストは、インタラクティブな使用を中断しないようにするためのものです。TERM=noneまたは他の値を試すこともできます。

于 2013-03-01T06:19:02.460 に答える