Subject: Re: request for IncludePath

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 1 Feb 2002 11:14:14 +0000

On 01 Feb 2002 01:02:51 +0100, Peder Stray wrote:
> 
> Mikhael Goikhman <[email-masked]> writes:
> 
> > On 31 Jan 2002 14:46:01 -0600, [email-masked] wrote:
> > > 
> > > Message summary for PR#849
> > > 	From: [email-masked]
> > > 	Subject: request for IncludePath
> > > 
> > > Would be nice if fvwm got IncludePath, and search it when including files
> > > from the configuration. Now i have to patch in support for at least one
> > > extra directory to search (sitewide modularized setup requires this). 
> > 
> > It was thought in the past to add IncludePath, so instead of the current
> > 
> >   FVWM_USERDIR FVWM_DATADIR
> > 
> > this search order is used:
> > 
> >   FVWM_USERDIR IncludePath FVWM_DATADIR
> > 
> > Maybe it will be implemented sometimes in fvwm and modules...
> 
> that would be very much appreciated. sooner than later i hope ;)

Still you didn't described an example where this would be required. I can
invent artificial examples, but I want to see a real-life one where using
FVWM_DATADIR for system stuff and FVWM_USERDIR for user's is not enough.

Regards,
Mikhael.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Peder Stray <[email-masked]>
Date: 01 Feb 2002 12:42:24 +0100

Mikhael Goikhman <[email-masked]> writes:

> Still you didn't described an example where this would be required.
> I can invent artificial examples, but I want to see a real-life one
> where using FVWM_DATADIR for system stuff and FVWM_USERDIR for
> user's is not enough.

we (that is Institute for Informatics, University of Oslo, Norway)
have sitewide fvwm setup for all new users. Installed on at least 2
different architectures as of now... using a highly modularised setup,
where users can customize parts of the setup by making their own files
in FVWM_USERDIR, these would otherwise be included from the global
setup directory (same for all architectures). Other stuff from the
fvwm distribution would be included from FVWM_DATADIR.

-- 
[ IRL   : Peder Stray                               ]
[ "A new life awaits you in the off-world colonies" ]

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 1 Feb 2002 12:04:16 +0000

> fvwm distribution would be included from FVWM_DATADIR.

So you don't need more than one directory in IncludePath like I expected.

You want the situation #1:

  * The system stuff in /usr/share/fvwm-includes that is not FVWM_DATADIR
  * Have this command in user or system fvwmrc:
      IncludePath /usr/share/fvwm-includes

I suggest the situation #2:

  * The system stuff in FVWM_DATADIR, i.e. `fvwm-config --fvwm-datadir`
    (by default datadir is a shared directory)

For me (and probably for you) #2 is preferable, because it does not
require to add a hard coded path to configs.

My point is that if even fvwm-themes (pretty modular and fully
configurable setup) does not require IncludePath, maybe it is not needed.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Fri, 01 Feb 2002 07:04:09 -0500

> fvwm distribution would be included from FVWM_DATADIR.

Is there a reason you don't want to put the global stuff in
FVWM_DATADIR?

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Peder Stray <[email-masked]>
Date: 01 Feb 2002 13:18:57 +0100

> Is there a reason you don't want to put the global stuff in

up to seven differen flavours of unix, spred over 2-3 different
locations. i would think it would be nicer to keep our sitewide setup
seperate from files installed by fvwm.

---

From: Dan Espen <[email-masked]>
Date: Fri, 01 Feb 2002 11:17:55 -0500

> seperate from files installed by fvwm.

I think you'll find that PipeRead is the best way to deal with
multiple UNIX flavors and common configuration files.

---

From: Cameron Simpson <[email-masked]>
Date: Sun, 3 Feb 2002 15:23:41 +1100

On 13:18 01 Feb 2002, Peder Stray <[email-masked]> wrote:
| Dan Espen <[email-masked]> writes:
| > Is there a reason you don't want to put the global stuff in
| > FVWM_DATADIR?
| 
| up to seven differen flavours of unix, spred over 2-3 different
| locations. i would think it would be nicer to keep our sitewide setup
| seperate from files installed by fvwm.

Any reason not to use a symlink for this?

Example: at work we have a sitewide apache build installed (through magic)
in /opt/apache. But naturally an individual server has its own config and
logs.  The build-from-source was done with "--prefix=/opt/apache-1.3.23",
and so the daemon believes its configs are in /opt/apache-1.3.23/conf
and so forth.

But post install I moved the conf dir to conf-dist and make conf a
symlink to /var/apache/conf. On machines actauually running apache
one then makes /var/apache and copies conf-dist into the conf subdir
and customises.

Similarly for your setup you would have the config stuff (architecture
independent) symlinked to a central spot. Would this not work?
--
Cameron Simpson, DoD#743        [email-masked]    http://www.zip.com.au/~cs/

I've seen things you people wouldn't believe.  Attack ships on fire off the
shoulder of Orion. I've watched C-beams glitter in the dark near the
Tannhauser Gate.  All these memories will be lost in time, like tears in rain.
	- Roy Baty, _Blade Runner_
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Peder Stray <[email-masked]>
Date: 03 Feb 2002 11:19:29 +0100

> Any reason not to use a symlink for this?

you could, but that too would be more work than just have FVWM search
an additional path (taken from IncludePath or perhaps $FVWM_INCLUDE).

when i think about it $FVWM_INCLUDE would be really nice... that way
we could just set that variable depending on the users type and
location.

---

From: Dan Espen <[email-masked]>
Date: Sun, 03 Feb 2002 17:05:06 -0500

> we could just set that variable depending on the users type and

If thats what you want, you already have it:

Setenv X /usr/local/myconfig
Read $[X]

$X can be exported before Fvwm starts too.

---

From: Peder Stray <[email-masked]>
Date: 04 Feb 2002 12:12:53 +0100

Dan Espen <[email-masked]> writes:

> > when i think about it $FVWM_INCLUDE would be really nice... that
> > way we could just set that variable depending on the users type
> > and location.
> 

and the will seach the given path for files i include from the config?

what i wanted $FVWM_INCLUDE to do was too add a directory to the
include path, after FVWM_USERDIR, before FVWM_DATADIR.

---

From: Dan Espen <[email-masked]>
Date: Mon, 04 Feb 2002 07:23:34 -0500

> include path, after FVWM_USERDIR, before FVWM_DATADIR.

Well, you probably already realize that an environment variable
can serve as a generalized read path, but:

Setenv X /usr/local
Read $[X]/myconfig

In "myconfig":

Read $[X]/anotherconfigfile

...

Read $[X]/anotherconfigfile/inasubdirectory

but I still think you should be looking at PipeRead.
PipeRead will read configuration from anywhere you like and
provides the necessary flexibility to tailor the Fvwm configuration
as its read.