Re: stretch update overwrites nano file
- Date: Tue, 27 Nov 2018 06:54:38 +0000
- From: Tixy <tixy@xxxxxxxxxx>
- Subject: Re: stretch update overwrites nano file
On Tue, 2018-11-27 at 00:30 +0000, Brian wrote:
> On Mon 26 Nov 2018 at 17:03:35 -0600, David Wright wrote:
> > On Mon 26 Nov 2018 at 16:31:38 (+0000), Bonno Bloksma wrote:
> > > What I just DID notice is that the upgrade replaced ALL nanorc
> > > files in the /usr/share/nano/ directory. All ca. 30 default files
> > > with timestamp Jul 16 2014 are gone and my default.nanorc file of
> > > a later date is gone as well.
> > > There are now around 40 files with timestamp Jan 11 2017.
> > AIUI those files are part of the nano package, so the upgrade
> > upgrades
> > them. It would be nice if one could substitute one's own foo.nanorc
> > file in a location like /etc/nano/ but I don't think the code for
> > that
> > has been written into the program.
> As you say, anything in /usr/share/ is under the control of the
> packaging system and in, this case, "my default.nanorc" is not the
> user's default.nanorc but the system's. It can do what it wants with
> it. There is no bug here.
> > > There was no warning that it was going to do so. Worse there are
> > > NO *.nanorc.dpkg-old files to replace the new color schemes with
> > > my old ones.
> > I think that facility only takes place for conffiles, and those
> > files
> > aren't conffiles. If they were, they would have to reside under
> > /etc.
> Correct. Why should there be any warning when the packaging system
> is only doing what it is designed to do? A user would alter nano's
> behaviour in $HOME.
For the OP who probably isn't reading the list... The man pages for
nano (command "man nano") says at end "See Also nanorc", and "man
During startup, nano will first read the system-wide settings, from
/etc/nanorc (the exact path might be different), and then the user-
specific settings, from ~/.nanorc.
So, the correct file to customise nano settings is either of those two