Problem using vim in csh on linux

[Lowell Specht]

I'm new to linux. I have used unix for decades. We are moving to redhat linux servers at work and I'm trying to use vi but have a problem with the vi window refresh. When the file first opens, all looks good. As I page back and forth, the file starts to look corrupted but is really just that the window is not fully refreshed, I think.

I tried vim with the same result as vi though I think when I launch vi, it is aliased to vim. My default shell is csh. Today, on a whim, I switched my current shell to ksh and tried vi/vim and it works perfectly.

How can I get vi/vim to work properly in csh on linux?
Please, no responses telling me to use ksh, instead of csh or a different editor unless it is just vi by another name. Thanks.

[Tony Mechelynck]

Which version are you using? Pasting the first few lines of the stdout
output of "vim --version" (without the quotes, at a shell prompt)
ought to be enough. For me it says the following:

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 13 2015 21:11:46)
Included patches: 1-898
Compiled by antoine.m...@skynet.be
Huge version with GTK2-GNOME GUI. Features included (+) or not (-):

The rest (and there is a lot of it) is less interesting to solve your problem.

Best regards,
Tony.

[Tim Chase]

While I don't have any immediate familiarity with any such issue, a
bit of extra knowledge might help track things down:

- does your value of $TERM change depending on whether you're in csh
or ksh? What is your setting/value for $TERM? How does ":set
termresponse?" compare between working and non-working sessions?

- what is your terminal? Is it a (non-X)console, serial line,
SSH/telnet connection, or X terminal (and if so, which one? xterm,
rxvt, gnome-terminal, etc)? Are you using GNU screen or tmux?

- does hitting ^L (or using ":redraw") properly repaint the window
when you get corruption?

- do you notice it more with certain file-types?

- have you checked that the same binary is being run in both cases? A
difference in $PATH might cause different versions to be run
depending on your shell's initializations. The output of "which vim"
(or "which vi" if you invoke it like I do) within csh and ksh might
highlight differences. Also, any apropos aliases would help.

There might be other useful information, but the above might guide us
towards a better suggestion.

And if your screen/$TERM gets corrupted, there's always ed(1) ;-)

-tim

[Gary Johnson]

I don't normally use csh, but it is installed on one of the systems
I use. I executed csh in an xterm on a Fedora 17 system, then ran
vim. I tried a number of editing operations and never saw any
screen corruption.

It might help if you started vim as

$ vim -N -u NONE

and could give us some minimal sequence of steps that demonstrate
the problem.

Following the suggestions from Tony and Tim would be good, too.

Regards,
Gary

[Random832]

Tim Chase <v...@tim.thechases.com> writes:
> And if your screen/$TERM gets corrupted, there's always ed(1) ;-)

Or ex, which is technically "vi by another name" but almost certainly
not what he wants.

To add to the list of suggestions - if they are different, see what the
output of :set termcap looks like on both systems.

[Lowell Specht]

Thanks for all the feedback and suggestions!
I'll try to answer all the questions and suggestions.

What version of vim?
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 31 2015 11:14:07)
Included patches: 1-207, 209-629
Modified by <bugz...@redhat.com>
Compiled by <bugz...@redhat.com>
Huge version without GUI. Features included (+) or not (-):

What does $TERM look like for the non-working csh and the working ksh?
csh: TERM=xterm
ksh: TERM=xterm

How do I establish my terminal session?
terminal is Windows client app hummingbird exceed common desktop environment to logon to a HP unix server. From there, I ssh -Y to the linux server.

Does CTRL Shift L work? No.

Do I notice it more with different file types?
No. Problem appears while editing a makefile, a fortran source file and my .cshrc. I haven't spent a lot of time exploring this with other files.

Same path in both shells?
yes. which vim returns /usr/bin/vim in both shells. which vi indicates it is aliased to vim.

Minimal sequence of steps to demonstrate the problem:
1. windows client, launch hummingbird exceed CDE, login to unix server with default csh, launch an xterm, ssh -Y <linux server> in an xterm
2. vim an ascii file large enough that you can page back and forth.
3. ctrl-f and ctrl-b a few times and watch the text become garbled as the window does not fully refresh. Note that using j and k to scroll one line at time works fine (I just discovered this).

