GNU nano 8.0 released

Posted May 1, 2024 21:16 UTC (Wed) by sub2LWN (subscriber, #134200)
In reply to: GNU nano 8.0 released by josh
Parent article: GNU nano 8.0 released

> Above modern bindings are activated also when the name of nano's
> executable (or a symlink to it) starts with the letter "e".

Does this mean nano could be installed as "emacs" to activate the new bindings? :-) Not that this would ultimately help users, of course.

GNU nano 8.0 released

Posted May 1, 2024 21:41 UTC (Wed) by josh (subscriber, #17465) [Link] (6 responses)

I am curious what use case they had in mind to motivate "starts with e" over "is this exact name".

GNU nano 8.0 released

Posted May 1, 2024 22:33 UTC (Wed) by fraetor (subscriber, #161147) [Link]

From the commit message:

This allows activating the "modern" bindings without having to pass an option, by simply invoking nano through a symlink -- for example: `en` (short for "editor nano"), or `et` (short for "edit"), or just `e`.

GNU nano 8.0 released

Posted May 1, 2024 22:35 UTC (Wed) by coriordan (guest, #7544) [Link] (3 responses)

My guess was so that it covers "edit" and "editor".

I found the mail where this change was announced on the dev list: https://lists.gnu.org/archive/html/nano-devel/2023-02/msg...

...but the replies don't raise or answer your question. I guess it's just an arbitrary decision between two fine options.

GNU nano 8.0 released

Posted May 2, 2024 0:47 UTC (Thu) by sub2LWN (subscriber, #134200) [Link] (2 responses)

I looked at the code to see if it uses argv 0 or actually checks the paths (/proc/self/cmdline vs /proc/self/exe), and it does the former. There's a similar rule next to it in nano.c for an "r" at the beginning of the command-name, to enable restricted mode:

if (*(tail(argv[0])) == 'r')
SET(RESTRICTED);
else if (*(tail(argv[0])) == 'e')
SET(MODERN_BINDINGS);

So the logic was likely based on the restricted code (which is also in nano 2.9.8 which I have on my system). Unfortunately it's mutually exclusive :-( can't invoke nano as "err" and have a restricted editor with modern bindings.

"git blame nano.c" says the earlier argv check for restricted mode was added 2017-12-29 so perhaps there's more rationale in an old changelog or message somewhere.

GNU nano 8.0 released

Posted May 2, 2024 5:29 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

Restricted mode is frankly not very useful. If you want to let somebody edit a file, the proper way to do it is to copy the file into /tmp with permissions set so that they can read and write it, let them edit it in-place with an unprivileged editor, and then copy it back. If you need to do something more elaborate than that, then you probably should be reaching for a container or VM, not restricted mode.

GNU nano 8.0 released

Posted May 3, 2024 5:43 UTC (Fri) by grawity (subscriber, #80596) [Link]

I'm reminded of the various captive interfaces I've seen back in the day, when shell accounts and telnet/ssh BBSes were more of a thing. They used restricted editors because the user (e.g. a free BBS-only user with no shell access) wasn't supposed to do anything in the account even in places where their UID would've granted them the access.

Spinning up a new VM for each user wasn't an option back then.

GNU nano 8.0 released

Posted May 1, 2024 23:00 UTC (Wed) by sub2LWN (subscriber, #134200) [Link]

Whatever their motivation, the e-ffects of this change may cause some users to change how they perceive and use argv 0: Rethinking Argv 0. :-)

My first thought was to overload argv to make distinct instances of the e* editor (as I'll now remember nano), such that you could kill a particular one when several are running (elinux, eblog, ecommerce, enlightenment).

I tried "$ (exec -a en nano)" in bash, and that seems to change argv and /proc/self/cmdline for that process to the new name. I don't have the new e* v8 yet to check the modern bindings however.

(Un)fortunately this doesn't affect the likes of "pgrep electricnano" by default, and needs "pgrep -f electricnano; pkill -f electricnano" to use the process cmdlines. I suspect this is due to /proc/self/exe being a symlink to the real path, and the design of certain tools limiting trust in user inputs to prevent complete chaos. The given argv 0 does show up in "ps a" and "systemctl status".