What’s up with nano? | Hacker News Reader

What’s up with nano?

asty.org

126 pointswdr179 comments

This is something I was pondering the other day: given nano's proliferation, I wonder how many devs use it in a regular basis? My suspicion is that nano is more popular than vim or emacs, just used less. Many devs who do not primarily use a command line editor use nano when they have to. It's like a screwdriver: it's nobody's favorite tool, but it's probably the most popular.

I wouldn't be too surprised if you were right. In an advanced comp sci class I took recently I was surprised to find that when we had to ssh into the university's supercomputer and edit some code something liked 75% of students used nano and only a quarter used vim. These are people early in their career using a low latency connection but it still surprised me.

My experience is that it's easier to remember the commands for Nano. vi confuses the hell out of me.

I'm not actually a Comp Sci major or anything, maybe that matters?

It does matter. When you're editing code in all kinds of terminals over 4 years the basics become ingrained. Really knowing how to quit at first and being able to get to the different modes makes a big difference. Also using it on your home computer helps. Once you get used to it other editors seem cumbersome.

The thing about vim is that the interface is a language. It certainly takes some learning. Check out vim-adventures.com

I fall in this category, I use neither Vim nor Emacs because I never had a need to learn them and I'm happy with lightweight GUI editors like Geany and Notepad++. Nano on the other hand was the default command line editor in the university computer lab, so I had to learn the basics to get around and still use it today.

I use it day in and day out. It's my favorite editor due to its simplicity. Most of my work is editing source and I find the command set and feature appealing for that. When I need to do serious line oriented editing or regular expression work I switch to vim.

I'm also in the "nano -w" camp. It's been muscle memory for over a decade now.

Took me years to mentally/muscle memory replace pico -w with nano -w, on many machines i would symlink nano to pico

I don't write code in nano, but it's fine for editing configuration files when you're on SSH. For writing code, I would never use an editor that does vendor lock-in by not supporting standard shortcuts for common things such as copy, paste, search and replace.

> A private thread ensued between myself, GNU, and Benno, and what came out of that conversation was that Benno was not going to be allowed to become a maintainer of the project in GNU’s eyes.

This is the part I'm most curious about. Why didn't GNU let him become a maintainer?

GNU requires contributors (and maintainers) to assign copyright for non-trivial contributions. Benno doesn't want to do this, thus in GNU's eyes, he can't be the maintainer.

You can argue (and it has been, to death) whether copyright assignment is right or wrong. When it comes to GNU projects, it's the rule of law. Based on mailing list posts and contribution history, it seems like the project had probably been in questionable GNU territory for awhile, given Benno's strong role and his unwillingness to assign copyright. I'm curious to see how the GNU project will respond.

Do you know what GNU's rationale is for requiring copyright assignment?

I'm no expert, but I believe the rationale is to simplify relicensing (GPLv2 -> GPLv3, for instance). I also think the papers disallow dual licensing the project with a proprietary license.

There's more discussion here: https://news.ycombinator.com/item?id=11953703

https://www.gnu.org/licenses/why-assign.en.html

Because it makes it easier for them, as owner, to deal with copyright violations.

conversely, what's the argument against assigning copyright? I'm pretty sure the EFF can be trusted to keep nano open source.

> I'm pretty sure the EFF

Do you mean FSF here?

oops. yah.

> GNU requires contributors (and maintainers) to assign copyright for non-trivial contributions.

It's up to the individual projects whether they want to assign copyright to the FSF.

Related discussion: https://news.ycombinator.com/item?id=11953044

I personally have a question relevant to this that seems to not have been answered in the previous discussion ref'd by brudgers: what does GNU stand to lose in losing Nano? What does Nano stand to lose by losing the GNU moniker?

That's a good question to ask. My opinion: nothing, basically, on either side. You could argue that being an official GNU project gives nano a level of legitimacy and carries with it an implied quality level. I wonder if nano would ship by default on basically every *nix distribution without the help of GNU. Last I checked, it was nano, not emacs that comes preinstalled on an Ubuntu image.

I think nano helps fulfill the GNU project's original goal of a flexible OS. I think of emacs and nano as having a similar relationship as wordpad and notepad. That's a bad comparison, but you could say both tools are valid and functional for the purposes they were designed for.

As it stands I think nano is better off hosting development on github or the like. People go to great lengths to install and customize their text editors, so hard core users will seek out the best nano. What sucks is I would be surprised if the next version of OSX includes a non GNU nano, thus fragmenting even further.

This is my 2 cents, and I'm mostly talking through my hat.

…does nano have hardcore users aside from its own developers?