What is the output from :set termcap?
I am not familiar with this command. I tried it in both shells and got :set not found. So I tried it without the colon and got no error and no output. Just a return to the prompt.

Try, vim -N -u NONE.
I did. Same problem.

So, I hope this helps.
After typing this up, I tried Windows Client, putty terminal, ssh -Y to linux server and now vim works in csh. So it is looking like a problem with the hummingbird exceed CDE.

[Tim Chase]

On 2015-10-21 05:20, Lowell Specht wrote:
> What version of vim?
> VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 31 2015 11:14:07)
> Included patches: 1-207, 209-629

> Huge version without GUI. Features included (+) or not (-):

Okay, not running some archaic version, nor a stripped-down "tiny"
version.

> csh: TERM=xterm
> ksh: TERM=xterm

Okay, the same. Good.

> How do I establish my terminal session?
> terminal is Windows client app hummingbird exceed common desktop
> environment to logon to a HP unix server. From there, I ssh -Y to
> the linux server.

I'm not sure if there's something funky going on here. Can you SSH
directly to the linux server rather than through the HP server?

> Does CTRL Shift L work? No.

The "shift" is unobserved by vim in this case (so ctrl+shift+L ==
ctrl+L), but control+ell should force a clear+repaint of vim. If that
doesn't resolve matters, I'm now curious whether the artifacts are
full characters, in which case Vim may think that they belong there,
so it repaints them, or they're rendering corruption on your Exceed
terminal end (these could be full-characters or they could be partial
lines/swaths of color that simply don't get properly
cleared/overwritten/moved/updated). My money would be on Exceed
munging things as I remember less-than-quality experiences with it
the last time I used it (which, granted, was back in the late 90s).

> Minimal sequence of steps to demonstrate the problem:
> 1. windows client, launch hummingbird exceed CDE, login to unix
> server with default csh, launch an xterm, ssh -Y <linux server> in
> an xterm 2. vim an ascii file large enough that you can page back
> and forth. 3. ctrl-f and ctrl-b a few times and watch the text
> become garbled as the window does not fully refresh. Note that
> using j and k to scroll one line at time works fine (I just
> discovered this).

[wrote this before reading your closing paragraph. Whoops]
Do you have access to a terminal SSH program on your Windows PC?
Maybe via Cygwin or PuTTY? Or boot a live Linux/BSD CD, connect to
your HP box, then SSH to the Linux box? It would help to know what
happens if you can cut Exceed out of the picture (or possibly cut the
HP box out too).

> Do I notice it more with different file types?
> No. Problem appears while editing a makefile, a fortran source file
> and my .cshrc. I haven't spent a lot of time exploring this with
> other files.

Okay, the only really interesting answers would be "it happens with
this particular file-type, or family-of-file-types". Since it seems
to happen across the board, likely a blind alley.

> Same path in both shells?
> yes. which vim returns /usr/bin/vim in both shells. which vi
> indicates it is aliased to vim.

Drat. That was my front-runner idea before you so thoroughly shot it
down :-)

> Try, vim -N -u NONE.
> I did. Same problem.

Okay, this strongly suggests that it's not Vim, but that something
between vim and you is getting garbled.

> What is the output from :set termcap?
> I am not familiar with this command. I tried it in both shells and
> got :set not found. So I tried it without the colon and got no
> error and no output. Just a return to the prompt.

The ":" prefix was a hint that it should be run within vim. It can
be a little messy, so you might want to

:redir > termcap_output_from_vim.txt
:set termcap
:redir END

which should have vim capture the output and send it to
"termcap_output_from_vim.txt" that you can attach or manipulate a bit
more easily.

> After typing this up, I tried Windows Client, putty terminal, ssh
> -Y to linux server and now vim works in csh. So it is looking like
> a problem with the hummingbird exceed CDE.

Heh, would help if I read all the way to the end of your message
before beginning a reply. At least this corroborates my suspicions. I
don't know if your test included SSHing to the HP box and then SSHing
from there to the Linux box, just to exculpate the HP box.

But now you have some evidence you can take to Exceed folks to get
use out of your support-dollars. :-)

-tim

[Erik Christiansen]

On 21.10.15 05:20, Lowell Specht wrote:
> How do I establish my terminal session?
> terminal is Windows client app hummingbird exceed common desktop
> environment to logon to a HP unix server. From there, I ssh -Y to the
> linux server.

