Subject: new read logic

From: Matthias Clasen <[email-masked]>
Date: Thu, 8 Apr 1999 22:40:02 +0200

the new read logik doesn't quite behave as advertised:
I have $HOME/.fvwm2rc and no $HOME/.fvwm subdir and I don't export
FVWM_USERHOME. If I start fvwm from my home dir, everything is ok,
but if I start from somewhere else, it doesn't find my .fvwm2rc and I get

[FVWM][Read]: <<ERROR>> file 'fvwm2rc' not found, looked for ..fvwm2rc and
/usr/local/etc/fvwm2rc

(note that there is a '/' missing in the error message between '.'
(the value of user_home_ptr) and '.fvwm2rc'.)

The problem is that fvwm never tries to look in $HOME/.fvwm2rc, since
user_home_ptr is either $FVWM_USERHOME or './.fvwm' or '.'

Matthias

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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: Dan Espen <[email-masked]>
Date: Fri, 09 Apr 1999 08:50:04 -0400

> but if I start from somewhere else, it doesn't find my .fvwm2rc and I get

I was  hoping to avoid  the condition  created by starting  fvwm2 from
other than  $HOME.  I don't  think everything  worked correctly in the
past  when this  was  done.    For   example, FvwmAnimate saved    its
configuration in  the  current directory.   I  would guess this  would
cause havoc with fvwm2    created processes  that don't reset    their
current working directory.

If I attempt to make the logic work from any directory, I've got to
do more parsing, mallocs and strcats to put $HOME where its needed.

How would you all feel about documenting this as a restriction?

> user_home_ptr is either $FVWM_USERHOME or './.fvwm' or '.'

I'll look at the message, under some conditions the logic actually takes
a 3rd look which isn't in the message either.  I was concerned about
the message logic exceeding the complexity of the actual read logic.
It might make more sense to just generate "file .fvwm2rc not found".

--
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: Matthias Clasen <[email-masked]>
Date: Fri, 9 Apr 1999 22:29:39 +0200

> Content-Type: text/plain; charset=US-ASCII
> Date: Fri, 09 Apr 1999 08:50:04 -0400
> From: Dan Espen <[email-masked]>
> Sender: [email-masked]
> Precedence: list
> X-Majordomo: 1.94.jlt7
> 

I don't care too much for modules not getting this right, my main
concern is that fvwm should always be able to find $HOME/.fvwm2rc.

> How would you all feel about documenting this as a restriction?

I would be more happy about a return of $HOME (the session code needs
that directory as well, so maybe some mallocs and strcats can be combined),
but if it doesn't return, the documentation for Read has to be changed
(sed s/\$HOME/\./g).
 
> It might make more sense to just generate "file .fvwm2rc not found".

Yes. You could leave the more detailed search info in a debug message.

Matthias

---

From: Steve Robbins <[email-masked]>
Date: Sat, 10 Apr 1999 11:42:44 -0400 (EDT)

On Thu, 8 Apr 1999, Matthias Clasen wrote:

> but if I start from somewhere else, it doesn't find my .fvwm2rc 

I just had a look at the read logic, and read.c has this to say:

/*
 * func to do actual read/piperead work
 * Arg 1 is file name to read.
 *   If the filename starts with "/", just read it.
 *   Otherwise we need the user home directory which is either
 *   "." or ".fvwm/".
 *   If the file starts with a dot, and  no ".fvwm" dir, read
 *     .x, sysconfdir/x.
 *   If the file starts with a dot, and  a ".fvwm" dir, read
 *     .fvwm/x, sysconfdir/x, .x.
 *   If the file doesn't start with a dot, and no ".fvwm" dir, read
 *     x, sysconfdir/x.
 *   If the file doesn't start with a dot, and a ".fvwm" dir, read
 *     .fvwm/x, sysconfdir/x.
 *
 * Arg 2 (optional) "Quiet" to suppress message on missing file.
 */
static void ReadSubFunc(XEvent *eventp,Window junk,FvwmWindow *tmp_win,
                        unsigned long context, char *action,int* Module,
                        int piperead)

