[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nano-devel] what to do about --disable-wrapping-as-root
From: |
David Lawrence Ramsey |
Subject: |
Re: [Nano-devel] what to do about --disable-wrapping-as-root |
Date: |
Thu, 24 Nov 2005 11:40:24 -0500 |
User-agent: |
Mozilla Thunderbird 1.0.7 (X11/20050923) |
Jordi Mallach wrote:
<snip>
>The reason this was added is Debian's installer uses nano in the case
>when a user choses to edit APT's sources list at the end of the
>installation phase.
>
>By default, nano would be wrapping lines and many newbie users would
>mess up their file, which needs to be 1 line per source.
I've heard about this. A lot of configuration files don't like wrapped
lines.
>Relying on a nanorc wasn't feasible because the system wasn't even
>completely installed yet, and shipping a default .nanorc for root in
>the nano package is a hack which I really dislike.
I suppose you'd dislike temporarily turning on nowrap in /etc/nanorc in
the package even more, then, since it's even more hackish. Am I right?
>Making debian-installer call nano --no-wrap is equally ugly, because
>the installer doesn't actually call nano, it calls "editor", which is a
>symlink to the current default text editor in the system. At install
>time, this is nano. The idea is that you call "editor" with no
>arguments and it "just works".
Understood. To think that this all comes down to Pico's having a bad
default (for us) in this case.
>So that left us with --disable-wrapping-as-root.
>
>My head is spinning a bit today, so I'm not sure if your proposal fixes
>any of these. Does it?
It depends. Adding the .nanorc for root would only apply if nano were
built with .nanorc support. nano-tiny, on the other hand, would have
all wrapping disabled. So if nano-tiny is used by the installer instead
of the normal version, then it would still work the way you'd expect.
(The only other way around this would be a configure option that would
reverse the wrapping default and the associated option, but that would
be even weirder and even less compatible with Pico...)