Re: FVWM: Strange fvwm-related problems

From: Phil Stracchino <alaric_at_caerllewys.net>
Date: Wed, 2 Jul 2003 20:21:47 -0400

On Wed, Jul 02, 2003 at 10:50:43PM +0000, Mikhael Goikhman wrote:
> You didn't show any configuration, like definition of your InitFunction
> or commands you use in sirc to open other application windows.

Sorry for the omission. I didn't include my InitFunction because I
wasn't starting sirc from InitFunction, and because the problem with
procmeter3 didn't seem specific to InitFunction -- the procmeter3
problem occurs whenever procmeter3 is started from fvwm2 by any means.

An example definition for sirc is as follows:

    my $rcdir = $ENV{'HOME'}.'/.sirc';

    sub cmd_edit
    {
        my $cmd = sprintf ('/usr/local/bin/xcoral %s &', $args);
        system ($cmd);
    }
    &addcmd("edit");

    &docommand("^alias rc edit ~/.sirc/sircrc.pl");


The equivalent definition for icbm is almost identical:

    my $rcdir = $ENV{'HOME'}.'/.icbm';

    sub edit
    {
        my $cmd = sprintf ('/usr/local/bin/xcoral %s &', _at__);
        system ($cmd);
    }
    &addcmd('edit');

    &alias ('rc', "edit $rcdir/commands");




> Please do this simple test. Start your fvwm-2.4.16 using this command:
>
> fvwm -c "AddToFunc InitFunction I Exec exec xterm -e sirc"
>
> (place it into ~/.xinitrc or the equivalent)
> Does sirc work like you expect even if started from InitFunction?

This actually doesn't replicate my situation, because I'm not starting
sirc directly. I open an xterm, and from that xterm I run a Perl script
which forks off a series of child processes, each of which spawns an
xterm and starts an sirc or icbm instance in it. Normally I do not do
this from InitFunction because usually, when I log in and start fvwm, my
dialup isn't connected yet and there's no servers available for sirc or
icbm to connect to. I also hadn't tried putting that script into
InitFunction because when I tried running the script from a menu in
fvwm-1.24r, it didn't work, and I was never able to figure out why. The
script executed, but no windows ever appeared.

However, in accordance with your instructions, I tried adding the
following to InitFunction:

+ "I" Exec exec /home/alaric/bin/geek

And to my surprise, not only did it work, but the icbm and sirc
instances it started could launch external windowed apps without any
problems. This mystifies me even more -- starting procmeter3 from
InitFunction breaks it, but running bin/geek from InitFunction makes
sirc and icbm work right? Most peculiar, Holmes.

Based on this, I then tried adding my front-end script to an fvwm menu
as follows:

AddToMenu RootMenu "Desktop Menu" Title
+ "Geek!" Exec exec /home/alaric/bin/geek

This worked too. So, it seems whatever the problem is, I can work
around it (so long as I don't want to specify additional options) by
starting my front-end from fvwm; this still doesn't tell me what the
problem is, though, or enable me to start from an xterm and have
launching work. It just occurred to me to try entering the command
using FvwmTalk, though, and that too works and yields a chat window from
which I can spawn windowed applications.

I've tried a few variations on these various themes trying to find a
similar workaround to the problem with procmeter3, with no success.
That's still a complete mystery to me.


> If yes, post your entire .fvwm2rc and we will try to find an error.
> If no, try to do more experiments with a mininal configuration.

Attached. I've also included my front-end script for starting icbm and
sirc in case it sheds any clues.



> > (Oh, and what's with fvwm2 on Solaris defaulting to utterly and totally
> > ignoring ALL user window-manager configuration?)
>
> Please explain this question.
>
> Do you mean Sun (or sysadmin) patched fvwm to ignore ~/.fvwm/.fvwm2rc
> configuration file or something else?

I take it this is NOT an expected occurrence. Allow me to clarify,
therefore:

I downloaded fvwm-2.4.16 source and used it to build fvwm2 for this
machine (an Athlon XP1800 running a heavily-updated, Slackware-7.0-based
Linux). I then performed a make distclean and used the exact same
source code, with as close as applicable to the exact same configuration
options, to build fvwm2 on an Ultra30 running Solaris 9.

The fvwm2 installation built on Linux honors all user configuration
files automatically, and just Does The Right Thing. The fvwm2 built on
the Solaris machine defaults to ignoring all user configuration files
unless explicitly started as 'fvwm2 -f $HOME/.fvwm2rc'.

I take it from your response this is not supposed to happen. Is it
possible that the prior presence of the Sunfreeware fvwm-2.4.5 package
on the machine while configuring fvwm-2.4.16 (I removed the fvwm-2.4.5
package before fvwm-2.4.16's make install) could have an influence on
this?


-- 
 .*********  Fight Back!  It may not be just YOUR life at risk.  *********.
 : phil stracchino : unix ronin : renaissance man : mystic zen biker geek :
 :  alaric_at_caerllewys.net : alaric-ruthven_at_earthlink.net : phil_at_latt.net  :
 :   2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold)   :
 :    Linux Now!   ...Because friends don't let friends use Microsoft.    :




--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Wed Jul 02 2003 - 21:11:06 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:55 BST