vim missing in FreeNAS 9.2.1.7 ?

[freenas1]

hello all,
after moving from 8.3 to the latest release, i don't find vim. Can i add it?

thanks in advance,

 

[danb35]

Yes, in a jail. No, to the base OS.

 

[Whattteva]

I didn't even know that vim actually existed in 8.3. I guess I just always assumed it doesn't and use vi instead unless I'm in a jail.

 

[danb35]

I'm a wimp and use nano instead. It's not very often I properly have occasion to do much text editing outside of a jail anyway.

 

[jgreco]

"vim" is a marginal clone of the vi editor. FreeBSD ships with the current version of the classic 4BSD implementation of vi. There is no need for a poor clone when the real thing exists on the system.

 

[Whattteva]

I'd have to disagree with that sentiment. As a regular user of vim, I can't really live without it in my jails. I can live without it on the base system cause I rarely have to do much other than occasional admin stuff.

There are quite a lot of things found in vim that don't exist in vi (multiple undo history, multiple paste buffers, syntax coloring, just to name a few).
Calling it a poor clone is IMO grossly inaccurate as it is an improvement in every respect. It is a superset of vi PLUS much more.

 

[jgreco]

No, it's not grossly inaccurate. One of the first things you should do when cloning is to avoid clashing with existing features; for example, you mention "multiple undo history." Which is exactly the point. vi's undo works a specific way, which is that "u" undoes the last change to a file - which implies that it acts as a toggle, because if you do an "undo", you have just made a change to the file, so another "undo" is essentially "redo". So it is safe to hit "u" multiple times, and some of us regularly use that. While vim does have an "compatibility" option to make it work more-or-less correctly, it isn't set by default, and that's going to cause administrators pain in shared administrative environments. It's an epic fail to collide with the real vi's functionality in such a manner. Syntax coloring? Please. This isn't kindergarten, vim. Put away the crayons and use a pen. I do not need an idiotic editor trying to guess at what colors are going to provide good readability - if it has no idea what color the background and foreground are being drawn in (and it doesn't) then it has no business trying to colorize text. And don't get me started on vim's file locking fails.

To be clear here, I have no problem with those features *existing*: a great editor should have lots of good features and should be customizable. But the out-of-the-box feature set should behave like the thing it is cloning. You know how bash is the default /bin/sh on Linux and as a result we have an entire generation of people who now use bash-isms in their .sh shell scripts without knowing they're doing so, and other related problems? In many ways, vim is the editor equivalent of that.

vim's a big (at about 6x the image size of vi) ugly (default colorization) poor clone (defaults for undo) of vi.

 

[Whattteva]

Whoa, I thought editor wars are restricted to emacs vs vi(m). Don't think I've seen any wars about vi vs vim ever and I've honestly never seen anyone complain about vim extra features being cumbersome since they're rather indispensible for programmers and pretty sure majority of users expect multiple undo/redo history from any modern editor. Yes it may be larger than vi, but it's still leaps and bounds lighter than any GUI based editor or even emacs. I don't think I've ever heard of anyone complaining that vim is too heavy/slow either.

I do stand corrected that it's not a perfect clone in the strictest sense of the word though. Anyway, these editor wars are usually pointless cause what works best is anyone's personal preference so I'll leave it at that.

 

[jgreco]

As a programmer, I am happy to let my compiler point out errors and a revision control system perform multiple undos. As a sysadmin, I'd rather have an editor that functions as an editor without presuming to colorbarf all over. The colorbarf thing is great for Linux since so many other parts of their userland impose gratuitous color on users - - users are likely to have a black background or something else that's compatible. But for those of us that are used to having ten or twenty windows open at the same time and differentiate them with color, vim's colorization is a real PITA. I hate ssh'ing into Linux boxes because it feels like I'm in a kindergarten schoolroom full of kiddies drawing in crayon.

http://www.reddit.com/r/vim/comments/1sogzs/vim_still_sucks/
http://nathanhammond.com/why-vim-sucks
http://gnuvince.wordpress.com/2007/03/28/five-things-i-hate-about-emacs-and-vim/

And from this:

http://drostie.livejournal.com/4528.html

I actually like a bit of description attributed to Emacs: "that the text editor should come to fit you like a well-worn glove", except that with vi, it's kind of the other way around, and you get used to the way the gloves fit, so when you come across something that looks to be the same thing but then fits wrong, it becomes hard because your reflexes are to do certain things and to expect certain things to happen in response.

I have nothing against other editors, but when you're cloning something, you should actually try not to extend functionality in incompatible ways.

 

[Whattteva]

All your links except for the first one apply just the same to vi, they just use vim instead because most people tend to treat them as one and the same.

I have nothing against other editors, but when you're cloning something, you should actually try not to extend functionality in incompatible ways.

As I have stated in my previous post, you have a point here.
I feel like it's not the fault of vim or bash for "bash'isms" though. It's more the fault of most Linux distros that decide to symbolically link /bin/sh to bash and /bin/vi to vim by default.

 

[jgreco]

Definitely.