bugGNU nano - Bugs: bug #65810, commit 580eaf29 breaks existing...


You are not allowed to post comments on this tracker with your current authentication level.

bug #65810: commit 580eaf29 breaks existing uses of 'editor' as symlink to nano

Submitter:  Colin S <csnover>
Submitted:  Thu 30 May 2024 07:55:17 AM UTC
Votes: 20
Severity:  3 - Normal Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Jump to the original submission

Sat 13 Jul 2024 08:52:57 AM UTC, comment #8: 

The fix was released in nano-8.1.

Benno Schulenberg <bens>
Group administrator
Sat 08 Jun 2024 10:30:07 AM UTC, comment #7: 

Fixed in git, commit a98f82e2, by removing the sniffing for "e":


(Indeed, news items get written at release time, by going through all commits and all fixed items on Savannah.)

Benno Schulenberg <bens>
Group administrator
Fri 07 Jun 2024 10:04:07 PM UTC, comment #6: 

I just updated my Debian/testing system for the first time since nano 8 landed there and immediately got tripped up by this as well.

file #56135 here (patch dropping the argv[0] check) seems the most reasonable to me. A NEWS item should presumably be added as well, though it looks like that's just done at release time (as opposed to alongside the code change).

Thank you both for your attention to this!

David H <crookedwrench233>
Thu 06 Jun 2024 09:30:12 AM UTC, comment #5: 

It doesn't surprise me that no one else has reported this yet, because I think that there are not many people who use Debian 'unstable' or 'testing', and that most who do are more advanced and are likely to prefer some other editor, and that the few who prefer nano will have arranged their system to actually always use nano (exporting EDITOR and VISUAL, setting editor="nano +1" in their .gitconfig, ...) instead of relying on the `editor` symlink to give them nano.

Another reason for deciding against `mnano` is that I have a few other editors installed (for comparison purposes) and `joe`... installs three extra symlinks: jmacs, jpico, jstar.  I hate that.

Benno Schulenberg <bens>
Group administrator
Wed 05 Jun 2024 11:11:14 PM UTC, comment #4: 

Looks good to me, thanks! And thanks for the historical insight.

Regarding your remarks about a lack of feedback until now, I was surprised to be the first person to notice and report this. I know from personal experience that sometimes working on open source software can feel like sending work into a black hole. If that’s the case here, rest assured, you and your work are noticed and appreciated. :-)

Thanks again,

Colin S <csnover>
Tue 04 Jun 2024 09:59:32 AM UTC, comment #3: 

Yeah, `en` is not going to be obvious to anyone either.  What might be somewhat guessable would be `mnano`, analogous to `rnano`.  But... as I think that no one is going to type mnano (because anyone who wants to use the modern bindings is going to make an alias anyway: `alias mm="nano --modern"`), having an `mnano` symlink or script would just be bloat.  So... see the attached patch.

If no one is going to respond to https://lists.gnu.org/archive/html/nano-devel/2024-06/msg00000.html, the attached patch here is what I will apply.

(The grep maintainers were/are trying to get rid of egrep and fgrep not because those were a bad idea, but because they are not part of POSIX.  See for example: https://lists.gnu.org/archive/html/bug-grep/2022-10/msg00000.html.)

(file #56135)

Benno Schulenberg <bens>
Group administrator
Mon 03 Jun 2024 05:09:46 PM UTC, comment #2: 


Sorry about the delay and thank you for working quickly to resolve this report!

Just looking at the binaries that are installed on my local system, the distribution maintainers seem comfortable using shell scripts when needed to add options. grep, netpbm, ghostscript, xorg, 7z, vlc, and libreoffice are all packaged with such scripts. The grep example feels noteworthy to me as they have been trying to get rid of their variant executables since 2007[0], so presumably discovered from experience that it was a bad idea.

As such, my personal opinion would be to just not try to do this at all, but if it still feels valuable, I would probably recommend using a full name like `enano`. I would also recommend that it be documented in the manual in the NAME section (“nano, enano, rnano - Nano's ANOther text editor, inspired by Pico”) and in the OPTIONS section for `-/`, in the same way `rnano` is documented in the OPTIONS section for `-R`.


[0] https://www.phoronix.com/news/GNU-Grep-3.8-Stop-egrep-fgrep

Colin S <csnover>
Sun 02 Jun 2024 10:15:28 AM UTC, comment #1: 

Thanks for reporting.

Yeah, I hadn't expected this "sniffing" of the first letter of the executable to conflict with anything.  The original idea was to give distros the opportunity to install a symlink to `nano` that would activate the "modern bindings" without the user having to pass an option or edit their nanorc or create an alias, but I didn't think this through.

As there does not seem to exist a program called `en`, how about the attached patch?  It would install an `en` symlink by default, and nano would activate the modern bindings when the executable's name equals 'en'.

(file #56127)

Benno Schulenberg <bens>
Group administrator
Thu 30 May 2024 07:55:17 AM UTC, original submission:  

Dear Author,

The Debian alternative system[0] uses the executable name `editor` for anything that needs to spawn an editor. Commit 580eaf29d60734133c11f4ddb4b6aa06cdf33fdc creates a conflict with this existing use of an executable name starting with 'e'. After this change, invoking `nano` still uses the traditional keybindings, but any application that spawns an editor (e.g. `git commit`, `systemctl edit`, etc.) or any user that runs `editor` themselves suddenly gets different modern keybindings.

This behaviour is not documented in the nano man page, so it cannot be discovered by end users except by accident. Furthermore, as an end user, I would personally never expect an application to sniff an executable name like this, so would not look for or use this feature. Instead, if I wanted an alias, I would simply use the `alias` function of my preferred shell, or if necessary, write a one-line forwarding script like `nano --modernbindings $@`.

Whilst there are ways to work around this change downstream, given what seem like extremely marginal benefits to end users versus the new problem that it creates with longstanding existing uses of nano, it seems to me like it should just be removed, but this is just my opinion.

Best regards,

[0] https://wiki.debian.org/DebianAlternatives

Colin S <csnover>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by crookedwrench233 (Voted in favor of this item)
  • -email is unavailable- added by crookedwrench233 (Posted a comment)
  • -email is unavailable- added by bens (Updated the item)
  • -email is unavailable- added by csnover (Submitted the item)

    There are 20 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-07-13 bens Open/ClosedOpen Closed
    2024-06-08 bens StatusIn progress Fixed
    2024-06-07 crookedwrench233 Carbon-Copy- Added crookedwrench233
    2024-06-06 bens StatusNone In progress
    2024-06-04 bens Attached File- Added 0001-startup-no-not-activate-modernbindings-when-name-sta.patch, #56135
    2024-06-02 bens Attached File- Added install-en-symlink.patch, #56127
    2024-05-31 bens Assigned toNone bens
        SummaryCommit 580eaf29d60734133c11f4ddb4b6aa06cdf33fdc breaks existing uses of 'editor' as symlink to nano commit 580eaf29 breaks existing uses of 'editor' as symlink to nano

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code