I accidentally downvoted you, sorry.

I think most nano users will end up using the one shipped with their distro, which means that the choice of fork will mean a lot for usage statistics. No one is going to go out of their way to install the best nano fork.

With vim/emacs you'll have super opinionated users and they will make sure that they use whichever is the best/most stable version, but in this case I really think politics plays a much bigger part.

I've been using OSX for years and never realized that it includes Nano until now.

What a dreadful choice of color combination! I cannot even read the comments here after reading that post.

Agreed.

Quick workaround: Firefox has a reader mode (the little book-icon at the right side of the address field) that renders the main content of a page black-on-white in a very eye-friendly (read: huge) font size. I used to wonder what that was for, but these days I come across unreadable or unreadably ugly pages more often, and I have come to like it.

My first editor was ed, then I switched to joe and pico, tried briefly vi and elvis but they didn't stick, and instead to learn how to do the same in five small editors I learned emacs. I think that this was a dificult, but very smart move in retrospective. Learned enought nano to be able to float, after or maybe at same time than emacs, so their main appeal to me always was that it was like a micro-emacs available for emergencies, but much easier to remember than ed. I like and keep using the editor, but to learn "big tricks" in nano was unnecessary from that point, because the time invested in emacs eventually started paying benefits.

I never understood why nano is so popular. It even breaks line breaks by default.

It's a simple modeless editor, with all the keys you need to know to save and exit printed on the bottom two lines. Someone used to notepad on Windows would have little to no trouble using it. That's why Debian installs it as the default text editor.

Another good reason:

  $ ldd /bin/nano
	linux-vdso.so.1 (0x00007ffc72add000)
	libmagic.so.1 => /usr/lib64/libmagic.so.1 (0x00007f3eca793000)
	libncursesw.so.5 => /lib64/libncursesw.so.5 (0x00007f3eca52b000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f3eca193000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f3ec9f73000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f3ec9d6b000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3eca9bb000)
  $ ldd /usr/bin/vim
	linux-vdso.so.1 (0x00007ffd69bfd000)
	libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007efe2d7d3000)
	libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007efe2d5b3000)
	libXt.so.6 => /usr/lib64/libXt.so.6 (0x00007efe2d33b000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007efe2cfdb000)
	libm.so.6 => /lib64/libm.so.6 (0x00007efe2cceb000)
	libncurses.so.5 => /lib64/libncurses.so.5 (0x00007efe2ca8b000)
	libacl.so.1 => /lib64/libacl.so.1 (0x00007efe2c87b000)
	libgpm.so.1 => /lib64/libgpm.so.1 (0x00007efe2c673000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007efe2c46b000)
	libc.so.6 => /lib64/libc.so.6 (0x00007efe2c0d3000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007efe2becb000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007efe2bca3000)
	libattr.so.1 => /lib64/libattr.so.1 (0x00007efe2ba9b000)
	/lib64/ld-linux-x86-64.so.2 (0x00007efe2d9e3000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007efe2b893000)
	libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007efe2b68b000)

There probably are stripped down versions of vim out there, but this makes nano more reliable in the case of say a corrupted disk where libs are corrupted...less points of failure at least.

I think it's a bit more fair to compare it to vi or nvi

    $ ldd $(which nvi)
    /usr/local/bin/nvi:
            Start            End              Type Open Ref GrpRef Name
            0000047a80c00000 0000047a8106c000 exe  1    0   0      /usr/local/bin/nvi
            0000047d4d9f6000 0000047d4de50000 rlib 0    1   0      /usr/lib/libncursesw.so.14.0
            0000047c97a14000 0000047c97e20000 rlib 0    1   0      /usr/lib/libutil.so.12.1
            0000047ca1ba9000 0000047ca2073000 rlib 0    1   0      /usr/lib/libc.so.88.0
            0000047d3bf00000 0000047d3bf00000 rtld 0    1   0      /usr/libexec/ld.so
    $ ldd $(which vi)
    /usr/bin/vi:
            Start            End              Type Open Ref GrpRef Name
            0000106784500000 0000106784956000 exe  1    0   0      /usr/bin/vi
            00001069ee8ed000 00001069eed47000 rlib 0    1   0      /usr/lib/libcurses.so.14.0
            00001069f097f000 00001069f0d8b000 rlib 0    1   0      /usr/lib/libutil.so.12.1
            00001069a8f41000 00001069a940b000 rlib 0    1   0      /usr/lib/libc.so.88.0
            0000106a02600000 0000106a02600000 rtld 0    1   0      /usr/libexec/ld.so

One thing I found interesting:

$ ldd /usr/bin/ne

        linux-vdso.so.1 =>  (0x00007ffc22abf000)

        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1c2d4ee000)

        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f1c2d2c5000)

        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1c2ceff000)

        /lib64/ld-linux-x86-64.so.2 (0x00007f1c2d7ff000)

For a pretty full featured text editor ne has surprisingly few dependencies.

Is your "vim" actually "gvim"?

On ArchLinux I get the following:

  ldd /usr/bin/vim
        linux-vdso.so.1 (0x00007ffdcebf9000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f1a49617000)
        libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007f1a493aa000)
        libacl.so.1 => /usr/lib/libacl.so.1 (0x00007f1a491a1000)
        libgpm.so.2 => /usr/lib/libgpm.so.2 (0x00007f1a48f9a000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f1a48d96000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f1a48b79000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f1a487d8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f1a4991b000)
        libattr.so.1 => /usr/lib/libattr.so.1 (0x00007f1a485d3000)

Here's neovim:

    $ ldd $(which nvim)
        linux-vdso.so.1 =>  (0x00007fff75590000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f821b0ea000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f821aecc000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f821acc7000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f821a9c1000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f821a7be000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f821a3f8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f821b301000)

This is on gentoo, so it looks like I have X, acl, and gpm use flags set for vim, which are a weak correspondence to configure options. So, I'm assuming you can remove SM,ICE,Xt,X11...gpm,acl,xcb,Xau,Xdcmp from my list. Quite a reduction! I admit. To be fair, nano can remove magic, ncurses which cuts it down to libc, libz for nano, and libm, libattr, libc, and ncurses for vim. I'm assuming you might be able to remove ncurses for vim(?) by configure? I've never built vim by hand.

So you might be right, the stripped out version makes a difference.

The ones that ship with OS X 10.11:

  $ otool -L /usr/bin/nano
  /usr/bin/nano:
          /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
          /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.0.0)
  
  $ otool -L /usr/bin/vim
  /usr/bin/vim:
          /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
          /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
          /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

If seems to me that if you're in a situation where you have to worry about working on a corrupted FS where parts of /usr/lib and /lib may or may not be reliable, thats about the time when you say 'screw it' and restore from backups.

Glad I'm not the only one that thought that. This sounds to me like comparing kitchen cabinets based on "which one might work best when your house is on fire".

Because it's simpler to grasp than vi, at least for newbies. You hit backspace, it deletes a character. You hit enter, it makes a newline. And so on.

Exactly what appealed to me in the beginning. Coming from Windows I was lost enough without trying to guess how to get out of vi.

Once I got more comfortable with how things work I was confident enough to use it and I would not want to miss it any more.

> I was lost enough without trying to guess how to get out of vi.

Oh man, I remember googling that years ago now. That was fun. Now I use Vim and Visual Studio Code for all my editing, but because my Vim is so customized, if I remote into a server I'm more likely to reach for nano instead.

vi doesn't kill my newlines when on PuTTY.

On that note, i wonder if people should take a long at another of Hishamhm's (Htop, Gobolinux) projects, Dit.

Its a terminal editor that uses hotkeys that you more commonly find in GUIs.

https://github.com/hishamhm/dit

I think there is a whole tier of both entry level hobbyists and what I'll call lower sophistication professionals, sysadmin types that manage small or mid-sized company IT systems where there are a small handful of low volume Linux servers (or similar) to deal with: basic configs, basic backups, etc. For them, I think nano is as close an analog to what they get in a windowed operating system, while still dealing with the command line.

These aren't the types to go run off and learn vi or Emacs because, at the level they're playing at, there's not much advantage. They are in the command line text editor only occasionally for a simple edit here and there. nano is relatively intuitive, vi and Emacs aren't.

Moreover, I think it may be under appreciated, especially here on HN, just how many technology professionals are in this category. They know what they know and get by with it.

EDIT: I should make clear, that "lower sophistication professionals" don't have anything to be ashamed of nor are they somehow lesser in what's important; I just don't know how to say it in a way that doesn't have a tinge of sounding derogatory. It's not intended.

I fall into this category, I run a HTPC off Lubuntu for performance reasons and because I like to tinker in different technologies, but do dev on Windows in my day to day, and never bothered to learn Vim / Emacs.

I stick to Sublime on Windows, and when I need to tinker on my HTPC, I jump into nano, mainly because the command is memorable and the editor is very easy to use.

Wouldn't it make more sense for them to use joe then? joe comes with preconfigured hotkeys which are more "known" than C-o etc.

Never heard of it.

