bug 219448
G. Milde
g.milde@web.de
Mon, 2 May 2005 11:06:14 +0200
On 1.05.05, Jörg Sommer wrote:
> [Cc-ing John, maybe he can help.]
>
> Hello,
>
> this bug [1] is really interesting.
(subject is "please allow /etc/jed-init.d/ to override global settings",
IMHO, this is easier to understand than bug 219448)
> The problem is this:
> please allow /etc/jed-init.d/ to override global settings
> $ xjed -batch
> loading /usr/share/jed/lib/site.slc
> loading /usr/share/jed/lib/os.sl
> loading /usr/share/jed/lib/menus.slc
> loading /etc/jed.conf
>
> Here a admin may make system wide setting
>
> loading /etc/jed-init.d/00debian.sl
Or here, in any file that resides in /etc/jed-init.d/ as all these will
be loaded at every startup.
> loading /usr/share/jed/lib/jed.rc
>
> and here they get overwritten by jeds default settings.
(If and only if the user doesn't have a ~/.jedrc file.)
> /etc/jed.conf become loaded at the end of site.sl. jed.rc become loaded
> by the command line hook, which is called after site.sl has quit. This
> must change, we can't make system wide settings before program defaults.
Maybe we could persuade John to renounce the "catchall" loading of
JED_ROOT/lib/jed.rc as this is clearly not "the right way" to provide
defaults.
Maybe one could abandon the complete Default_Jedrc_Startup_File custom
variable and load mechanism.
The only difference of "site administrator customisation" I see between
using
defaults.sl or jed.conf
vs
setting Default_Jedrc_Startup_File and providing this file
is the possibility to disable the Default_Jedrc_Startup_File with the -n
command line option. (However, this disables the users jedrc too.)
But maybe I am missing something here.
> I would say, we should remove /usr/share/jed/lib/jed.rc
I would not remove JED_ROOT/lib/jed.rc, as the original jed documentation
refers to it as a reference (a la "copy ... to ~/.jedrc and adapt to your
needs...").
> and put it at the beginning of /etc/jed.conf
This should not be necessary, as JED_ROOT/lib/jed.rc just reflects the
default settings. AFAIK, early versions of jed depended on some variable
definitions done in jed.rc (or .jedrc) but this is solved since some time
now. (And `jed -n` should give errors at some stage otherwise.)
> and set Default_Jedrc_Startup_File to NULL to prevent jed.rc is
> searched by command_line_hook().
This will suffice.
> Does anyone know, why a command_line_hook is necessary?
To make things more complicated? ;-)
Well, it allows the user (in .jedrc) or the site-administrator to
overwrite the command_line_hook. (Unfortunately, that this hook is
quite long.)
My filelist.sl documents an example use of this feature:
% Problem: Currently, a relative filename is expanded before passing
% it to the _jed_find_file_before_hooks, with the side-effect of
% "http://host.domain" becoming "/host.domain"
% -> find_file doesn't work for URIs with a double slash
%
% If you want to be able to start jed with e.g.
% jed http://jedmodes.sf.net/mode/uri/
% you can copy the 194 lines of the command_line_hook from site.sl
% to your .jedrc and modify the 6.-last line from
% () = find_file (next_file_arg);
% to
% () = find_uri (next_file_arg);
--
G.Milde web.de