I have memories of using the same application for the same purpose, two
decades ago, when on the first day at a new job, I was shocked to find a
M$ box on my desk. That was circumvented by lunchtime. Vi/Vim worked fine,
with no xterm scrolling issues.

What happens if you leave the linux environment and "ssh -Y" out of the
equation, and just edit a file in the xterm on the HP server?

...

> What is the output from :set termcap?
> I am not familiar with this command. I tried it in both shells and
> got :set not found. So I tried it without the colon and got no error
> and no output. Just a return to the prompt.

That looks a lot like a Vim query of the current setting of "termcap".

Erik

[Lowell Specht]

On Tuesday, October 20, 2015 at 9:46:22 PM UTC-4, Lowell Specht wrote:

Here is some additional info though I believe my solution is to stop using the Hummingbird Exceed CDE to connect.

I did try the termcap suggestion in vim and got it to work. I don't know how to interpret the results though. I do have man pages for termcap so when I get some time, I'll see if I can figure out what it all means.

The garbled text I mentioned in my original post means whole characters, It's as if the window is simply not being repainted when I navigate using ctrl f and ctrl b.

Also, didn't mention this before, whenever I do a : command in vim, the command is not being repainted so the command remains at the bottom of the window and after several commands, the line becomes garbled with parts of former commands. This problem occurs in both csh and ksh.

I did try to do some editing yesterday using vim in ksh and discovered, for example, that if I delete 4 characters from a line using 4x, the characters are deleted, the remainder of the line shifts left 4 characters and the last 4 characters in the line left the original characters in place so that the last 4 chars are repeated. ex:

The rain in Spain stays mainly on the plain. <<original line

If I delete the word rain using 4x, the line becomes.

The in Spain stays mainly on the plain.ain. <<new line

This problem occurs in both ksh and csh though the original paging issue only occured in csh.

I did try putty connecting to the hp unix server and then ssh to the linux server and vim still works fine. So I don't think it is the unix server, I believe that vim is just not supported in Hummingbird Exceed CDE. It is a shame since I really like the CDE. I will be trying gnome in the near future as a replacement for the CDE and hopefully vim will work with that since gnome is bundled with linux.

Thanks for all the feedback. It has helped me to understand this issue better and moved me along my linux learning curve.

[Tim Chase]

On 2015-10-22 03:22, Lowell Specht wrote:
> The rain in Spain stays mainly on the plain. <<original line
>
> If I delete the word rain using 4x, the line becomes.
>
> The in Spain stays mainly on the plain.ain. <<new line

I'd normally expect that control+L would refresh to repaint that. I
know legacy vi had a behavior similar to this (and correspondingly,
one of the 'cpoptions' that controls a behavior like this). That said,
it's not what most folks want.

> I did try putty connecting to the hp unix server and then ssh to
> the linux server and vim still works fine. So I don't think it is
> the unix server, I believe that vim is just not supported in
> Hummingbird Exceed CDE. It is a shame since I really like the
> CDE. I will be trying gnome in the near future as a replacement
> for the CDE and hopefully vim will work with that since gnome is
> bundled with linux.

Before completely giving up on Exceed/CDE, I'd try poking around to
see if there are terminal emulator options that might align things so
they work. My first guess would be that Exceed's terminal (or
is it HP's terminal) doesn't fully support $TERM=xterm despite
claiming to. So you might try

lowell@linuxbox> export TERM=vt100
lowell@linuxbox> vim myfile.txt

or

lowell@hpbox> export TERM=vt100
lowell@hpbox> ssh linuxbox
lowell@linuxbox> echo $TERM # ensure it's still vt100 not xterm
vt100
lowell@linuxbox> vim myfile.txt

and then perform your tests. It may help to inform Vim that your
terminal isn't as smart as your terminal thinks it is. It may limit
some things like the range of available colors or the use of the
alternate/backing screen (":help xterm-screens") that an xterm
provides, but it hopefully will prevent the redraw artifacts you're
seeing.

Also, if you test your Exceed->HP->Linux link with other (n)curses
tools like Midnight Commander or ranger, nano, lynx, alsamixer, etc.
do you see similar artifacts?

-tim