That same audience is also likely not choosing their editor much of the time. I've found that nano is the default editor often and if it's good enough, why would you mess with it?

I know when I search for something that is not a core interest of mine, I go with the first thing that Google shows me that meets my requirements.... I don't overthink that which is mostly unimportant to me.

joe! My first Unix-y text editor, but it's been vi/vim for 12 or 13 years now. Anyway, distros stopped including joe out of the box in favor of first pico and then nano, which is why it's not more popular.

Yeah, looking at wikipedia it seems joe was without a maintainer from 1995 to 2001. This likely leading to people adopting pico. But as pico was part of the pine email client, nano was made to be a free standing pico replacement.

Also, i guess pico/nano style key combos more "friendly" than the sequences joe uses (ctrl-k then another key to do anything).

Damn, i haven't touched it in years. But apparently i had it still installed.

And best i can tell nano happened because pico was popular but was part of the pine email client.

Also, from what i can gather joe was left unmaintained for a number of years, likely leading to people picking up pico, and then nano, as an alternative.

I'm a professional software developer, working in a mix of Windows, OSX, and Linux, and nano's still my go-to text-mode editor. Nano's got simple, easy-to-remember keyboard shortcuts, it's modeless, and it's more than powerful enough for the tasks I'm typically doing at the command line (editing git commit messages, light editing of config files, etc.).

When I need more features, I'd rather be in a GUI editor: Sublime or Atom for plain text editing, and the JetBrains IDEs or Visual Studio for projects where we're using a full IDE. I've yet to find anything in my workflow that would make it worth the time and effort to learn emacs or vim, beyond the basics needed to get around just in case one of them is the only thing available (coughGit for Windowscough).

I agree that coming from a Windows world I found there are many reasons to love Nano. It's easy to pickup and use plus it is rock solid even when working in large files.

That said, I noticed you labeled folks who use it "lower sophistication professionals". I don't think it's fair to label anyone who works with different technologies than you as such. They may work in a different part of the industry than you but that hardly makes them "less sophisticated". Maybe you find their tasks less challenging/exciting than the ones you work on but in all fairness they may find your tasks less challenging/exciting than the ones they work on.

After all Zuckerberg was at Harvard as a psychology major, Andrew Mason has a degree in Music, Tim Westergren from Pandora has a degree in political science and they are all examples of people who don't fit the uber nerd Steve Wozniak like programmer mold. There is hardly a reason to call people that build companies of that size "lower sophisticated professionals" yet they likely can't navigate emacs like you can.

I clarified my point as you were commenting. While the my label is accurate: you'd never hire these people to run large, complex, high volume infrastructure, it's not a value judgment on them.

So you'd never hire these people based on what editor they used but it's not a value judgement or you being derogatory..

That really doesn't come across well.

>.<

I've learned that in forums such as this, there is always someone to pick nits, drop context, read too literally, or otherwise not see the forest for the trees.

I've also learned not to worry about it.

Enjoy the rest of your day.

I'm a Product Manager (and have, in the past, been a sysadmin) and I fall into that camp. I prefer to use a GUI text editor, but use nano when I'm in a shell.

I have an emacs book on my shelf, and intend one day to learn emacs, but due to the nature of my work and spare time activities, I don't spend enough time in a text editor. It seems like it would take quite some before I was more efficient in emacs than I am with nano and a grep.

