Easiest way to install VIM on TrueNAS Scale?

[ajgnet]

What is the cleanest way to install vim on TrueNAS scale? Thank you

 

[Patrick M. Hausen]

There isn't any. It's an appliance OS with a fixed feature set. You cannot install additional software except for VMs and apps. Is there really no vi on SCALE?

 

[ajgnet]

There is vi which is sort of sufficient. Vim would make things a lot easier.

 

[Patrick M. Hausen]

What sort of extensive manual editing on the NAS itself do you deem necessary?

 

[ajgnet]

Hah, when you frame it like that there is no reason to use vim other than writing a dissertation!

But in all seriousness, the undo/redo chain of commands, working escape key, pattern matching, visual highlighting, make the editing experience a lot easier.

On pfSense for example, one can add vim through "pkg install vim" which installs from the pfSense repository (not FreeBSD ports/packages) so it does not break the appliance nature of the system.

 

[Patrick M. Hausen]

I don't see any use case of editing a file on TrueNAS apart from really small shell scripts. You are not supposed to edit any system configuration - that won't survive a reboot, anyway. And for larger things I use MacVIM or VScode locally, git etc. and deploy the files to the target system.

 

[ajgnet]

Fair enough. I was able to get this working by installing the single package neovim binary:

Code:

wget https://github.com/neovim/neovim/releases/download/stable/nvim-linux64.deb
dpkg -i nvim-linux64.deb

Won't survive upgrades but easy enough to add to a startup script.

 

[anodos]

scale-build/conf/build.manifest at d1ad71802ee0f8ae495edb97c920b5fb6960ed72 · truenas/scale-build

TrueNAS SCALE Build System. Contribute to truenas/scale-build development by creating an account on GitHub.

github.com

We already have vim-tiny installed in SCALE.

 

[jgreco]

There is vi which is sort of sufficient. Vim would make things a lot easier.

What you're calling "vi" is actually vim.tiny.

I don't see any use case of editing a file on TrueNAS apart from really small shell scripts.

Well, just to be contrarian, I'll point out that I do a great deal of editing directly on the NAS, including one of the largest shell projects I've ever done, two scripts that together weigh in at more than 300KB. This is very useful because these scripts are shared out as read-only, and there's very little value in having a special VM just for editing.

Part of this works because I'm a native vi/nvi user, learned way back in the day on BSD 4.2, SVR4, and SunOS 4, and I tend to stick to a minimalistic set of operations that work across the board, even on stripped down embedded versions. That pile of trash that your typical Linux has installed, with all the bling and colors and other annoying crap, yes, I can imagine that if that is what you are used to, and what you learned on, then a more spartan vi or feature-stripped vim is going to be annoying.

I do actually like vim integrated with shellcheck, which I use for some types of projects.

 

[Patrick M. Hausen]

I am perfectly fluent in vi, too, originally coming from a SysV, then SysVR4 background. Yet for a couple of hundred k I would definitely use local VScode and git.

 

[ChrisRJ]

Just to point out alternatives for those who are not so much into Vi: On Core (and perhaps also on Scale) there is Midnight Commander (run mc), which I like to use (reminds me of the late 1980s/early 1990 when I had my DOS times). It also comes with nano.

 

[jgreco]

git blows. But I did finally find a reasonable, simple, understandable chart of how git is intended to work a bit earlier this year. Every other time I've had someone explain git at me, it's like listening to someone explain all the blingy vim features that you can turn on but which have little to do with actual editing; I just "need the basic vi" and I had not managed to get anyone to explain the basic h/j/k/l of it all.

Actually this might not be too bad a place to ask. Has anyone seen a chart like this, either this one or similar:



This neatly ties together git for me. It's intuitive and obvious. Git is something that I will never use often enough to warrant the day-to-day familiarity that some developers who have tried to explain it to me have had; I can see from this picture why it's hard to describe the differences between pull/merge/fetch, for example. I can definitely stick this in with our miscellaneous documentation, but it is unfortunately a photograph.

And I do too much hacking directly on systems for a "local" editor (meaning local to your PC, presumably) to be practical. I want a true local editor, something local to whatever I'm actually editing.

 

[ChrisRJ]

It is also worth noting that Git was originally developed for a very specific use-case: the Linux kernel development with its particular way to collaboration. Using the various bells whistles of Git for the sake of doing so, basically means to apply the Linux approach directly and without consideration to other situations. That is usually not a good idea, especially when it comes to things like CI/CD.

 

[Patrick M. Hausen]

That's about all the commands I ever use I'd prefer SVN but that battle is lost. I need to collaborate with my coworkers and the rest of the world so git it is.

 

[ChrisRJ]

That's about all the commands I ever use I'd prefer SVN but that battle is lost. I need to collaborate with my coworkers and the rest of the world so git it is.

I also come from SVN and had some problems when starting out with Git. Basically I think that most of Git offers is not necessary for me, so I mostly use it like SVN and that works well. And on Windows clients I like to use TortoiseSVN and TortoiseGit, that made the switch easier as well. But I know that GUIs for Git are not everybody's cup of tea.

 

[Patrick M. Hausen]

You cannot do a local checkout from a remote repo.
You cannot do a remote repo commit from a local working copy.

It's always unnecessary copying around of entire repositories.

 

[Thorarin]

The biggest annoyance I have with the pre-installed vim can be solved by:

Code:

vi ~/.vimrc
a
:set nocompatible
ESC
:wq

Profit!
At least that makes the arrow keys behave like a sane person would want them to behave :)

 

[Patrick M. Hausen]

What's wrong with the arrow keys? Working perfectly well here. You are not using the web UI builtin shell and try to run vi in that, are you?

 

[viniciusferrao]

What's wrong with the arrow keys? Working perfectly well here. You are not using the web UI builtin shell and try to run vi in that, are you?

I think he refers to showing up the characters A B C D on a new line when you press the cursor keys.

Also I was interested on vim and not vim.tiny, so I came to this topic.

 

[Patrick M. Hausen]

When exactly do these characters show up? They don't if I use the stock vi while logged in via SSH. If this happens to you while you are using the web UI shell - don't. It's broken. Use SSH.