vi gives error - shomode:No such option

[Rita C Workman]

Huh...vi gives error - shomode:No such option "set all" gives all options...No space on device

I have never seen this one...and couldn't find anything on Search for shomode.

Developers logging in using telnet are getting this the second they try to use vi.
Now when I connect to box using my nice Hummingbird XDMCP Broadcast..(logged in as developer) I get in and no problems.
So it doesn't seem to be an issue with vi.

The telnet lets me into the box, but once I'm in (as developer) I can't vi...huh ??

Anybody seen anything like this, just started today...and NO I haven't anything..honest !

Rita

[Steven E. Protter · Accepted solution]

I've seen that before when /var/tmp (or wherever vi wants to store its temporay files) has incorrect permissions or when the /var filesysetm was at 100%

It may also be an environment problem, but I can't remember how I made that one happen for my developers.

How you doing? Hope all is well in WV.

SEP

[Eric Antunes]

Hi Rita,

Sometimes, it happens to me when trying to delete more than 100K lines. It says something like this:

"Huh: out of registry space"

Than I delete just 50K lines, save and quit before deleting more 50K lines...

Eric Antunes

[Peter Godron]

Rita,
are you sure you are running the same editor.
Are you using the $EDITOR login setup?
Have you tried running the telnet session with /usr/bin/vi ?
Regards

[Fred Ruffet]

Do you have the same output, running "which vi" as your user or developper ?

Are the users or you have a .virc in $HOME ?

What are there temp dir set to ? Is it full ?

Regards,

Fred

[Rita C Workman]

OK guys...thanks for the input.

It's fixed. Was filesystem corruption, albeit not a great message to figure it out. But in syslog I found some earlier vx_ialloc inode type errors.
This box is what we call a GOLD server. It runs a read only version of our production database, so we use it for big reports and backups and such.
Had the DBA shut it down (since it's the GOLD copy, not the production instance) and we umounted the infracting filesystems (one was truly hosed big time), did a full fsck on them. They are back up and the GOLD instance is restarted...all is well again.

Points a coming..
Thanks again to all !
Hey Steven...hope to see ya at the next conference!
Rita

[Rita C Workman]

Solution mentioned...
Thread Closed

Although not the exact fix, Steven got the closest, cause it was environment. Corrupted file system.

Rgrds