我必須使用一個需要透過某些 Citrix/Windows 虛擬化登入才能最終存取 RedHat EL 6 系統的系統,在該系統中我遇到了一些管理員無法修復的非常奇怪的行為。
基本上,除非我在螢幕內使用,否則兩者似乎都正常工作vi
。vim
一旦進入螢幕,如果我移動到顯示的初始內容之外(即移動到比螢幕可以顯示的長度長的文件末尾或中間,或者我向下滾動到底部一行或二)。當這種情況發生時,終端螢幕底部繪製的「INSERT」會將所有內容向上推一行。如果您的編輯很小(即沒有移動並在不同的行上進行許多更改),通常沒問題,但是重繪的內容不正確(有時vi 本身的附加反饋會將前一行向上滾動,因此您最終會得到兩行- INSERT -- 行或其他文字)但是,如果您在插入後四處移動,特別是如果您強制視窗的內容滾動或完全繪製,那就完全是一團糟。將遊標移到行尾或任何不遵循螢幕上顯示內容的位置。
更令人沮喪的是,可以透過兩種方式存取這個奇怪的系統:1 透過終端會話(透過虛擬化 IE 瀏覽器),1 透過 VNC 桌面(透過相同的虛擬化)。不幸的是,由於刷新問題和卡住字元(隨機字元重複數百次),VNC 桌面完全無法用於命令列。但是,儘管存在這些問題,vi 確實可以在螢幕內運行。
我已將兩種類型的 vi 會話中的變數轉儲到檔案中,它們是不同的,但我不太了解 vi,無法知道哪些變數可能是罪魁禍首。
FWIW,兩者都使用相同的 VIM 7.2.411 二進位檔案(/bin/vi 仍然存在問題)和螢幕 4.00.03 兩者都在同一台機器上
當我提交幫助台票證時,管理員安裝了較新版本的 VIM,這實際上使問題變得不那麼嚴重,但除了非常小的更改之外,它仍然無法用於編輯檔案。
答案1
問題可能是您的螢幕配置為使用終端機視窗的最後一行作為硬狀態行,並且您在 screenrc 中開啟視窗前配置硬狀態行。您的螢幕配置是否包含類似的內容?
screen 1
# ...
hardstatus alwayslastline "..."
在這種情況下,screenrc 中的 screen 命令打開的視窗沒有配置正確的行數——它沒有考慮 Hardstatus 行使用的行。不過,其他視窗應該沒問題(比較stty size
screenrc 開啟的初始視窗和其他視窗的輸出)。
我已經針對這個問題開啟了一個錯誤這裡。儘管回想起來,hardstatus 配置之前的 screen 命令可能會產生這種效果,但從使用者的角度來看,這是相當意外的(許多設定檔沒有排序的概念)。另外,奇怪的是,如果你做了類似的事情:
screen 1
screen 2
screen 3
# ...
hardstatus alwayslastline "..."
只有視窗 3 配置不正確。