#34 load system-wide RC file

open
Bruno Haible
5
2007-11-02
2007-10-31
Sam Steingold
No

On startup, CLISP loads a user RC file (~/.clisprc),
but no system-wide RC files (e.g., /etc/clisprc).
see http://clisp.cons.org/impnotes/clisp.html#opt-norc
http://clisp.cons.org/impnotes/image.html

Proposal:
1. interactive sessions load /etc/clisprc (.lisp or .fas)
unless called with -norc-global (or -norc, see [2] below)
2. -norc suppresses both global and user RC files
3. -norc-user suppresses user RC file
but not the global one.
4. saveinitmem accepts :norc-global and :norc-user in addition to :norc which overrides their defaults but is overriden by them.
5. batch sessions (script execution) do not load any RC files, like now.

Issues:
1. where should the global rc file reside on win32? (c:\.clisprc - but does c: make sense under vista?)
2. which file should be loaded first: system-wide or user? (system should come first so that the user can override some settings)

Rationale:
1. stumwm apparently wants this
2. sbcl loads /etc/sbclrc; bash loads /etc/bashrc
3. emacs loads two system RC files: one before the user and one after.

Discussion

  • Bruno Haible
    Bruno Haible
    2007-10-31

    Logged In: YES
    user_id=5923
    Originator: NO

    We discussed this topic already on 2001-07-13:
    <http://sourceforge.net/mailarchive/forum.php?thread_name=15183.17196.122174.985830%40honolulu.ilog.fr&forum_name=clisp-list>

    In practice, such system-wide config files (like /etc/profile) have
    the property of annoying more users than of being useful to them.
    (I am here speaking about experience with /etc/profile on SuSE Linux.)

    What can /etc/clisprc do that $HOME/.clisprc and saveinitmem cannot?

    - If you are a democratic sysadmin or Lisp course teacher, you can
    tell your users or students to create a $HOME/.clisprc containing
    the line

    (load "/etc/clisprc")

    - If you are a fascist sysadmin, you can add this line to your users'
    $HOME/.clisprc without asking them. :-)

    - If you are a Linux distributor, you can add your stuff to config.lisp
    before building clisp. It will then end up in the memory images
    automatically.

    Regarding your "rationale":
    - stumwm (or any particular program) is not an argument. The program can
    be written so that it performs its initializations by itself, when it is
    invoked.
    - What other programs do (bash, sbcl, emacs), is irrelevant. Just because
    these programs allow fascist sysadmins to rule their users, clisp does not
    need to do the same. Please see also the section "Why GNU su does not support
    the 'wheel' group" in
    <http://www.gnu.org/software/coreutils/manual/html_node/su-invocation.html>

     
  • Jack D. Unrue
    Jack D. Unrue
    2007-11-01

    Logged In: YES
    user_id=119851
    Originator: NO

    Regarding location on win32, it's not uncommon to place such global config files somewhere within an application's install directory tree. I wouldn't recommend either c:\ or c:\windows

    If we ever get to the point where we have a native installer, then the installer could present some degree of customization, perhaps just a couple of options or full control over the entire contents of the file.

     
  • Sam Steingold
    Sam Steingold
    2007-11-01

    • assigned_to: sds --> nobody
     
  • Sam Steingold
    Sam Steingold
    2007-11-01

    Logged In: YES
    user_id=5735
    Originator: YES

    >> We discussed this topic already on 2001-07-13:
    >><http://sourceforge.net/mailarchive/forum.php?thread_name=15183.17196.122174.985830%40honolulu.ilog.fr&forum_name=clisp-list>

    time flies like an arrow (however, fruit flies like a banana!)

    >> What can /etc/clisprc do that $HOME/.clisprc and saveinitmem cannot?

    - not having to modify each new user's .clisprc and
    - not having to re-dump a memory image on each clisp upgrade or small /etc/clisprc modification

    >> - If you are a democratic sysadmin or Lisp course teacher,
    >> you canell your users or students to create a $HOME/.clisprc
    >> containing the line (load "/etc/clisprc")

    customizability is no substitute for good defaults.
    similarly, half the users will forget or ignore.
    not loading the system-wide RC is a matter of a command-line switch,
    so it does not look like a big deal.

    >> What other programs do (bash, sbcl, emacs), is irrelevant.
    >> Just because these programs allow fascist sysadmins to rule their users,
    >> clisp does not need to do the same. Please see also the section
    >> "Why GNU su does not support the 'wheel' group" in
    >> <http://www.gnu.org/software/coreutils/manual/html_node/su-invocation.html>

    does it not strike you as peculiar that the same RMS added two(!) system-wide
    emacs init files and wrote the above diatribe?
    I have always been blessed with benign sysadmins, so, I guess, I should not
    say that the system-wide init files are not related to fascism, but the
    connection seems tenuous at best.

     
  • Sam Steingold
    Sam Steingold
    2007-11-02

    • assigned_to: nobody --> haible
     
  • Sam Steingold
    Sam Steingold
    2007-11-02

    Logged In: YES
    user_id=5735
    Originator: YES

    another use for system-wide RC file is hooks for 3rd party packages who can add LOADs and hooks there.

     
  • Jörg Höhle
    Jörg Höhle
    2007-11-13

    Logged In: YES
    user_id=377168
    Originator: NO

    I still don't see the value of this modification to clisp given that it looks to me like it could be trivially implemented using custom:*init-hooks*.
    http://clisp.cons.org/impnotes/custom-init-fini.html
    It looks like this hook is invoked right at the good place, not too late, not too early.

    Debian/Ubuntu create their own dump image for the installed clisp. If they wanted to provide a system wide (dynamic) initialization file (as opposed to statically present in the dump), they could use this variable.
    When installing new packages (or some of them?), Debian redumps all installed Lisp's images IIRC. At least I've seen my computer redump sbcl, cmucl and clisp here and then.
    E.g. if sbcl on Debian loads /etc/xyz, clisp on Debian could do the same.
    Heck, we could even describe this example in the manual.

    I don't know how stumwm works, but I recommend it starts from a suitable image instead of starting from the generic one loading all stumwm libraries. Why can't stumwm then use *init-hooks*?

    The mingw32 version distributed by Arseny and Reini could include a *init-hooks*.

    Perhaps in 2001, when the feature request was originally submitted, there was no *init-hooks*? Written in Lisp, that function would benefit from Lisp-level pathname handling and dirkey API to possibly access registry keys on MS-Windows.

    Regards,
    Jörg Höhle

     
  • Sam Steingold
    Sam Steingold
    2007-11-13

    Logged In: YES
    user_id=5735
    Originator: YES

    *init-hooks* is run before the splash screen, it is too early for an RC file