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

[Guenter Milde <G.Milde@xxxxxxxxxxxxxxxxxxxx>]

On Thu, 4 Apr 2002 00:52:08 +0200 wrote ks <klaus.schmid@xxxxxx>:

Lieber Klaus,

ich schreibe die ausführlichen Kommentare mal lieber in einer privaten mehl,
um die liste nicht mit zu langen Briefen zu überschütten.

> ----- Original Message -----
> From: "Guenter Milde" <G.Milde@xxxxxxxxxxxxxxxxxxxx>
> To: <jed-users@xxxxxxxxxxx>
> Sent: Wednesday, April 03, 2002 5:14 PM
> Subject: Re: Re: startup file names (was: Ignore_Beep doesn't...)
> 
> 
> > As Klaus has a more Windowish view, I'd like to add some rather Linuxish
> > thougts to it.
> 
> I try to be os-independant as jed. ;)
> Counted on years I am far more vaxish, a bit debianish
> and windowish without much fun.

I hope I did not offend you (maybe I did not recognize the vaxishness, as I
have no experience at all with VAXes). (and I wonder whether there is
anybody having fun with windows (besides MS) ;-)

 
> > For me, "system" is associated with operating system, i.e. stuff I'd not
> > touch to customize an editor (not even as sysadmin == "root"). How about
> > site.sl (as this becomes "free"), jedrc.sl or config.sl?
> 
> It seems linuxish is very near windowish, but quite different to
> vaxish. e.g.: On vax: sys$login (i.e. home), sys$print (default printer),
> sys$manager,... On windows: system folder, system.ini, system files, ...
> (most in windows folder, inherited danger ;)).

Unix has additionaly the host (but a site might consist of several hosts, if
it is a cluster of machines)


* OT: Hidden files under Unix

> Hmmm... Not so familiar with mixing "normal" files and other files in one
> directory. Hidden files are unknown on vax...  and bothering on windows
> imo. Anyway I would prefer a transparent organization.
> ...
> Isn't there a file attribut on unix to hide a file? (I fear not, and this
> way it should be allowed to break the tradition).

Hidden files are fairly transparent and a widely used standard under Unix.
There is no attribute, but the name tells whether a file is hidden
   ls     will not show any files and directories that start with a dot
   ls -a  will show all files
(and most filemanagers have a setting "Show hidden files")
This way, a lot of configuration stuff can be put in the users home
directory without interference of the daily work. (And as the scheme is
common, the average Unix user will use ls -a to find a configuration file as
easily as the Windows user will have a look in the registry or serach for a
config file.)

(Funnily enough: Windows has an attribute for hidden and a naming convention
for executables and Unix vice versa.)

* Templates
 
> > Simple solution for this: the distribution has the templates in
> JED_ROOT/doc.
> 
> More simpler (as written in a previous post): templates in JED_ROOT.
> Easier to find for users, no danger to mess up any jed sub folders.

IMO, templates are a kind of documentation - I would look for them there.
Also, they would/should show up in the Help>Browse_Docs menu. (BTW, why is
changes.txt not in the doc/ subdirectory?)

* Jed Directories

  User and Site-wide jed directories should reflect the structure of JED_ROOT
  (i.e. should have the subdirectories /lib and /doc) so that additional
  modules/modes can be accompagnied by documentation.


> As described, I would prefer just two variables: one which points to config
> file
> for all users, 2nd which points to personal config file. No need to
> introduce
> pointers to directories, because within these config files anyone can relate
> to
> supplement jed files in arbitrary directories and point to these by
> introducing
> corresponding variables if necessary. And from the two file pointers your
> script
> can easily derive two default directories, which a user may accept (or not)
> if
> any jed customizing stuff has to be stored.
> 
> To make it more clear: suppose your script reads and writes different files.
> If the user does not configure anything, the script will use the path
> (or maybe a subpath) of the 'user initialization file' to locate them.
> If the user prefers other directories for this usage, he has to define
> corresponding
> variables in his 'user initialization file'.


I'd like it the other way round: 2 pointers to the directories (with
sensible defaults)

   Setting up a directory for extensions is something I believe should be
   done by default, not triggered (or even worse programmed) in a
   configuration file.
   
   I'd offer 3 instead of 2 environment variables (additional: JED_RC_FILE)
   but gain more flexibility and transparency. In most cases, not all of
   them will be needed.
   
   Giving directory pointers is IMO more straightforward than to explain
   the user: If you set the variable JED_RC_FILE, its path is also taken as
   your JED_HOME
   
   The defaults for Jed_Site_Dir and Jed_User_Dir can still be changed in
   the config file (but will be used for finding the config file in the
   first place)
   

> My home's on xp:
> c:/Dokumente und Einstellungen/All Users/
> c:/Dokumente und Einstellungen/ks/
> 
> I think it is possible to retrieve these directories with common windows
> programming means (note the language-dependant directory names).
> 
> Is there an equivalent directory on linux/debian to store 'all user' data
> or has the .jedrc file to be copied or linked from ~ to \root?

There is no general consesus in the Unix world. Alternatives might be /etc,
/usr/etc, /usr/share and many more.

However, it is definitely not /root, as this is just the home directory of
the sysadmin.


MfG

Günter

--
G.Milde@xxxxxxxxxxxxxxxxxxxx


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