I started using nano (although I think I'd type pico to invoke it?) back when I used pine as my only email client. It has the same shortcuts as pine IIRC, so was easy to pick up.

For much of my career I was in the same camp you're in. I did field tech, sysadmin (Windows), and then went the IT management route for a long time. Early on I did pick up some vi, but only because in my field tech days I was working on small doctor office billing systems: single servers usually running Xenix(!) or SCO OpenServer(!) and vi was the only editor available: to this day I can reliably get into insert mode, save the file, and exit vi and no more without looking it up. Emacs I had the same breadth of skills until about a month ago. I always used a GUI text editor of some sort, though sometime specialized.

In more recent years, I've oddly enough become much more directly involved in software development. I live in Sublime Text and occasionally an IDE... Eclipse, Netbeans... QT Creator a fair amount. But I've been learning Emacs: I need to write estimates and, depending on the engagement, track time and such. I've found that, of all the online services and other software I have, the best tool to get things done was Emacs & org-mode with some fairly extensive config to customize the org-mode behavior; I even got Gnus up and running. I couldn't use it for coding because about 75% of what I do is database development (PostgreSQL schema stuff, PL/pgSQL) and I couldn't get the damn indentation behavior behaved so now I'm in both: Sublime Text for development and Emacs for organization.

I have used Vim, and I still use Emacs (Spacemacs), but a lot of the time, I just start up nano or leave it running for quick edits. I find I am in nano several times, and only sit with Emacs for coding because I don't like to leave Emacs running in the same way I can with nano.

I've been using linux/unix for 2 decades and I used pico/nano for ages. It's an intuitive and easy to use editor with on-screen help. For the vast majority of everyday uses it works just fine. And for the rare times when it's not suitable, there are plenty of tricks to working around nano's limitations. The main reason I started learning vim is just because I wanted to, not because I thought I was being held back by nano.

From a user perspective, it has huge critical mass in that short 'how-tos' tutorials invariably include screenshots of nano, as it is probably installed and can be easily used for simple tasks.

After years of attempting and failing hard to grasp Vim or Emacs, I've recently switched to nano and I'm very happy with it.

Vim and Emacs seem impenetrable to someone coming to them after they've been around for so long. Documentation and code is scattered all around, their concepts are not intuitive and there's so much stuff (modules, modes, whatever) available for both that I just feel paralyzed trying to decide what I need and what I don't. And then there's learning all the crazy key combinations and commands.

In contrast, the manpage for nanorc can be read in a few minutes. Keys work as expected and there's a helpful menu at the bottom. Shortcuts are all Ctrl+<something>. It's small, it's fast, and it does what I expect it to do: allow me to painlessly edit text files.

Probably I'm just the wrong type of person for nano then. I'm rather happy with Emacs (even with its mediocre performance).

I use Vim all the time, and I don't know how to do squat in it. Press `a` start typing, `:wq!` when done.

... Ok, that's a lie. I also know /, n, N, :noh for searching , dd to delete lines, and [{, ]} for jumping to delimiters.

That's as much as I know of vim, and I can do those same things in nano :)

I think 'a' is actually append. I think 'i' (for insert) is the correct way to start typing.

> Documentation and code is scattered all around

Vim and Emacs both have excellent built-in manuals.

I love nano, I've got absolutely no interest in vim or emacs. First things I do with it is set up colour highlighting, make it never break lines, and make it go into the background with ^Z.

If I'm ever held back by nano, I've got sublime text and rsub set up on my servers, so I can type "sublime /etc/whatever" on the remote computer, and it will pop up on my home computer.

^ Thanks for that trick, I didn't follow ST development too much recently.

I checked email with pine for ten years before succumbing to gmail. Once something's in your muscle memory, there's no reason to shift out.

I use Sublime or Spacemacs for Real Editing, Writeroom for distraction free writing. Ten second config file tweak? Doing something to J. Random Remote Server? nano's got my back.

It's popular because it's a text editor that you don't have to learn how to use. You just use it. I don't understand why, after all these years, people still think they can fool others into believing that they don't understand why others would choose nano over vim.

To borrow from an Arch discussion, it may well be that vi is something of a humblebrag.

I never liked nano. The only time I used it for a stretch was when for a year I used a non-GUI, X-less only environment for everything only old ThinkPad running Slackware. I was in University then. That was when I used Pine for email and Slrn for Usenet (and elinks for browser). While I remember using nano to edit emails in Pine (and later moving over to Emacs), I can't remember which editor I used inside Slrn.

I am a thorough Vim believer. I have been for a long time. If I ever accidentally find myself on a nix system with nano or pico as the default editor, I exit and install Vim.

However, in my almost 15 years using nix of all flavours, I have spent considerable time using Emacs as well, both on the GUI and the command line. Eventually, I gave up Emacs in favour of Vim. I've stuck to it since.

It may well be that you were not using nano but pico. It is part of pine, and i do believe that part of the reason nano got created was that a common question on distro lists etc was "where is pico?!".

And checking wikipedia i see that pine's license was at one point changed from a BSD-like to one that restricted third parties from distributing altered versions of pine. Something that naturally riled up the FSF.

It comes installed on servers and isn't a modal editor. Actually mostly the same reason Notepad is still used a lot on Windows.

Just guessing: you didn't grow up in a GUI world. When I'm ~45 I hope I'll know lots more about vim, until then, we're still cashing checks.

Ahh, also, I like to share the command line with other folks. Nano is the easier one to share. It comes with a manual! (trapped in vi PTSD anyone?, I certainly know one vim command. ":q")

Well if i get the history right it started out as a clone of pico, and pico was the editor part of the pine email client.

Meaning that the line break behavior kinda makes sense if your primary goal is writing emails, or similar long texts.

But for any kind of programming of config file editing it is indeed a problem.

Thankfully there is multiple ways to turn the behavior off.

Reply on news.ycombinator.com