I did "nano debian size" on google and one of them mentions - The Nano package contains a small, simple text editor which aims to replace Pico, ... Download size: 1.5 MB. Estimated disk space required: 20 MB.
https://www.linuxfromscratch.org/blfs/view/svn/postlfs/nano....
https://packages.debian.org/bullseye/nano
But building from source is a different story, if you stripe and clean build dir it will be similar to prebuilt .deb
A shame the linux kernel doesn't have some way for packers to say "I am a packer, I run with access to nothing except the binary, therefore run me with no permissions and then share the pages I make with any user that executes me. If you like, you can even delete my output and reunpack me on-demand"
I was mad about it at the time, but now I'm happy I made the change. Vim or vi is everywhere, including on the switches and routers I work on. Nano is not everywhere, nor can it easily be put everywhere.
If I weren't regularly SSHing into decrepit or resource-constrained hardware, I would likely see less of a benefit
Like.. this is wild https://vim.rtorr.com/
And now I'm hooked on a horrible amount of vscode plugins.
then you sit down for an hour and you create and edit a file, and you do not allow yourself to hold any key down to move the cursor around. you have the link you posted printed out, and you use only what is on the sheet to edit.
when you want to add something to the end of the line, you do NOT push the END key then enter edit mode, you look at the sheet and you find what you want and you push SHIFT+A to enter edit mode and go to the end of the line at the same time.
you keep track of which mode you're in and what mode you need to do something, and you force yourself through the keystrokes needed to operate completely and efficiently using only the keyboard.
in an hour, if you force yourself to use only the shortcuts on the cheat sheet, you will be more fluent in vi/vim than ~90% of the people who use it, myself included, and I've been using vi/vim for 25 years.
Vim is not an editor, it's a language you speak with your editor. Like with real language learning, some of it is just rote memorization.
There are, however, some tricks that I find really help. The first is to find mnemonics for the different actions. Some are obvious, for example (d)elete or (c)hange. Some require a little imagination, like un(t)il (like in 'til).
Finally, there's some level of logic to many related things. For example, the CAPITAL version of an action is generally a "louder" more aggressive/stronger version. So (a)ppend is just "insert after current cursor position", whereas (A)PPEND! means "insert at the very end of this line".
Just like with languages, if you use them long enough, they start to "make sense", and "feel right". I don't have to translate "I want to append at the end of the line" to the correct keybinding, I simply "speak" to the editor in a way that "feels" right.
You can start vim with --clean to fix your vimrc.
`set mouse=a` - yes i want to use a mouse `i` - start editing `esc :wq` - exit
From there it's syntactic sugar navigation and editing.
And dang he owns toms.net, nice.
His resume on here hasn't been updated since 2002. Looks like he started his career in 1987. This is an interesting looking resume. Tons of skills at the top, goals, Other. I suppose it's cover-lettery.
If none of the EDITOR/VISUAL/etc. variables are set when you invoke 'visudo' a f*king nano appears.
Like god dammit it i assume vi in that name comes from vi as even the manpage has 'vi' among 'see also'. This is akin to launching firefox and some random application popping up - its the ultimate troll and i salute your graybeards for solving the problem at the core!
And I 105% assure that that system was the most secure in the entire county... And also unusable. And when that lad retires or someone in their office kills them out of sheer desperation, hopefully they'll be replaced by one of these new fangled engineers who might not know about vi, but they at least care a little bit about their users(Not a lot though, we're still engineers)
Restart the computer
It’s SO inefficient in comparison to Vim, VSCode, or tons of other alternatives.
If it’s the only thing on the box, fine, but in reality usually Vim is the only editor installed.
But I am MUCH faster and more efficient with nano than I am vi/vim/emacs. My text editor of choice is like my IDE of choice, it shouldn't be a problem at all for anyone to just accept that I'm getting my work done in a different application.
If you are interested they might give you a good start.
As a *nix tech I could get a call to work on a QNX system, HP-UX system, SGI Altix supercomputer or a Sun Ultra 2. Linux systems were easy, as they had the package management support for FL/OSS, and would commonly come with Emacs in the base-pack (before nano was mainstream). Sometimes you would have a terminal issue and have a single line to work with, in which case you would need to operate vi without seeing what you are doing (or use sed/awk). So maybe it is those instincts to KISS and force everyone to learn vi, like they had to (I had to).
Certainly it provides no significant surface area of attack to have an editor, but I wouldn't put it past a threat actor to leverage plugin functionality as a persistence mechanism. I presume that these applications operate differently as root, but maybe not as service (daemon) accounts. It's not very well hidden, but there are all grades of threat actors.
However, the choice of text editor is a very personal one. It makes no sense at all for anyone to insist that anyone else should or shouldn't use any particular text editor. Just let people use what they like.
When I first encountered nano, I found out that it could silently corrupt configuration files (by word wrapping long lines) unless you were very careful to always start it as "nano -w". Since then, I've always removed nano (or at least set something else as the default editor) on every Unix system I administer.
What you mentioned is "soft wrapping", which is visual only but doesn't affect the saved file. But the default for nano when I first encountered it was "hard wrapping", which does affect the saved file. Some distributions later changed the default in the nano configuration file, but depending on the configuration file instead of a built-in default is risky. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=135978 (and the five other bug reports merged into it) for an example of the problems caused by running nano in the default configuration without disabling its line wrapping.
I write the standards for our engineers to follow/emulate/consider. I don't have very much for nano but this is what I put into every containers userdata scripts. I can't get this curl command to show up correctly.
# Add syntax highlighting and line numbers to nanorc, need to fork syntax repo so we're not installing random git repos
curl {
echo set constantshow
echo set linenumbers
} > ~/.nanorcHowever, I do understand the criticism, and how that could leave a bad first impression.
I'd been a linux/bsd engineer forever and I worked at some places where they refused to install nano on servers. There are some greybeard linux admins who absolutely refuse to let someone use anything other than vi. I never got that. It's a 20MB package and not exactly much of an attack vector.