Re: startup file names (was: Ignore_Beep doesn't...)

["Klaus Schmid" <klaus.schmid@xxxxxx>]

----- Original Message -----
From: "Guenter Milde" <G.Milde@xxxxxxxxxxxxxxxxxxxx>
To: <jed-users@xxxxxxxxxxx>
Sent: Thursday, March 28, 2002 5:14 PM
Subject: startup file names (was: Ignore_Beep doesn't...)


> On Tue, 26 Mar 2002 13:04:16 -0500 wrote "John E. Davis"
<davis@xxxxxxxxxxxxx>:
>
> > Guenter Milde <G.Milde@xxxxxxxxxxxxxxxxxxxx> wrote:
> > >Feature request:
> > >
> > >could we have a more clear naming convention for the startup files?
> > >
> > >site.sl     is no longer a site-wide configuration file but provides
basic
> > >            jed functionality via Slang library functions. A name like
> > >            "libfuns.sl" or "basic.sl" would (IMHO) be more telling.
> >
> > This has been on my todo list for quite some time but since it is
> > merely cosmetic, it is not very high on this list.  I was thinking
> > jed.sl would be a better name.
>
> Well, IMHO it is not only cosmetic, but also a matter of clearity that
might
> attract/disturb new users of jed.
>

Although the mechanism is well documented (install, install.pc, jed.rc,
site.sl, ...),
as a casual Jed/Slang-scripter I would prefer 'easier' names as well.

>
> > [...]
> > >jed.rc      should become just a template, with a name telling this
(like
> > >            "template.rc" (finding telling names that fit into the 8.3
> > >            scheme is a really hard thing - suggestions welcome) and
> > >            that is *not* read in when no ~/.jedrc exists.
> > >
> > >            This way the user on a single-user OS that cannot copy
jed.rc to
> > >            .jedrc will not get his/her changes overwritten with every
> > >                release.
> >
> > The prefered (and documented) way is to create an environment variable
> > called "HOME" or "JEDHOME" and put the jed.rc file there.  That way,
> > updating jed will have no effect upon the user's personal jedrc file.
>
> While this is true, I don't like programs that need a bunch of environment
> variables to run. (Maybe this is becouse I had bad experiences with an
> overfull environment in the old DOS days, maybe just becouse I am lazy and
> prefer "out of the box" solutions.)
>
> Would a default "JEDHOME" for Win(DOS) that is different from
"JED_ROOT"\lib
> be an option?
>

To minimize os differences, It might be a good idea to have an empty
JED_ROOT/home directory (empty i.e. with only a readme file).
But see my proposals below...

>
> > >            Once we are at changing names, we could also to rename the
> > >            private configuration file that resides in the standard jed
> > >            library to rc.sl (to make clear that it is a slang file)
> >
> > Which "private" file do you have in mind?
>
> the user configuration file jed.rc.
>

To summarize my thoughts/proposals on that topic:

- site.sl could be renamed to jedlib.sl, to have it better associated with
jed.exe.

- defaults.sl, jed.conf could be substituted by _one_  jedsys.sl, to
associate it
better to system or system-manager.

- jed.rc, .jedrc could be substituted by _one_  jedini.sl  (of course the
same scheme
like edtini.edt on vax/vms. Why should it be a hidden file on
unix/linux...).

- an empty JED_ROOT/usr could be provided. Users/System-Managers may decide
to copy their existent/modified Jed_Sys or/and Jed_Ini files into this
directory.

- a global slang variable Jed_Sys could be provided/predefined -- in any
case -- before
Jed_Sys will be tried to load.
-- by environment variable JED_SYS (or maybe logical on vax/vms)
-- by lookup of file jedsys.sl in JED_ROOT/usr
-- if nothing succeeds: Jed_Sys= ""

- a global slang variable Home_Dir could be provided/predefined -- in any
case -- before
jedini.sl will be tried to load. Normal means of each os to retrieve the
home directory (sys$login, home, profiles,...) could be used. If nothing
succeeds, Home_Dir="". Same applies to other
user specific stuff which might be supplied by the system (user_name,...)

- a global slang variable Jed_Ini could be provided/predefined -- in any
case -- before
jedini.sl will be tried to load.
-- by environment variable JED_INI (or maybe logical on vax/vms)
-- by lookup of file jedini.sl in Home_Dir
-- by lookup of file jedini.sl in JED_ROOT/usr
-- if nothing succeeds: Jed_Ini= ""

- No problem should occur, if either Jed_Sys or Jed_Ini -- or both -- are
not present.
I.e. the stuff should be predefined best possible in jedlib.sl.

- Jed_Sys and Jed_Ini should be mutually exchangable. Single difference:
Jed_Sys will be
tried to be loaded at first and is forseen to supply useful
stuff/pre-definitions on multi-user systems.

- jedsys.sl and jedini.sl in JED_ROOT/lib should deserve merely as templates
to be copied
and modified to JED_ROOT/usr or any other location with the mechanism
described above.

Thanks
Klaus


--------------------------
To unsubscribe send email to <jed-users-request@xxxxxxxxxxx> with
the word "unsubscribe" in the message body.
Need help? Email <jed-users-owner@xxxxxxxxxxx>.