1.1 About this FAQ.
1.2. How do I contribute to it?
1.3. What is nano?
1.4. What is the history behind nano?
1.5. Why the name change from TIP?
1.6 What is the current version of nano?
1.7. I want to read the man page without having to download the program!
2.1. FTP and WWW sites that carry nano.
2.2. Redhat and derivatives (.rpm) packages.
2.3. Debian (.deb) packages.
2.4. By CVS (for the brave).
3.1. How do install the RPM or DEB package?
3.2. Compiling from source: WHAT THE HECK DO I DO NOW?
3.3. Why does everything go into /usr/local?
3.4. I get errors about 'bindtextdomain', 'gettext' and/or 'gettextdomain'. What can I do about it?
3.5. Nano should automatically run strip on the binary when installing it!
4.1. Ack! My backspace/delete/enter/double bucky/meta key doesn't seem to work! What can I do?
4.2. Nano crashes when I type <insert keystroke here>!
4.3. Nano crashes when I resize my window. How can I fix that?
4.4. Why does nano show ^\ and ^_ in the shortcut list instead of ^G and ^J?
4.5. When I type in a search string, the string I last searched for is already in front of my cursor! !What happened?!
4.6 How do I make nano my default editor (in Pine, mutt, etc.)?
5.1. There's no translation for my language!
5.2. I don't like the translation for <x> in my language. How can I fix it?
6.1. Why should I use nano instead of Pico?
6.2. Why should I use Pico instead of nano?
6.3. What is so bad about the PINE license?
6.4. Okay, well what mail program should I use then?
6.5. Why doesn't UW simply change their license?
6.6. What if tomorrow UW changes the license to be truly Free Software?
7.1. Nano related mailing lists.
7.2. I want to send the development team a big load of cash (or just a thank you).
7.3. How do I submit a patch?
7.4. How do I join the development team?
7.5. Can I have CVS write access?
This FAQ was written and is maintained by Chris Allegretta <chrisa@asty.org>, who also happens to be the creator of nano. Maybe someone else will volunteer to maintain this FAQ someday, who knows...
Your best bet is to send it to the nano email address, nano@nano-editor.org and if it is useful enough it will be included in future versions.
Nano is designed to be a free replacement for the Pico text editor, part of the PINE email suite from The University of Washington. It aims to "emulate Pico as closely as possible and perhaps include extra functionality WITHOUT breaking compatibility with Pico.
Funny you should ask!In the beginning...
For years Pine was THE program used to read email on a Unix system. The Pico text editor is the portion of the program one would use to compose his or her mail messages. Many beginners to Unix flocked to Pico and Pine because of their well organized, easy to use interfaces. With the proliferation of Linux in the mid to late 90's, many University students became intimately familiar with the strengths (and weaknesses) of Pine and Pico.
Then came debian...
The debian GNU/Linux distribution, known for its strict standards in distributing truly "free" software (i.e. had no restrictions on redistribution), would not include a binary package for Pine or Pico. Many people had a serious dilemma: they loved these programs, but they were not truly free software in the GNU sense of the word.
The event...
It was in late 1999 when Chris Allegretta (our hero) was yet again complaining to himself about the less-than-perfect license Pico was distributed under, the 10000 makefiles that came with it and how just a few small improvements could make it the Best Editor in the World (TM). Having been a convert from Slackware to debian, he missed having a simple binary package that included Pine and Pico, and had grown tired of downloading them himself.
Finally something snapped inside and Chris coded and hacked like a madman for many hours straight one weekend to make a (barely usable) Pico clone, at the time called TIP (Tip Isn't Pico). The program could not be invoked without a filename, could not save files, had no help menu, spell checker, and so forth. But over time it improved, and with the help of a few great coders it matured to the almost stable state it is today.
On January 10, 2000, TIP was officially renamed to nano because of a namespace conflict with another program called 'tip'. The original 'tip' program "establishes a full duplex terminal connection to a remote host", and was included with many older Unix systems (and newer ones like Solaris). The conflict was not noticed at first because there is no 'tip' utility included with most Linux distributions (where nano was developed).
The current version of nano *should* be 0.9.21. Of course you should always check the nano hompage to see what the latest and greatest version is.
Jeez, demanding, aren't we? Okay, look here.
The nano distribution can be downloaded at the following fine web and ftp sites:
Additionally, check out the Redhat contribs section at:
For debian users, you can check out the current nano packages for: Note that versions < 0.9.10 are probably not for those wanting to get serious work done, so until the stable distribution has an updated version of nano, you are best off using the one in unstable for now.
For the 'bleeding edge' current version of nano, you can use CVS to download the current source code. Note: believe it or not, by downloading code that has not yet stabilized into an official release, there could quite possibly be bugs, in fact the code may not even compile! Anyway, see the nano CVS page for info on anonymous CVS access to the nano source.
It's simple really! As root, type rpm -Uvh nano-x.y.z-1.i386.rpm if you have a Redhat-ish system or dpkg -i nano_x.y.z-1.deb if you have a Debian-ish system, where x.y.z is the release of nano. There are other programs to install programs, and if you wish to use those, knock yourself out.
Okay, take a deep breath, this really isn't hard. Unpack the nano source with a command like:tar -zxvf nano-x.y.z.tar.gz
If you get error messages about the -z option, try this:
gzip -dc nano-x.y.z.tar.gz | tar xvf -
(again, where x.y.z is the version number in question). Then you need to run configure with any options you might want (if any).
The average case is this:
./configure
make
make install (as root, of course)
Well, that's what the configure script defaults to. If you wish to change this, simply do this:./configure --prefix=/usr
to put nano into /usr/bin when you run make install.
Try doing a ./configure --with-included-gettext and see if that solves your problem. You make need to do a make clean ; make to get it to work fully.
Actually, it does, but you have to use make install-strip. The default make install does not, and will not, run strip automatically.
Try setting your $TERM variable to 'vt100'. Nano doesn't yet support every term entry under the sun.Bourne shell users (like bash): export TERM=vt100
C Shell users (tcsh and csh): setenv TERM vt100
If you aren't trying some bizarre keystroke combination with some bizarre $TERM entry, chances are you have found a bug. You are welcome to submit it to the nano-devel list or to nano@nano-editor.org.
Older versions of nano had this problem, please upgrade to a newer version (at least 0.9.9 would be great, 0.9. 12 is recommended).
The help (^G) and justify (^J) functions were among the last to be written. To show the improvements that nano had over Pico (goto line # and replace), ^_ and ^\ were put on the shortcut list. If you use the -p option to nano you will get the same shortcuts at the bottom as Pico.
In nano version 0.9.21, the default is to have a completely consistent user interface across all user input functions. This means that regardless of whether you're being asked for a filename to insert or write, or a string to search for, the previous value is already inserted before the cursor. If you prefer the old behavior, use the pico emulation mode (-p or --pico) or just hit Meta-P while in nano (see the ^G help text for more details).
You need to make nano your $EDITOR. If you want this to be saved, you should put a line like this in your .bashrc if you use bash:export EDITOR=/usr/local/bin/nano
or if you use tcsh put this in your .cshrc file:
setenv EDITOR /usr/local/bin/nano
Change /usr/local/bin/nano to wherever nano is installed in your system. Type which nano to find out. This will not take effect until the next time you login. So log out and back in again.
Then on top that if you use Pine you must go into setup (type S at the main menu), then configure (type C). Hit enter on the lines that say:
[ ] enable-alternate-editor-cmd
[ ] enable-alternate-editor-implicitlyThen exit (E) and select Yes (Y).
Mutt users should see an effect immediately the next time you log in, no further configuration is needed. However, if you want to let people know you use nano to compose your email messages, you can put a line like this in your .muttrc:
my_hdr X-Composer: nano x.y.z
Again, replace x.y.z with the version of nano you use.
So, uh, get someone who speaks your native language to write one =-). Just grab the nano.pot file from the latest and greatest nano distribution (it's in the po/ directory) and translate each line into your native language on the msgstr line. Then send it to the nano devel list or nano@nano-editor.org.
The best way would probably be to e-mail the person listed in the <your_language>.po file with your suggested corrections and they can in turn forward it to the nano email address, or the devel list.
There are many reasons to use nano instead of Pico, a more complete list can be found at the nano homepage.
Again, check out the nano homepage for a good summary of reasons. It really is a matter of personal preference as to which editor you should use. If you're the type of person who likes using the original version of a program, then Pico is the editor for you. If you're looking for a few more features and a 'better' license as far as adding your own changes (sacrificing mailer integration and a little stability), nano is the way to go.
Technically there is nothing "wrong" with the U of W license for Pine and Pico. However, it is not considered truly "free" according to the Debian Free Software Guidelines. The only real problem as far as I'm aware as that there are limitations on the redistribution of programs based on the Pine and Pico source. So at a real nitty gritty level, these programs are not considered Free Software. This is why Pico isn't distributed in binary form in debian, and hence one of the main reasons nano was started.
Well, there is nothing stopping you from using Pine with nano (or Pine with Pico for that matter). But if you want to use programs that are considered Free Software, you may want to look into mutt. It is a full-screen, console based mail program that actually has a lot more flexibility than Pine, but has a keymap included in the distribution that allows you to use the same keystrokes as Pine would to send and receive mail. It's also licensed under the GPL.
You're really not asking the right person here. I (Chris) waited a long time to see if UW would change their license because of the amount of high quality software being released and developed under the GPL without being taken advantage of by malicious corporate entities or other baddies, but no such luck so far.
Honestly nothing would make me happier than to see that happen. Nano would continue to be developed independently until such time as Pico had all the features nano did or the projects merged. That just does not seem very likely given that there has been no sign of any changes in the past few years in a positive direction.
There are two mailing lists for nano hosted at SourceForge, nano-announce and nano-devel. Nano-announce is a very low traffic list where new versions of nano are announced (surprise!) Nano-devel is a sometimes low, sometimes very high traffic list for dicussing the present and future development of nano. Here are links to where you can sign up for a given list:nano-announce - http://lists.sourceforge.net/mailman/listinfo/nano-announce
nano-devel - http://lists.sourceforge.net/mailman/listinfo/nano-devel
That's fine. Send it our way! Better yet, fix a bug in the program or implement a cool feature and send us that instead (though cash is fine too).
See Section 7.2.
The easiest way is to consistently send in good patches that add some needed functionality, fix a bug or two and/or make the program more optimized/efficient. Then ask nicely and you will probably be added to the SourceForge development list and be given CVS write after awhile. There is a lot of responsibility that goes along with being a team member, so don't think it's just something to add to your resume.
Re-read Section 7.4 and you should know the answer.
06/31/2000 - Initial framework.
$Id$