bugGNU nano - Bugs: bug #60307, [Request] nanorc.d style config

 
 

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

bug #60307: [Request] nanorc.d style config

Submitter:  Paul Chernysh-Barr <nassbar>
Submitted:  Tue 30 Mar 2021 03:45:22 AM UTC
   
 
Severity:  1 - Wish Status:  Wont Fix
Assigned to:  None Open/Closed:  Closed

Tue 20 Apr 2021 09:29:27 AM UTC, comment #4: 

Nano is a user tool -- its configuration should be under full control of the user.  In my opinion, system admins should not be modifying /etc/nanorc after the system has been first set up, nor should the installation of any other packages affect the way that nano works.  So checking an /etc/nanorc.d/ directory is not a good idea (and would only waste time).

Benno Schulenberg <bens>
Group administrator
Sun 04 Apr 2021 03:17:11 PM UTC, comment #3: 

I'm amazed.  You work for an organisation that has its own developers, but you /request/ a feature instead of providing a patch?  You want me to do your work for you, for free?

Anyway.  If I understand correctly, some groups of users in your organisation will get nano configured (by default) somewhat differently than the agreed upon standard.  (By the way: what is that agreed-upon base configuration?  I'm curious whether it's any different from Debian's defaults.)  But if the admins that are responsible for the divergent configurations want to keep these configurations stable (unaffected by possible changes in the main /etc/nanorc), it would mean they have to explicitly set or unset each and every option that nano knows.  What a waste of effort that would be.  To me it seems obvious that /etc/nanorc should not be managed centrally, but by each group's admin.

Anyway.  For 1) all you need is /etc/nanorc.  And for 2) it would be enough if nano additionally read an /etc/nanorc.local, if it existed, right?  No need to read a random number of files from a nanorc.d directory.

Benno Schulenberg <bens>
Group administrator
Sat 03 Apr 2021 06:41:48 AM UTC, comment #2: 

In my organisation we have a number of admin, support, and developer staff that have differences of opinion on what should and shouldn't be configured.

1) At the organisation level we'd like to define the system-wide agreed standard (80/20 rule), which not hacking a change to the upstream version.

This means the configuration becomes managed for 80% of the system users, and can be conformed if/when there are changes in the future.

and...

2) Because there is always someone (the 20%) who does not agree with particular options, or just likes to have different color/highlight rules, etc.

So while they can potentially adopt configuration/features that they might not previously have been made aware of, they can continue to utilise the existing functionality of creating their own.

Essentially the desired outcome of this change is to eliminate/reduce the overhead, and potential error in configuration that all users currently need to create their own overrides, as we cannot package a system-wide configuration currently.

(not sure if that's two, but more the rationale to this wish item)

Paul Chernysh-Barr <nassbar>
Wed 31 Mar 2021 08:36:27 AM UTC, comment #1: 

You mean that any package (other than nano itself) could drop some nanorc fragment in /etc/nanorc.d/, and then nano would read it after /etc/nanorc has been read and before ~/.nanorc would be read?  When would this be useful?  Please give two examples.

Benno Schulenberg <bens>
Group administrator
Tue 30 Mar 2021 03:45:22 AM UTC, original submission:  

This request is to add functionality to allow includes of system-wide configuration to override the configuration commonly in /etc/nanorc via something like including files in /etc/nanorc.d/* (purely for example).

While there are means override the system-wide configuration for each user, short of editing the /etc/nanorc configuration file there is no clean/simple means for a vendor to package overrides.

Paul Chernysh-Barr <nassbar>

 

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

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by nassbar (Submitted the item)
  •  

    There are 0 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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-04-28 bens Open/ClosedOpen Closed
    2021-04-20 bens StatusNone Wont Fix
    2021-03-31 bens Severity3 - Normal 1 - Wish

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code