Umm... does this seem overly-complicated to anyone else?

I particularly don't like programs second-guessing me based on whether the
filename has a leading dot or not.

I would favour a simpler logic:

at startup time:
	if environment variable FVWM_USERHOME is set
		fvwm_userhome = $FVWM_USERHOME
	else
		fvwm_userhome = $HOME

then read( filename ) does one of exactly two things:

	if filename is absolute (start with leading slash) 
		read filename
	else
		try fvwm_userhome/filename
		if not found try configdir/filename

where configdir is the system-wide config directory.  Currently this is
${sysconfdir}, but since we're dumping lotsa stuff in it, we ought to
change to ${sysconfdir}/fvwm. 

--
Steve Robbins                              <[email-masked]>

Istanbul was Constantinople,
now it's Istanbul, not Constantinople.
Why did Constantinople get the works?
That's nobody's business but the Turks'!

---

From: Matthias Clasen <[email-masked]>
Date: Sat, 10 Apr 1999 22:37:15 +0200

> Umm... does this seem overly-complicated to anyone else?

Yes.

> change to ${sysconfdir}/fvwm. 

This sounds reasonable to me.

Matthias

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 11 Apr 1999 01:33:14 +0300 (IDT)

> Umm... does this seem overly-complicated to anyone else?

Yes, it is very complicated for the user. This entire comment must go into
the man page. But I understand every step in this logic and why it is
needed. It tries to be both new and backward compatible. Actually to be
truely backward compatible, '.' must be replaced by $HOME and .fvwm/ by
$HOME/.fvwm/ . Even if this requires additional malloc.

> 		fvwm_userhome = $FVWM_USERHOME

I think, Dan wanted to introduce $HOME/.fvwm, so the last line, probably,
must be (perl):
                fvwm_userhome = (-d "$HOME/.fvwm")? "$HOME/.fvwm": $HOME

> 		if not found try configdir/filename

In the implemented logic, current directory (must be home directory)
is treated specially, all configuration files must start with a period.
So,  Read .fvwm2rc  will search in:
    $HOME/.fvwm2rc and/or $HOME/.fvwm/fvwm2rc

I think it is acceptable that home directory is not treated specially.
In this case the suggested new logic (by Steve) is ok.

> where configdir is the system-wide config directory.Currently this is

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Sat, 10 Apr 1999 20:50:37 -0400

> $HOME/.fvwm/ . Even if this requires additional malloc.

The comment reflects what the code accomplishes, not the implementation.
(There aren't as many ifs/ands in the implementation.)

For relative paths, there are a maximum of 3 probes for the file.
I didn't think documenting the 3rd probe was necessary since its there
for the case where you have created a ".fvwm" directory, but you have
existing reads of files in $HOME for files that don't have a leading dot,
and reads for files that have a leading dot that you haven't moved,
for example, "read .myconfig/.myfile".

I'm sorry this is complicated.  My first inclination was to have all
config files have a leading dot.  Once I agreed to remove the dot
when the file was not in $HOME, it became a little bit more involved.

>                 fvwm_userhome = (-d "$HOME/.fvwm")? "$HOME/.fvwm": $HOME

Except for using $HOME, thats what I'm doing.  Note that the original
code also dealt with the getenv on $HOME failing.  I was trying to
keep it simple, and decided to avoid $HOME.

> In this case the suggested new logic (by Steve) is ok.

I must be missing something.  I think the 3rd probe is needed for
backward compatibility.  Do we get that with this proposal?

Note that the first read when there is a ".fvwm" directory must
be in the ".fvwm" directory.  This is to avoid old .xxx files
in the users home directory.

> > change to ${sysconfdir}/fvwm.

I agree with this, in fact I install with sysconfdir set this way.
Any hints on how this can be made the default?

---

From: Julian Gilbey <[email-masked]>
Date: Sun, 11 Apr 1999 03:09:15 +0100 (BST)

> > [...]

Why are we aiming for backwards compatibility on such a trivial matter
at the expense of making the docs *so* complicated?  I think that
small changes in logic between version 2.2 and 2.4 are not that
disasterous, especially as there will be many more significant changes
as well.  I think that users should always be encouraged to look at
NEWS files, which should contain the key points first.  Maybe have the
fvwm2 manpage begin "If you have recently upgraded your FVWM, please
remember to look at the NEWS file for imporant notes about changes in
this version."  And the worst that will, most likely, happen is that
some of their config files won't be read, and they'll wonder why,
figure it's 'cos they've upgraded and maybe, just maybe, they'll read
the docs.

Or is there something much subtler that I'm missing here?

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [email-masked]
             Debian GNU/Linux Developer.  [email-masked]
       -*- Finger [email-masked] for my PGP public key. -*-
--
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: Steve Robbins <[email-masked]>
Date: Sun, 11 Apr 1999 01:05:28 -0400 (EDT)

>                 fvwm_userhome = (-d "$HOME/.fvwm")? "$HOME/.fvwm": $HOME

Why?  

If the user wants to use $HOME/.fvwm, let them set the FVWM_USERHOME
variable.  That's what it's there for. 

A woman came up to me and said, "I'd like to poison your mind,
with wrong ideas that appeal to you, though I am not unkind."

---

From: Steve Robbins <[email-masked]>
Date: Sun, 11 Apr 1999 01:11:57 -0400 (EDT)

> Except for using $HOME, thats what I'm doing.

No, the code also plays games with leading dots, and treats "$HOME/.fvwm"
as magical.

That's rather complicated to understand, and seems unnecessary to me.

> Any hints on how this can be made the default?

Simple.  Change the line in configure.in from

	FVWM_CONFIGDIR='${sysconfdir}'
to
	FVWM_CONFIGDIR='${sysconfdir}/${PACKAGE}'

---

From: [email-masked]
Date: 11 Apr 1999 12:44:51 +0200

> variable.  That's what it's there for. 

I think people expect programs to read config files from ~, not from
the current working directory.  So fvwm should be able to find ~ even
with FVWM_USERHOME unset.

Just MHO.

kai
-- 
Abort this operation?   [Abort]  [Cancel]

---

From: Dan Espen <[email-masked]>
Date: Sun, 11 Apr 1999 09:04:42 -0400

> variable.  That's what it's there for. 

The installation form creates the users .fvwm directory by executing a
mkdir.    Any  hints as   to how  I   make   the users  profile export
$FVWM_USERHOME?

---

From: Dan Espen <[email-masked]>
Date: Sun, 11 Apr 1999 09:02:20 -0400

> That's rather complicated to understand, and seems unnecessary to me.

I'll repeat, my first pass on this was to leave the leading dots on
config files.  I thought there was concensus that all config files
stored in sub directories would be stored without the leading dot.

When I change the man page so that it reads this way, I don't think
thats terribly complicated.

---

From: Dan Espen <[email-masked]>
Date: Sun, 11 Apr 1999 09:16:59 -0400

> Or is there something much subtler that I'm missing here?

I think you are missing something.

The extra read for compatibility is NOT documented.
Its not meant to be used intentionally by a user.
It only kicks in when the read command encounters an non-quiet
read, that has otherwise failed, and the file name is such that
read.c thinks it may be a file created before the sub-directory
feature was created.

The issue seems to be the complexity of the comment in read.c.

The actual code in read.c is a little simpler than the comment,
and the man page is simpler than the code.

Don't get me wrong.  I'll change the code if we can come to an
agreement.

In this case what I'm after is being able to store config files either
in $HOME or a sub-directory off $HOME, and no additional hand editting
of configurations.  The "dot flipping" was not my idea, although
I see some logic to it.

---

From: Steve Robbins <[email-masked]>
Date: Sun, 11 Apr 1999 09:22:16 -0400 (EDT)

> with FVWM_USERHOME unset.

Yes, that's what I had proposed; $FVWM_USERHOME is an *override* for
those who want the config stuff somewhere else. 

To reiterate, the user config files will be searched for

	* in $FVWM_USERHOME if set, else
	* in $HOME

and no games with leading dots.

I am an anarchist.  
I am the antichrist.

---

From: Steve Robbins <[email-masked]>
Date: Sun, 11 Apr 1999 16:05:37 -0400 (EDT)

> mkdir.    Any  hints as   to how  I   make   the users  profile export

I would suggest that if your site is going to standardise on FVWM_USERHOME
= ~/.fvwm, then you can wrap fvwm in the following script:

	#!/bin/sh
	test "$FVWM_USERHOME" || FVWM_USERHOME=${HOME}/.fvwm
	export FVWM_USERHOME
	exec real_fvwm

Well, you tried it just once, and found it alright for kicks,
Now you found out that it's a habit that sticks,
And you're an orgasm addict.

---

From: Steve Robbins <[email-masked]>
Date: Sun, 11 Apr 1999 16:18:59 -0400 (EDT)

> stored in sub directories would be stored without the leading dot.

There was a lot of discussion about FVWM *installing* dotfiles in SYSTEM
directories.  The consensus was that *that* is a poor idea. 

I don't recall any discussion about leading dots in USER config files.
What the user calls these files is up to the user.

Which is my point: I don't want fvwm second-guessing me about things like
leading dots.

---

From: Dan Espen <[email-masked]>
Date: Mon, 12 Apr 1999 15:49:44 -0400

> Which is my point: I don't want fvwm second-guessing me about things like

No one  likes to admit   failure, but I'm  not happy  with this change
either.  I'll back it out as soon as I can.  As someone once said,
you code the first one to throw away.

---

From: Julian Gilbey <[email-masked]>
Date: Tue, 13 Apr 1999 11:57:55 +0100 (BST)

> read.c thinks it may be a file created before the sub-directory

I understand (I think).  Hmm.  What files would be created that would
need looking at in the new version?  Can we list all of them?  If yes
(presuming they are something such as module config files), then write
a short shell script such as:

#!/bin/sh
cd
if [ ! -d .fvwm ]; then
  mkdir .fvwm ||
    { echo "Couldn't make ~/.fvwm directory!  Aborting...." >&2; exit 1; }
fi

for i in FvwmAnimate FvwmFoo FvwmBar; do
  [ -r ".$i" ] && cp -p ".$i" ".fvwm/$i"
done

Then in the README tell users to run this script during the upgrading
procedure.

I hate the thought of unnecessarily coding for legacy stuff like this,
which will only lead to worse problems in the future, and which is so
easy to fix.  ("Why doesn't my config file get read?"  "Have you
checked whether you have any of the following 17 other files on your
system?")

   Julian

---

From: [email-masked] (Paul D. Smith)
Date: 13 Apr 1999 09:59:18 -0400

%% Julian Gilbey <[email-masked]> writes:

  jg> I hate the thought of unnecessarily coding for legacy stuff like
  jg> this, which will only lead to worse problems in the future, and
  jg> which is so easy to fix.  ("Why doesn't my config file get read?"
  jg> "Have you checked whether you have any of the following 17 other
  jg> files on your system?")

Ouch.  This makes me cringe :).

You have no idea how many times you'll be forced to answer that question
or how tired of it you will get until you do something like that.  Trust
me.  It doesn't matter how often you document it in how many different
places, you will get message after message after message on changes like
this if they're not backward-compatible.

And after you patiently explain it for the umpteenth time, you'll have
to suffer abuse from those same people saying "why in the world did you
change that?"

Backward-compatibility _IS_ an extremely important goal.  Not only does
it make our lives easier by avoiding reams of questions, but it gives
users a sense of comfort that they can install new versions and not
rework their entire environment, and that's critically important
esp. for fundamental tools like fvwm.

I personally am willing to put up with an _AWFUL_ lot of crufty smelly
code in this area to preserve compatibility--after all, we're the only
ones who have to hold our noses.

My $0.02.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
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]